[gdm-list] xsession-errors

["Ray Strode" <halfline gmail com>]

Hi Brian and Jon,

So I spent a little time tonight working on getting .xsession-errors
support back in (patch attached).  It does things differently than the
way the gdm-2.20 and earlier did.  The way it worked in 2.20 was a
little complicated.

Previously, the slave would:

1) open ~/.xsession-errors
1a) fallback to /tmp/xses-$LOGNAME.XXXXX to 1 didn't work
2) open a pipe
3) attach one end of the pipe to stdout and stderr of the children
4) watch the other end of the pipe for output, and feed the results
from the pipe to opened .xsession-errors file

This is sort of icky because it has data coming from the user running
session to a root run process and then the root run process is sending
the data back to a file in the user's home directory.

>From looking at the code it seems like the reason it does this is to
prevent SIGXFSZ signal from getting sent to any process in the session
that writes to stdout/stderr after .xsessoin-errors reaches a size
bigger than the set user limit.  Since very few programs trap SIGXFSZ,
most programs in the session would get killed if .xsession-errors ever
grows past the user limit.

I talked with Roland McGrath (of glibc and utrace frame) on IRC about
what our options going forward could be (just sort of brain storming).

The first idea we talked about was creating a session-logger helper
application that runs along side the session within the user's
context, doing the proxy logging work the slave did
in 2.20.  The problem then is if that app ever dies or hangs or gets
killed, the next (and all subsequent) app that tries to print to the
console will get a  SIGPIPE and die.

The next idea was to leak a reference to the pipe outside of the
proxy-process so the SIGPIPE would never get generated.  The problem
with that approach is that all apps would block on the write instead.

>From there we talked about making the pipe non-blocking on the write
end.  This means in our proxy-dying scenario, that write calls from
apps in the session would fail with -EAGAIN.  Normally, write calls to
console are in the form of printf() / fprintf(stderr, ...) so the
EAGAIN failures wouldn't be a big deal most of the time.  It may be a
problem under some scenarios though.

Another option we discussed was using a pseudoterminal instead of a
pipe.  this option was discounted pretty quickly, because it has the
possiblity of breaking apps that depend on isatty() tests to fail when
running outside of an interactive terminal.

The last option we considered was the simple, straightforward one.
Redirect console i/o straight to ~/.xsession-errors without the
intermediate proxy.  It has the SIGXFSZ problem, obviously.

Some things to think about:

- .xsession-errors is ideally empty all the time.  UI programs aren't
supposed to write to stdout/stderr, so when they do it's normally for
exceptional reasons.
- the default user limit for files is unlimited.  It's atypical to
have it set to anything but unlimited in fact.
- most files in a typical user's home directory are orders of
magnitude bigger than .xsession-errors
- when a user limit is set, it needs to be big enough to accommodate
the files in the user's home directory (obviously)
- given the above two things, it's very unlikely that that
.xsession-errors will ever hit the user limit

Anyway, the pipe trick seems to add  a lot of complexity for a small
gain in robustness in one set of scenarios but decreases robustness
for another set of scenarios.  It seems better to stick with the
simplest approach and just skip the proxy helper.

thoughts?

--Ray