Request to limit xinit writes to .xsession-errors to some reasonable value, such as 10 megs

[Derek]

Binary package hint: x11-apps

Recently, I discovered a system that had been completely shut down for a rather ridiculous reason.
Over a period of 21 hours, a user's .xsession-filled with the following:
============================
Starting Oracle Universal Installer...
Checking installer requirements...
Checking operating system version: must be redhat-4, redhat-5, SuSE-9 or SuSE-10 Passed
All installer requirements met.
Checking Temp space: must be greater than 400 MB. Actual 384320 MB Passed
Checking swap space: must be greater than 512 MB. Actual 7730MB Passed
Checking monitor: must be configured to display at least 256 colors Failed <<<<
    >>> Could not execute /usr/X11R6/bin/xdpyinfo
Checking if CPU speed is above 300 MHz. Actual 2992 MHz Passed

Some optional pre-requisite checks have failed (see above). Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n]

... repeat that last portion about 20 billion times, approximately 256,000 repetitions of the phrase per second, until:

# ls -lh .xsession-errors
-rw------- 1 1000 1000 373G 2010-08-26 13:11 .xsession-errors

Now. I have looked into the history of this, and I've noted that this sort of thing happens periodically. Users file a bug, and it is closed.

Now, I'm aware that this is obviously the fault of misbehaving apps...
But.
Is there any reason this couldn't be mitigated?

I've read elsewhere that right now the syntax for this file is xinit calling:
exec >"$ERRFILE" 2>&1

Could that not be changed to:
exec 2>&1 | head -c 5000000 > "$ERRFILE"

Or something similar?

Thanks!

[Derek (bugs-m8y)]

Or.. piping to any command capable of doing a rolling log would be even better.

[Derek (bugs-m8y)]

FWIW, I tried modifying mine to add a head -c and it seems just fine.

I hope this issue can get a little more attention, since it can have significant stability impact in the pathological case.

[Bryce Harrington (bryce)]

Despite the first letter in the filename, .xsession-errors is produced by gdm rather than X itself.

Specifically, the code that creates it is in gdm:_open_session_log() in file daemon/gdm-session-worker.c

[Derek (bugs-m8y)]

Err.... No.

ERRFILE=$HOME/.xsession-errors in /etc/X11/Xsession

Which, BTW already has a truncate:

# truncate ERRFILE if it is too big to avoid disk usage DoS
if [ "`stat -c%s \"$ERRFILE\"`" -gt 500000 ]; then
  T=`mktemp -p "$HOME"`
  tail -c 500000 "$ERRFILE" > "$T" && mv -f "$T" "$ERRFILE" || rm -f "$T"
fi

exec >>"$ERRFILE" 2>&1

That exec is the one I personally modified to:
exec 2>&1 | head -c 5000000 >> "$ERRFILE"

Also other bugs about this exact same problem are in x11-apps

[Derek (bugs-m8y)]

(The problem with the truncate BTW is it is from session to session, there is nothing to handle a single pathological session)

Anyway, yeah, don't think the move was correct.

[Derek (bugs-m8y)]

exec 2>&1 | uniq -c | sed 's/^[[:space:]]*1[[:space:]]//' | head -c 5000000 >> "$ERRFILE"

increase useful info density.

[Derek (bugs-m8y)]

further suggestion from ion in IRC.
 "On my system, there’s a great number of messages from Gtk applications that have extra newlines, making uniq unable to do its magic.

exec 2>&1 | grep -Ev '^[[:space:]]*$' | uniq -c | sed 's/^[[:space:]]*1[[:space:]]//' | head -c 5000000 >> "$ERRFILE"

[Derek (bugs-m8y)]

So, today had an experience w/ a runaway nx client that wrote 44 gigs to ~/.gnomerc-errors in a matter of minutes.

Presumably the uniq -c approach from the prior comment would have prevented that, although I don't know if there's a handy wrapper layer in between. I believe the client had a direct handle to the error file.

Just thought I'd mention in terms of sucking up disc space.