Screensaver "Log Out" no longer works reliably

[jdreed]

This was briefly working for a while, and now no longer works reliably (I waited 10 minutes). Is the Log Out functionality implemented by d-bus signals? Can we listen on d-bus with our own wrapper that catches the signal and sends SIGKILL to all the user's processes?

[mitchb]

This sounds really reckless. First, why would you use SIGKILL? That
ensures that no app will exit cleanly and all but guarantees data loss.
Second, if it's not a cluster machine, the user may well have persistent
processes that aren't part of their login session, and killing those
when they get logged out of the console is wrong. You probably want
to be using SIGTERM on the jobs that are part of the relevant session only.
Of course, that's probably what the logout button was supposed to do, so
hacking around it by doing the same thing seems questionable instead
of debugging what's wrong with the existing implementation.

[jdreed]

My understanding was that we had debugged it and chalked it up to a tokens issue, to write data into AFS (when they get SIGTERM) and can't. If that's no longer true, then that's fine. Also, the next step for a user and/or hotline is to reboot the workstation, which will also guarantee data loss. Finally, we explicitly tell the freshmen that if they leave themselves logged in for more than 20 minutes and vanish, they _will_ lose data. If gnome-screensaver is correctly honoring logout_command these days, then we can certainly do something more forceful that way rather than writing our own thing. Perhaps something which runs gnome-session-save --force-logout, sleeps for 30 seconds, and then if the session is still active, give up pkill all the user's processes.

Debugging is extremely difficult, because it seems to work reliably for short durations, but fails for long ones. And when it is successful, it kills whatever monitoring you have set up.

[jdreed]

er, that first sentence should read:
... a tokens issue, where apps try to write data...

[mitchb]

Rebooting the workstation, if done with Ctrl-Alt-Del or with
the soft power button, will try SIGTERM first and do an
orderly shutdown. SIGKILL only happens if your program doesn't
clean itself up in several seconds.

[jdreed]

OK, having gathered data for about a week, the issue is indeed tokens. Once your tokens have expired, you cannot be logged out, unless you have _nothing_ open in AFS (other than the cwd of a shell).

So, I assert that we replace the gconf key for logout_command with something that checks for tokens, and if it finds them, runs gnome-session-save --force-logout, or if it doesn't, that SIGKILL's gdm or something. Once your tokens have expired, you have, by definition, lost data, so we don't have to be graceful.

[jdreed]

Aha! I don't know why I didn't think of this sooner. The problem is tokens, but specifically that GNOME is waiting for input. Here's a good test:

• Log in
• Start Ooffice
• Type some stuff into Writer, save it in your homedir
• Add some more text to your document, but don't save it.
• unlog
• pkill gnome-session

You'll get a dialog like  this one (you get the same dialog with gnome-session-save --force-logout) . I bet that's what's happening on the cluster machines. Can we convince whoever is responsible for that dialog that we don't want it? (Sending SIGKILL to gnome-session does in fact force the logout, regardless).

[jdreed]

whoever is responsible for that dialog

That would be gnome-session (specifically gsm-inhibit-dialog.c), and no, we don't get to get rid of it without invasive measures. Therefore, I formally propose that we replace logout_command with something that checks for tokens, runs gnome-session-save if it finds them, and runs pkill schroot if it doesn't.

[jdreed]

r25002

[jdreed]

Potentially bad idea: We could mail the user and tell them they were booted.

[jdreed]

Upload to to dev. It works, but tends to end up rebooting the machine (which reactivate will do if things are hanging around) I _think_ this is an improvement...