MDM: Size limit and filtering in .xsession-errors
by clem 15

With GTK, Glib and a few libraries/toolkits sending warnings at widget level, we recently saw people being unable to log in, or getting their system crawl. In Fedora a user reported his .xsession-errors had gotten larger than 500GB. Most of the information in that file was spammed by a single process and the output was irrelevant to the user himself.

In the upcoming MDM 1.8, the session output is limited to 200KB (between 2000 and 4000 lines of logs). This limit is enabled by default and the user can disable it in the MDM preferences. When .xsession-errors reaches 200KB, a footer is appended by MDM explaining that the limit was reached and how to disable it.

Another option coming in the MDM preferences allows the user to filter the session output. This option, which is disabled by default, prevents warnings and errors from GTK, Glib, Gio, Gobject, Glade etc… from getting into .xsession-errors.

15 thoughts on “MDM: Size limit and filtering in .xsession-errors

  1. VolMi Oct 29,2014 13:27

    zomg, I was not aware of that amount of spam. I just peeked in mine, which is currently at 56MiB and contains plenty of these silly GTK warnings that I hate so much.
    I hope that someday someone will take care of that upstream…

    I am on pure Debian and use lightdm; I think I will put a simple
    sh -c ‘:> ~/.xsession-errors’
    in my startup commands in order to tame that beast the poor man’s way.

    • VolMi Oct 29,2014 13:57

      I thought a bit and now came up with this:
      I have *never* been interested in the contents of ~/.xsession-errors in many years now. If I want to see program-specific errors and warnings, I always open the program from the command line and see what it barks at me. So I am fine if that stuff is not logged at all, i.e. written to /dev/null.
      This can be done by
      rm ~/.xsession-errors; ln -s /dev/null ~/.xsession-errors

      But I thought, why not write that to /dev/random instead, so Linux’ random pool gets a tad more noisy input?
      rm ~/.xsession-errors; ln -s /dev/random ~/.xsession-errors
      This is fine as long as no root process writes to ~/.xsession-errors: If it does, Linux’ entropy counter is actually increased which should only be done for true random input.

  2. Matthew Morgan Oct 29,2014 13:37

    Wow, I’ve never run into this before. I wish one of you guys had been working for the SBS Server 2008 team. Microsoft talks about the defaults for SBS Monitoring of use all available RAM and disk space as if they are a performance feature.

    As a user I can say I really appreciate attention to this type of detail. If my system does something like fail to log in, I want it to be because I did something stupid. ;)

  3. Miati Oct 29,2014 14:28

    Interesting, reviewing my .xsession file, 457806 out of 459852 lines of code are one message –

    Window manager warning: Log level 8: meta_screen_get_monitor_geometry: assertion ‘monitor >= 0 && monitor n_monitor_infos’ failed

    I guess that takes nagging to a whole new level!
    Maybe a nice feature (if possible) would be to periodically uniq the file?
    This dropped my .xsession file to 2338 lines

  4. xxTT22xx Oct 29,2014 14:55


    I remembered how trying to play Civilization 5 under Wine, and .xsession-errors ate all free space (~100GB on SSD) for some hours :)

  5. Jamin Samuel Oct 30,2014 04:27

    Hi Clem, can you include “gnome-system-monitor” 3.12.2 in Linux MInt 17.1 Rebecca?

    Is possible?

      • Bob the builder Oct 30,2014 16:14

        Why not? :P
        It is a more up-to-date version of a useful program. I mean, perhaps you don’t want to change many programs from 17 to 17.1. But why do you keep the old versions of some programs in the first place (Mint 16,17 have gedit 2.30, an old gedit version without some of the new features).

        • mtwebster Oct 30,2014 16:35

          In most cases, when we provide an older version, it’s because *we* feel the latest version falls short in some area or other, so we pick the best version available, in our judgement. This is the case with gedit.

          As for gnome-system-monitor – version 3.12 probably requires the equivalent versions of libraries that it uses (like GTK, GLib for example) which will *not* be updated in 17.1, other than major bugfixes.

        • clem Oct 30,2014 19:48

          When you mentioned it I thought you had a reason, a feature that landed in 3.12 or an important bug fix you wanted. Is that the case?

          Otherwise as mtwebster said, GNOME isn’t great at retro-compatibility, upgrading some of it usually means upgrading all of it.

          Anyway, there’s no plan on upgrading anything based on the fact that there are newer versions out (3.14 would qualify as well in that case). That said, any bug fix, any new cool feature can be looked at and make a strong case for individual backports.

          So if there’s something cool you’re missing in 17.x and it’s a backport away let us know and we’ll consider it.

        • clem Oct 30,2014 19:49

          Re-gedit, that’s different, that’s a special case. That program is frozen at version 2.x. Changes in the UI, and in the way the search works in particular were considered regressions.

  6. David H. Durgee Oct 31,2014 15:59

    I’m not sure how you are planning to implement this, but would it make sense to have the log show that last however many lines fit in the size limit as opposed to simply discarding additional logging at that point? If there is an easy way to drop off the beginning x blocks of the log file this might be workable.

    I am thinking that there might be a reason to want to know what errors are currently being logged as opposed to what was logged at the beginning of the session in order to be able to take a stab at whatever remidial action might be needed.

    Of course if there is something logging errors in a run-away fashion, as I saw with nemo in my issue 749 there, this might make CPU hogging even worse.


    • Geoff M Nov 1,2014 01:50

      Yes, that would be the logical way to do it. If you can only keep 200k, why would you want that to be the last 200k before it got full, instead of the last 200k, period?

  7. David H. Durgee Oct 31,2014 16:31

    Another thought inspired by Miati’s comment above. Perhaps once the size limit is reached change the logging mode so some sort of uniq tabulation of errors as opposed to extending the log. When I was trying to find out what was causing the problem I was using the following command:

    sort .xsession-errors | uniq –count | sort -n >latest-errors.log

    I could then tail the last n lines to see the worst offenders. I don’t know if it makes more sense to sort it up or down on the tally, I could see both being useful depending if you wanted to head or tail the file. It might also be useful to timestamp the last occurence of a particular error being logged, but I am unsure how that could be implemented if the errors are not timestamped in the first place.

    Take my comments with a grain of salt as appropriate, as I am not capable of programming this myself and unsure how useful my suggestions are to those trying to deal with the conditions being encountered.


  8. David H. Durgee Dec 15,2014 18:13

    A question for you, what is involved in obtaining the updated MDM in qiana? Do I need to add “backports” to my repository list? Do I need to upgrade to rebecca?

    It has been a while since this was released and I still don’t see it applied to my qiana system via updates, thus my question. I still show MDM 1.6.9 here.

    Once I have it do I need to reboot to get it running? Is a restart of X sufficient?


Comments are closed.