Re: [gdm-list] xsession-errors

[Brian Cameron <Brian Cameron Sun COM>]

Ray:

> 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.

Thanks for helping with this.  There are also some issues that people
have complained about relating to how this works:

- Bug 419085 - Running Xnest stomps your .xsession-errors file.  Perhaps
  it makes sense to append the $DISPLAY value to the filename if the
  value is not ":0" or something?

- Bug 459293 - Some ideas about dealing with file limits.

- Bug 493737 - Support a fifo instead of a file for .xsession-errors.

Perhaps we should address some of these issues as well if we are
working in this area.

> 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.

Ick.

> 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.

I like the fact that this is simple.  Is there nothing that can be
done to limit its size?

> 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.

I guess this depends on how this is implemented.

With GDM 2.20 and earlier, I notice that warnings from programs
launched from the panel don't get logged in this file.  Some GTK+
based programs spew lots of warnings.  If we rewrite this so that
programs launched from the panel get logged here, then it might
grow large - especially for users who leave a session running for
a long time.

> - 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.

I'd say that a simple approach makes sense.  If users end up
complaining about problems, we can always add more smarts to how
this works later.

Brian