Re: [gdm-list] xsession-errors


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.


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]