GNOME Bugzilla – Bug 97361
improve exit-gconfd-on-logout chances
Last modified: 2004-12-22 21:47:04 UTC
gconfd does not die with gnome-session. It usually receives a SIGHUP signal when the X display dies. For an unknown reason, this signal is not always received so it can happen that gconfd-2 survives the X server. This is not a big deal if you are running gnome on a single server because gconfd-2 can be reused by your next gnome session. On the other hand, this is problematic on systems with multiple servers because the lock created by gconfd-2 prevents gnome to be started on another server. One method I know to let gconfd-2 survive the X server is to kill it with 'gconftool-2 --shutdown' and then restart it with 'gconftool-2 --spawn'.
It should be dying after a short timeout, if no applications are using it.
I also saw that in the code. That probably solve my problem except that I have to educate the users to wait a few minutes before re-logging. Also, the 2 minutes timeout will only work if all clients are killed with the X server. You can't assume that peoples will not be using gconf in non graphical application that may survive the X session. It can also happen that an X application survives the X session (after a crash, in a VNC session, ...). My first idea was to 'gconftool-2 --shutdown' immediatly after gnome-session but I noticed that gnome-session does not kill all gcond clients when it dies. Is gconftool-2 --shutdown safe then? I am afraid that such approach could be worse that letting gconfd die by itself because if a gconf client is still running after the --shutdown but before the X server dies, then the client may just --spawn a new gconfd-2 instance to save its state. In this case you get a full 2 minutes timeout. A possible solution could be to start all gconfd-2 on a dedicated server. Enabling network socket should also work except that those daemons running all over the place are a nightmare for the sysadmin: can't reboot server A because it runs gconfd-2 for the gnome session of Bob on server B. That will happen all the time when you ask people to quit server B before reboot. People will logout and immediatly login on server A without waiting for the 2m timeout.
A --shutdown after logout should be fairly safe, it will just get restarted next time someone tries to use it; if no one is using it on the logout machine, then it should restart on a different machine. Truth be known "killall gconfd-2" is reasonably safe as well. On Red Hat Linux 8 you can also try the experimental GCONF_LOCAL_LOCKS patch described on http://www.gnome.org/projects/gconf/ Shortening the timeout to say 15 seconds might be pretty sane as well. In fact I thought I'd already cut it to 30 seconds, maybe that's just in CVS.
*** Bug 97651 has been marked as a duplicate of this bug. ***
*** Bug 108639 has been marked as a duplicate of this bug. ***
I changed the timeout to 30 seconds in CVS, but it's probably sort of a performance hit; it pings every gconf-using app on the desktop every 30 seconds. So a better solution would be good.
Created attachment 21099 [details] [review] Simple patch that causes gnome-session to shutdown gconfd-2 processes when a user logs out.
This bug still exists in gconfd-2 2.4.0. As documented in bug #97651, this bug also causes problems with unmounting remote home directories.
Mark - see this gnome-session patch.
Created attachment 21135 [details] [review] Simple patch that causes gnome-session to shutdown gconfd-2 /and/ bonobo-activation-server processes when a user logs out.
Created attachment 21167 [details] [review] Same patch, but uses execvp/waitpid instead of gnome_execute_async.
What's the problem you're trying to solve using execvp() directly? The function you _really_ want is probably g_spawn_async() (or even the synchronous one, to avoid a race condition on the homedir unmount).
I've committed a patch similar to this on gnome-session HEAD. Note, I've gone with a synchronous shutdown even though I'm worried about logout hanging because of random problems ... if we see problems like this we should switch back to async. Also, I haven't included the bonobo-activation shutdown bit, because I don't see how that affects the home dir and because it requires much more though. gconftool-2 --shutdown is safe ... bonobo-slay certainly isn't.
Created attachment 22019 [details] [review] patch which I committed
This bug still exists in gnome-session-2.5.3 and GConf2-2.5.1. Though gconfd-2 is shut down correctly, the following processes are not: bonobo-activation-server remains with $HOME as its CWD (libbonobo) gnome-vfs-daemon remains with $HOME as its CWD (gnome-vfs2) mapping-daemon (sometimes) remains with $HOME as its CWD (nautilus-cd-burner) These problems continue to cause unmounting $HOME difficult. Perhaps this bug should be filed under another package? Gnome-session? Or maybe split it into individual bug reports for libbonobo, gnome-vfs2 and nautilus-cd-burner?
Yes, please open new bugs for each process which is causing problems. Easier to track progress that way. Thanks ...