GNOME Bugzilla – Bug 459293
.xsession-errors limit can be quite annoying
Last modified: 2010-11-10 21:03:29 UTC
Please describe the problem: After an X session has output more than MAX_XSESSION_ERRORS_BYTES of output, the message "Too much output, ignoring rest" is written and all logging stops. This is obviously a good thing because it prevents a user from filling up their filesystem with fairly useless information; however it can occasionally be useful for debugging purposes; for instances, it makes debugging problems that only occur when I have been logged in for a few days more difficult. I suggest that instead of keeping only the earliest X session output, GDM instead keeps only the latest. That is, it logs to ~/.xsession-errors as normal; when the length of that file surpasses MAX_XSESSION_ERRORS_BYTES, the file is renamed to ~/.xsession-errors.old, it is compressed with gzip, and a new ~/.xsession-errors file is created. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information: [ forwarded from http://bugs.debian.org/303346 ]
This seems reasonable, although I'm a bit wary of using gzip unless configure.ac detects its location and only uses it if found on the system. I'd accept a patch to make this work. Note similar bug #419085 which should probably be fixed along with this bug.
See also Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/15027 ... I didn't notice they had imported Debian bug #303346 so I ended up submitting a duplicate (I'm also the original submitted of the Debian bug). Anyway, in the duplicate https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/162991 I'm suggesting an alternate architecture where the primary logging device would be a volatile target of some sort (sort of like dmesg or /dev/xconsole) and the logging to ${HOME}/.xsession-errors could copy stuff from there until it fills up, and then maybe leave a pointer to the primary logging device. Maybe an example would be in place here. Say you establish a FIFO /var/run/X0.session-errors and copy stuff from there to ${HOME}/.xsession-errors until MAX_XSESSION_ERRORS_BYTES is exceeded, then leave a message there "Too much output, storing in log file suppressed, see /var/run/X0.xsession-errors for latest messages". (Not sure if /var/run is a FHS-compliant location etc but you get the idea, I hope.)
Hi, So we recently discussed this bug on list: http://mail.gnome.org/archives/gdm-list/2007-November/msg00017.html We came to the conclusion it's probably better to go less engineered than more engineered, and just remove gdm from the equation entirely.
Looking very good! Thanks for the update.
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.
It would be wonderful if the limit were user-configurable, without needing to recompile gdm. Hardcoding a cutoff value of 200000 isn't the best choice for all systems.
FYI, a workaround was also discussed on the mailing list: http://mail.gnome.org/archives/gdm-list/2010-May/msg00035.html It requires recompiling gdm, though.
seems the new comments indicate that's still an issue and the bug should be reopen?
I'd be delighted if it were to be reopened. However, the bug is for version 2.18, and I'm currently observing the bug on 2.20. Perhaps a new bug should be created.
I can confirm the problem still exist in version 2.20.10. Please reopen? Making the cut-off configurable without recompiling might be a solution. Allowing the logging to 'wrap around' (storing the newest X lines instead of the oldest, like dmesg does) would be nice, too, imho.