GNOME Bugzilla – Bug 152907
Option for gdm to kill all user prosesses upon disconnects
Last modified: 2013-12-16 18:04:51 UTC
In a terminal/server environment with >100 terminals, using gdm/gnome it is unacceptable that userprocesses is not beeing killed upon user logout. There should be an option in gdm.conf to make gdm force-kill all user processes upon both: 1) Conventional logouts 2) Client disconnects (by e.g. a power cable pull). This would spare sysadmins to write PostSession scripts that did it (which may not even be run in the 2) case (see #152906)). The solution should not be to avoid running such ever-ongoing processes as a user, but rather the described option to make sure, the system is clean.
To support multi-user (where a user is logged in on the console & via XDMCP) the technique would need to be smart enough to know which user processes to kill.
Second this bug report, i battle it everyday on my linux terminalservers. Serving 300+ users.
I would be happy to accept a patch.
Note in daemon/slave.c, the gdm_server_whack_clients should kill all processes that have an X connection. Perhaps this function needs to be smarter, or also kill programs that don't use X and are children of the user session.
Some thoughts about this. The list below was made on my system during a typical session; only what I think are gnome related processes are listed (note, this is single user machine) : PGRP PID PPID CMD 5215 5215 1 /usr/sbin/gdm 5216 5216 5215 /usr/sbin/gdm 5221 5221 5216 /usr/X11R6/bin/X 5575 5575 5216 x-session-manager 5575 5617 1 /usr/bin/dbus-launch 5575 5620 1 /usr/lib/libgconf2-4/gconfd-2 6 5575 5623 1 /usr/bin/gnome-keyring-daemon 5575 5634 5575 /usr/bin/metacity 5575 5637 5575 gnome-panel 5575 5638 5575 nautilus 5575 5658 5575 update-notifier 5575 5661 5575 /usr/lib/evolution/2.10/evolution-alarm-notify 5575 5667 5575 nm-applet 5575 5668 5575 gnome-cups-icon 5575 5680 1 /usr/lib/nautilus-cd-burner/mapping-daemon 5575 5760 1 /usr/lib/firefox/firefox-bin 5575 5930 1 gnome-terminal 5575 5932 5930 gnome-pty-helper 5614 5614 5575 /usr/bin/ssh-agent 5618 5618 1 /usr/bin/dbus-daemon 5618 5625 1 /usr/lib/control-center/gnome-settings-daemon 5618 5649 1 /usr/lib/gnome-vfs-2.0/gnome-vfs-daemon 5646 5646 1 /usr/lib/bonobo-activation/bonobo-activation-server 5646 5682 1 /usr/lib/evolution/2.10/evolution-exchange-storage 5646 5695 1 /usr/lib/gnome-applets/mixer_applet2 5646 5698 1 /usr/lib/evolution/evolution-data-server-1.10 5650 5650 1 gnome-volume-manager 5669 5669 1 gnome-power-manager 5747 5747 1 gnome-screensaver As you can see we have: - The gdm "root" process (5215) - The gdm "slave" process (5216) - The X server processes (5221 and 5575), both children of gdm "slave". - A plethora of things, with the same PGRP as the PID of the x-session-manager. Not all of these are children of it. - the SSH agent, which, even if child of the x-session-manager has a PGRP equal to its PID. - Several others, all children of init. Now, how would you go about killing these many somewhat unrelated processes? How could one write a piece of code that scans the list of processes and recognise which are gnome related, and are killable? My first idea was to use the process group id and then with a simple call kills as many processes as possible. As you can see, this was somewhat optimistic. The only thing I can think right now is to modify the whole spawning logic. Whenever a process is spawned, it must be assigned a unique PGRP (for instance equal to the PID of the gdm "slave"process, which can be easily made available (perhaps it is already) as a global variable). This way, a single call to killpg() or kill(-slavePID,) will kill all spawning (even though the sequence and timing will be left to the OS or the specific API being used). Any idea!?
Sorry it took me some time to respond. This is ugly - I was hoping that the processes started by gnome-session would be properly attached to the program that started it. It looks like what is happening is that the process that starts these PPID=1 programs die and these processes end up getting inherited by PPID=1. This seems bad. Might be good to ping gnome-hackers and find out if this behavior is expected. If this is expected, is there any way to tell what processes on a system are associated with a given session. Want to ping gnome-hackers about this? Also note we can't simply kill all processes associated with the user since the user may be logged into multiple displays, or might have telnetted/rlogged into the system as well as having a session running. We really only want to kill processes associated with the session, if possible. If not possible, we can't kill anything. Well, we could kill the processes we know are children and hope that this causes the other processes to die, but this seems an incomplete solution.
I've asked to be subscribed to the list and waiting moderator's approval. Actually, I will be on holidays the next two weeks so it looks like this would anyhow have to wait a bit.
I've sent an email to the list but I've never seen it "published". Well, in the last 2 weeks I only received one email through this list. Is the list active at all?
Can confirm this bug, too. It's still there with GDM 2.19.3 and Gnome 2.19.4.
The right mail list is gdm-list@gnome.org for the GDM program. The list is fairly active, but 2 weeks can go by without an email. I do review all emails to the list that require moderators approval, and I don't remember seeing your email. Try again, and I'll be happy to approve it.
I see, this explains it. I sent it to gnome-hackers@gnome.org (at least this is the list I understood from your post #6). Will subscribe and send it now. Thanks.
logind supports this feature now without gdm really getting involved.