GNOME Bugzilla – Bug 60697
Gnome session manager fails to kill program it starts
Last modified: 2014-12-15 20:57:27 UTC
Hi, Under the Gnome Control Center there is a list of programs that need to be started explicitly by the session manager at the start of the session because the program doesn't implement the session management communication conventions and thus won't get included as part of the session when it is saved. To this list I have added a program which talks to a modem and to esd but doesn't use X at all. When I log out the session manager does not kill this program so when I next log in a second copy is started, and so on. Since the program got started by the session manager when I log in, to my way of thinking the session manager should kill it again when the session finished (i.e. I log out) in the same way that processes using a terminal get a SIGHUP which kills them when the user logs out of a stardard terminal session. I suspect this has not come to light before because most programs that are added to this list of extra programs to start do use X and therefore get killed when the X server is reset. Nevertheless I think killing these programs is the session manager's job and hence this bug report. On a related point, I notice that the programs that get started by the session manager all appear to have init as their parent process whereas it would seem more logical if these retained gnome-session as the parent process - that way if a use if logged in more than once it would be possible to tell the two sessions appart.
Hmm, I think this is actually smproxy's job, but that's only a first guess. This needs to be looked at closely ...
*** Bug 2124 has been marked as a duplicate of this bug. ***
Bug 2124 had the GNOMEVER2.3 keyword, so I'm adding it here as well.
Has this changed in later releases?
In the Debian package I have included a patch to kill the esd process upon exit, but this is a crude hack. I can attach it if someone is interested.
FYI -- the init-as-parent thing is fixed by the patch in bug #101351. I think there are two possible resolutions to this bug. One is to write a simple wrapper program which connects to the session manager and runs a child process. Then, when the session manager exits, it would kill its child. Another idea is that, in conjunction with the proper parenting patch, gnome-session could make a new process group and, on exit, send SIGHUP to all members of that process group. This approach is a bit more general but also less flexible.
Created attachment 73821 [details] [review] patch to add gnome-session-wrapper program This patch adds a new "gnome-session-wrapper" program. This program can be used to wrap non-session-aware programs. It will manage them in a very simple way: it will start them, register itself with the session as appropriate, and when the session exits it will send the child a SIGHUP. This ought to suffice for programs that don't have session management capability (and never will).
Created attachment 73873 [details] [review] updated patch This is an updated patch which handles command-line option parsing correctly.
Looks great. We don't need to link to gtk+ though (although it might happen because of libgnome...). Using a GMainLoop should be enough.
I just followed existing style in that directory. E.g., see gsm-remove-client.c. I will update the patch when I have a chance.
Created attachment 74533 [details] [review] updated to use glib main loop I've updated the patch to use the glib main loop
Hi Tom, So is the idea that people would manually add the wrapper to the autostart desktop files? Should we add the wrapper automatically with gnome-session-properties?
Is there any reason gnome-session doesn't just call setpgrp() at startup and then kill its entire process group immediately before exiting?
In re #12: yeah, the idea is that the wrapper would be used by programs which are not and never will be session-aware themselves. Unfortunately this isn't a property you can auto-detect so adding it automatically seems difficult. In re #13: we could do that. My only reluctance is that we don't know all the ramifications of doing it. I suppose most programs that care will do something smart with SIGHUP already though.
Tom: do you think adding a checkbox to the "Edit startup program" dialog, stating "Is not session aware", would be enough? Then, users could easily use this feature. Not sure that enabling this for a session-aware program would be good, though ;-)
at this point I think we should close this bug... Applications that want to die when the session goes away can listen for the bus going away, or use the session management protocol, or listen for X going away... Furthermore, at some point, systemd will probably handle this by killing the whole cgroup. Reopen if you strongly disagree.