Announcement

Collapse
No announcement yet.

GNOME 3.12 Puts The X.Org Log In The Systemd Journal

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNOME 3.12 Puts The X.Org Log In The Systemd Journal

    Phoronix: GNOME 3.12 Puts The X.Org Log In The Systemd Journal

    A useful tip shared by X.Org input expert Peter Hutterer is that with today's GNOME 3.12 release the GNOME Display Manager is no longer writing X.Org Server logs to the file but is being stored within systemd's journal...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    trollfest in 3 2 ...

    Comment


    • #3
      Originally posted by Peter Hutterer
      Previously the server kept only a single backup log file around, so if you restarted twice after a crash, the log was gone. With the journal it's now easy to extract the log file from that crash five restarts ago. It's almost like the future is already here.
      Probably what I like most about this. While it doesn't happen often, sometimes there's that "oops" moment when you restart after a crash and realise you've just wiped the log you needed to troubleshoot your problem. If you know you only rebooted 'n' times since the crash, you can use 'journalctl -b -n /usr/bin/Xorg' (where n is an integer) to find all Xorg logs for that boot. Handy.
      Last edited by Nobu; 27 March 2014, 01:26 AM.

      Comment


      • #4
        Originally posted by Nobu View Post
        Probably what I like most about this. While it doesn't happen often, sometimes there's that "oops" moment when you restart after a crash and realise you've just wiped the log you needed to troubleshoot your problem. If you know you only rebooted 'n' times since the crash, you can use 'journalctl -b -n /usr/bin/Xorg' (where n is an integer) to find all Xorg logs for that boot. Handy.
        I don't remember how many times I rebooted, but it was a friday or monday and full moon.. is there an option for journalctl to find that? I think it is a valid use case and such option needs to be added.
        And I always restart everything 3-4 times after a crash. And debugging crash that happened 3 years ago on another xorg/drivers is my hobby ))
        Last edited by Stellarwind; 27 March 2014, 02:50 AM.

        Comment


        • #5
          Originally posted by Stellarwind View Post
          I don't remember how many times I rebooted, but it was a friday or monday and full moon.. is there an option for journalctl to find that? I think it is a valid use case and such option needs to be added.
          And I always restart everything 3-4 times after a crash. And debugging crash that happened 3 years ago on another xorg/drivers is my hobby ))
          Well now you can centralize all logs and configure that for all. Why keep logs from other stuff longer and discard the ones from xorg sooner?

          Comment


          • #6
            Originally posted by Stellarwind View Post
            I don't remember how many times I rebooted, but it was a friday or monday and full moon.. is there an option for journalctl to find that? I think it is a valid use case and such option needs to be added.
            And I always restart everything 3-4 times after a crash. And debugging crash that happened 3 years ago on another xorg/drivers is my hobby ))
            As a matter of fact, you can, as systemd logs keep the timestamp of the log (and you can search by that), and you can rotate/backup log databases as you see fit (if you want to keep longer log history). You can compute separately all friday and monday that happened at full moons, cycle in you backup logs, and find all unsuccessful termination of xorg on said days.

            Funny how your stupid and snarky example is actually feasible without too much effort.

            Comment


            • #7
              I don't understand. Is systemd a requirement for Gnome now or what? My educated guess would be no, since Gentoo still can run it, but I'm a bit confused.

              Comment


              • #8
                Originally posted by garegin View Post
                I don't understand. Is systemd a requirement for Gnome now or what? My educated guess would be no, since Gentoo still can run it, but I'm a bit confused.
                Its If-else'd. If systemd & logind are available then Gnome prefers them. If they are not they fallback to the traditional code paths.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #9
                  usually the first place to look to clues for the failure is generally the /var/log/Xorg.0.log file. If it was one restart ago, /etc/X11/Xorg.1.log.
                  This is wrong. Xorg.1.log is the log for DISPLAY=:1. You were probably thinking of Xorg.0.log.old.

                  Comment


                  • #10
                    Originally posted by garegin View Post
                    I don't understand. Is systemd a requirement for Gnome now or what? My educated guess would be no, since Gentoo still can run it, but I'm a bit confused.
                    Not a hard requirement, no. But with every Gnome release, it uses more and more systemd functionality - and since very few Gnome developers are using distros that don't run systemd, the non-systemd code paths don't get anywhere near as much testing.

                    Comment

                    Working...
                    X