Yep, we're on exactly the same page. I went through the entire 137 line /etc/X11/Xsession startup script and there is NOTHING that would account for the log rotation and resulting move of the current log to .old and subsequent creation of a new log file, so I also immediately assumed that this script was probably being overridden by the service based lightdm startup. If you check the original X11 Xsession script you'll see that if it finds that you have pointed it at a symbolic link, just as I feared, it just uses a call to mktemp to create a log in the sys tmp folder - and if that fails just bomb out and completly aborts the X startup:
if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] &&
[ ! -L "$ERRFILE" ]; then
chmod 600 "$ERRFILE"
elif ERRFILE=$(mktemp 2> /dev/null); then
if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-$USER"; then
message "warning: unable to symlink "$TMPDIR/xsession-$USER" to"
""$ERRFILE"; look for session log/errors in"
""$TMPDIR/xsession-$USER"."
fi
else
errormsg "unable to create X session log/error file; aborting."
fi
I haven't had a chance to look at the hard-coded lightdm source, but knowing how programmers like to copy off each others homework, and NOT reinvent the wheel, it wouldn't surprise me if it also would have some kind of special handling for the scenario where it finds the log file has been replaced by a symbolic link.
Not sure why the Xsession startup seems to want to avoid a symlinked log file, since symlinks to simlinks are allowed, and it could still be symlinked to some hard-coded path name within X, but that seems to be the intent of the [ ! -L "$ERRFILE" ] test, and resulting reassignment of the log file to a random /tmp system log with:
" elif ERRFILE=$(mktemp 2> /dev/null) "
So, in examining the lightdm startup there are at least TWO potential gotchas that could complicate things -- 1) like the Xsession script, it might have special handling for symbolic links -- and -- 2) even if it accepts the symbolic link, it might just mv it right out of the way by renameing it to .old, then create a brand new file, with a brand new file handle, and write to that instead.
So, as I said - IT'S COMPLICATED . . .
ALSO, I would point out that NONE of the log redirect to /dev/null fixes are practical for the Mate LIVE SESSION which has a finite RAM based file system that will fill up at the rate of up to about 400Mb a day (5000bytes/sec times 86400 sec/day). I can imagine a nightmare scenario where someone tries Mate for a few days using the Live-ISO image, then clicks on the "Install Mate" icon on their Live-Desktop, intending to Install Mate alongside MS Windows, only to have the installer RUN OUT OF SPACE AND CRASH, potentially leaving their PC unbootable.
Seriously folks, we need to just FIX THIS - not just try to figure out ever more clever ways to hack around it - AND IGNORE IT.
