I have been having some trouble with gconfd-2 (currently using GConf2-2.4.0 from RawHide PPC) for quite some time. I tried to get some discussion going on Red Hat's Bugzilla quite a while ago but nothing really came of it. I'd be willing to work on a patch, but I'd like to come to consensus on the technique we should use to fix the problem. I thought perhaps I would try this forum.
The gconfd-2 daemon is run by many GNOME applications to manage configurations. Gconfd-2 remains running for some time after the application which used it quits. This allows other applications to use gconfd-2 without having to start and stop the daemon too much. This is a good idea.
The problem comes when a system tries to unmount a user's home directory when the user logs out. For example, pam_mount unmounts an encrypted home directory then I log out of my system. Other people use NFS or other means to mount home directories.
Gconfd-2 continues to run even when a user logs out. This causes the unmounting of the user's home directory to fail because gconfd-2 keeps the following files open:
/home/user/.gconfd/saved_state
In addition, when using GNOME 2.4, there are four new programs that seem to hang around unwelcome for a second after logging out (at least they are still around when PAM session closing code is run). This is partially documented in bug #106826. The four programs are:
bonobo-activation-server (home direcotry remains open as CWD?) gnome-settings-daemon (home direcotry remains open as CWD?) xscreensaver -nosplash (home direcotry remains open as CWD?) mapping-daemon (home direcotry remains open as CWD?)
Red Hat Bugzilla bugs #67605, #75895 and #106826 comment more on this problem.
-- Mike
On Thu, 2003-10-30 at 13:32, mike@flyn.org wrote:
The problem comes when a system tries to unmount a user's home directory when the user logs out. For example, pam_mount unmounts an encrypted home directory then I log out of my system. Other people use NFS or other means to mount home directories.
I think the simple solution is to exec "gconftool-2 --shutdown" as the last thing gnome-session does before exiting, or perhaps even in the X scripts in xinitrc. If you wrote and tested a patch along those lines it'd be useful.
Another possible solution is to have an X server monitor process for gconfd; basically gconfd would fork/exec a tiny little program that simply connects to the X server and sits there, exiting when it loses the X connection. gconfd would then exit when this program exits. This is conceivably a more robust approach and still pretty easy to implement.
Havoc
The problem comes when a system tries to unmount a user's home directory when the user logs out. For example, pam_mount unmounts an encrypted home directory then I log out of my system. Other people use NFS or other means to mount home directories.
I think the simple solution is to exec "gconftool-2 --shutdown" as the last thing gnome-session does before exiting, or perhaps even in the X scripts in xinitrc. If you wrote and tested a patch along those lines it'd be useful.
Another possible solution is to have an X server monitor process for gconfd; basically gconfd would fork/exec a tiny little program that simply connects to the X server and sits there, exiting when it loses the X connection. gconfd would then exit when this program exits. This is conceivably a more robust approach and still pretty easy to implement.
Your second solution may be something that could be generalized to be quite useful -- perhaps freedesktop.org material? Other projects, like the venerable esd, have problems similar to gconfd. Esd can lock down a system's audio device for a while after a user logs out. I'll have to spend a little time looking at xscreensaver, gnome-settings-daemon, etc.
Your first solution seems simple enough. I included a very unsophisticated patch that performs the task (vs. gnome-session 2.4.0). Comments?
============================================================================== diff --recursive -u gnome-session-2.4.0-vanilla/gnome-session/main.c gnome-session-2.4.0/gnome-session/main.c --- gnome-session-2.4.0-vanilla/gnome-session/main.c 2003-08-13 07:58:52.000000000 -0500 +++ gnome-session-2.4.0/gnome-session/main.c 2003-10-30 17:01:04.000000000 -0600 @@ -481,6 +481,15 @@ #endif }
+/* Ensure gconfd-2 is shutdown when a user logs out so the user's $HOME + * may be unmounted if appropriate + */ +static void gconfd_shutdown (void) +{ + char *argv[] = { "gconftool-2", "--shutdown", NULL }; + gnome_execute_async (NULL, 2, argv); +} + int main (int argc, char *argv[]) { @@ -634,6 +643,8 @@
clean_ice ();
+ gconfd_shutdown (); /* in case home needs to be unmounted on logout */ + /* If a logout command was set, the following will not return */ execute_logout (); ==============================================================================
On Thu, 2003-10-30 at 19:56, W. Michael Petullo wrote:
Your second solution may be something that could be generalized to be quite useful -- perhaps freedesktop.org material? Other projects, like the venerable esd, have problems similar to gconfd. Esd can lock down a system's audio device for a while after a user logs out. I'll have to spend a little time looking at xscreensaver, gnome-settings-daemon, etc.
My eventual thought is that dbus could perform this function; the per-session message bus is tied exactly to the lifetime of the user's session, and thus performs the same function as the X server. (Most apps exit on logout because they lose their X server connection.) dbus itself already has a mechanism where it can be tied to the X server lifetime or the login session's pty.
Your first solution seems simple enough. I included a very unsophisticated patch that performs the task (vs. gnome-session 2.4.0). Comments?
It looks sane to me, thanks. I'd file it on bugzilla.gnome.org, and also make a bugzilla.redhat.com bug with a link to the gnome.org bug (or use an existing bug if someone already opened it) to remind us to backport the patch if needed, since we'll probably still be on GNOME 2.4 in the next Fedora Core release. We could also do a bugfix update to Fedora Core 1 once the freeze is over.
Havoc
Your second solution may be something that could be generalized to be quite useful -- perhaps freedesktop.org material? Other projects, like the venerable esd, have problems similar to gconfd. Esd can lock down a system's audio device for a while after a user logs out. I'll have to spend a little time looking at xscreensaver, gnome-settings-daemon, etc.
My eventual thought is that dbus could perform this function; the per-session message bus is tied exactly to the lifetime of the user's session, and thus performs the same function as the X server. (Most apps exit on logout because they lose their X server connection.) dbus itself already has a mechanism where it can be tied to the X server lifetime or the login session's pty.
Very nice.
Your first solution seems simple enough. I included a very unsophisticated patch that performs the task (vs. gnome-session 2.4.0). Comments?
It looks sane to me, thanks. I'd file it on bugzilla.gnome.org, and also make a bugzilla.redhat.com bug with a link to the gnome.org bug (or use an existing bug if someone already opened it) to remind us to backport the patch if needed, since we'll probably still be on GNOME 2.4 in the next Fedora Core release. We could also do a bugfix update to Fedora Core 1 once the freeze is over.
I attached the patch to GNOME Bugzilla #97361 and mentioned the GNOME report in Red Hat Bugzilla #67605. I'd really like to see a fix in Fedora once it thaws.
We've made some progress getting gconfd-2 to exit when a user logs out (see "gconfd-2 does not exit when a user log out, breaks unmounting home" thread). Now I am interested in turning my attention to some other processes that seem to loiter around after one logs out of a GNOME 2.4.0 session.
Pam_mount performs an lsof that claims the processes are still running when pam_close_session is called, but the processes are gone after the user is completely logged out (Unlike gconfd-2, which stayed running for two minutes).
The following processes hang around (with $HOME as their CWD):
bonobo-activation-server gnome-settings-daemon xscreensaver mapping-daemon
While investigating these four processes, I have gotten myself very confused.
First, on my system, pstree says:
init-+-aio/0 |-atd ... |-bonobo-activati ... |-gdm-binary---gdm-binary-+-X | `-gnome-session---ssh-agent |-gnome-panel |-gnome-settings-daemon ...
Why is init the parent process of /usr/libexec stuff like bonobo-activation-server? How does that happen?
Why does gnome-panel not have gnome-session as its parent?
At first I thought that things like login and gdm sent HUP signals to children when a user logs out. I had forgotten that it was in fact the shell that performs this magic. So my idea of ensuring that gdm kill -HUP'd all of a user's programs before calling pam_close_session was faulty.
The processes do seem to get killed (but after pam_close_session code) but I'm not sure by what means. Could someone shed some light on this or nudge me in the right direction for some documentation?
I'd really like to fix pam_mount/gdm/GNOME.
We've made some progress getting gconfd-2 to exit when a user logs out (see "gconfd-2 does not exit when a user log out, breaks unmounting home" thread). Now I am interested in turning my attention to some other processes that seem to loiter around after one logs out of a GNOME 2.4.0 session.
Pam_mount performs an lsof that claims the processes are still running when pam_close_session is called, but the processes are gone after the user is completely logged out (Unlike gconfd-2, which stayed running for two minutes).
The following processes hang around (with $HOME as their CWD):
bonobo-activation-server gnome-settings-daemon xscreensaver mapping-daemon
While investigating these four processes, I have gotten myself very confused.
First, on my system, pstree says:
init-+-aio/0 |-atd ... |-bonobo-activati ... |-gdm-binary---gdm-binary-+-X | `-gnome-session---ssh-agent |-gnome-panel |-gnome-settings-daemon ...
Why is init the parent process of /usr/libexec stuff like bonobo-activation-server? How does that happen?
Why does gnome-panel not have gnome-session as its parent?
At first I thought that things like login and gdm sent HUP signals to children when a user logs out. I had forgotten that it was in fact the shell that performs this magic. So my idea of ensuring that gdm kill -HUP'd all of a user's programs before calling pam_close_session was faulty.
The processes do seem to get killed (but after pam_close_session code) but I'm not sure by what means. Could someone shed some light on this or nudge me in the right direction for some documentation?
I'd really like to fix pam_mount/gdm/GNOME.
Okay, I just realized that having the X server stopped will cause X applications like xscreensaver to exit (duh). Gdm kills X when a user logs out and I think I can ensure this happens before pam_close_session is called.
But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent?
On Fri, Oct 31, 2003 at 06:33:41PM -0600, W. Michael Petullo wrote:
But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent?
Reparenting.
When a child process's parent dies, but the child lives on, init becomes the child's new parent.
Does that help?
-Barry K. Nathan barryn@pobox.com
We've made some progress getting gconfd-2 to exit when a user logs out (see "gconfd-2 does not exit when a user log out, breaks unmounting home" thread). Now I am interested in turning my attention to some other processes that seem to loiter around after one logs out of a GNOME 2.4.0 session.
Pam_mount performs an lsof that claims the processes are still running when pam_close_session is called, but the processes are gone after the user is completely logged out (Unlike gconfd-2, which stayed running for two minutes).
The following processes hang around (with $HOME as their CWD):
bonobo-activation-server gnome-settings-daemon xscreensaver mapping-daemon
Modifying gdm to kill X before running pam_close_session() seems to fix my problem with xscreensaver and gnome-settings-daemon. Right now gdm does things in the opposite order. I should have a decent patch for the gdm folks soon.
Further patching gnome-session to run bonobo-slay rids me of the loitering bonobo-activation-server process. Are their any objections to this?
I'm not sure about the mapping-daemon process. Apparently it is a component of the nautilus-cd-burner package. There does not seem to be a nice facility for causing the process to quit. From looking at mapping-daemon.c, it appears that the daemon wakes up every 5000us, checks to see if it has any client nautilus processes and exits if it does not. So my modified gdm kills X/nautilus and then runs pam_close_session in less than 5000us.
Does anyone have a suggestion for mapping-daemon?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
W. Michael Petullo writes:
I'm not sure about the mapping-daemon process. Apparently it is a component of the nautilus-cd-burner package. There does not seem to be a nice facility for causing the process to quit. From looking at mapping-daemon.c, it appears that the daemon wakes up every 5000us, checks to see if it has any client nautilus processes and exits if it does not.
Are you certain that's every 5000us, as in microseconds?
So this process wakes up, and runs a code loop *every 5 milliseconds*?! That'd be horrific for load, if so.
- --j.
I'm not sure about the mapping-daemon process. Apparently it is a component of the nautilus-cd-burner package. There does not seem to be a nice facility for causing the process to quit. From looking at mapping-daemon.c, it appears that the daemon wakes up every 5000us, checks to see if it has any client nautilus processes and exits if it does not.
Are you certain that's every 5000us, as in microseconds?
So this process wakes up, and runs a code loop *every 5 milliseconds*?! That'd be horrific for load, if so.
Yes, I was three orders of magnitude off. Mapping-daemon uses g_timeout_add to check for remaining clients every 5000 /milliseconds/ (or less often if higher priority stuff is processing).
The result still seems to be that mapping-daemon contines to execute when gdm calls pam_close_session.
On Fri, 2003-10-31 at 19:33, W. Michael Petullo wrote:
But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent?
When doing a fork/exec, GLib programs usually use the g_spawn_ family of functions; these fork twice, creating an intermediate child process that immediately exits and is reaped by the parent. The purpose is to avoid zombies, as usually in a GUI context parent/child doesn't mean much. (e.g. say Evolution launches your web browser there's no point really having the browser be a child of evolution)
Havoc
We've made some progress getting gconfd-2 to exit when a user logs out (see "gconfd-2 does not exit when a user log out, breaks unmounting home" thread). Now I am interested in turning my attention to some other processes that seem to loiter around after one logs out of a GNOME 2.4.0 session.
Pam_mount performs an lsof that claims the processes are still running when pam_close_session is called, but the processes are gone after the user is completely logged out (Unlike gconfd-2, which stayed running for two minutes).
The following processes hang around (with $HOME as their CWD):
bonobo-activation-server gnome-settings-daemon xscreensaver mapping-daemon
But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent?
When doing a fork/exec, GLib programs usually use the g_spawn_ family of functions; these fork twice, creating an intermediate child process that immediately exits and is reaped by the parent. The purpose is to avoid zombies, as usually in a GUI context parent/child doesn't mean much. (e.g. say Evolution launches your web browser there's no point really having the browser be a child of evolution)
Thanks to all who explained. There is also a mail thread from 2000 on gnome-devel-list titled "Process Tree."
I updated the gconfd-2-killing gnome-session patch I have submitted to GNOME's bugzilla to use execvp/waitpid instead of gnome_execute_async. Is there a more GNOME/glib-happy way to wait for a forked process?
I also send the following very simple patch to the gdm folks. It fixes my problem with X programs hanging around when pam_close_session is called, but I'm not sure if it would break anything else. Here it is:
diff -u --recursive gdm-2.4.4.5-vanilla/daemon/slave.c gdm-2.4.4.5/daemon/slave.c --- gdm-2.4.4.5-vanilla/daemon/slave.c 2003-10-16 11:38:45.000000000 -0500 +++ gdm-2.4.4.5/daemon/slave.c 2003-11-03 11:19:31.000000000 -0600 @@ -864,6 +864,8 @@ gdm_slave_quick_exit (DISPLAY_REMANAGE); } } + + gdm_verify_cleanup (d); } /* very very very evil, should never break, we can't return from here sanely */ @@ -4132,8 +4134,6 @@ /* things are going to be killed, so ignore errors */ XSetErrorHandler (ignore_xerror_handler);
- gdm_verify_cleanup (d); - in_session_stop --;
if (need_to_quit_after_session_stop) {
We've made some progress getting gconfd-2 to exit when a user logs out (see "gconfd-2 does not exit when a user log out, breaks unmounting home" thread). Now I am interested in turning my attention to some other processes that seem to loiter around after one logs out of a GNOME 2.4.0 session.
Pam_mount performs an lsof that claims the processes are still running when pam_close_session is called, but the processes are gone after the user is completely logged out (Unlike gconfd-2, which stayed running for two minutes).
The following processes hang around (with $HOME as their CWD):
bonobo-activation-server gnome-settings-daemon xscreensaver mapping-daemon
But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent?
When doing a fork/exec, GLib programs usually use the g_spawn_ family of functions; these fork twice, creating an intermediate child process that immediately exits and is reaped by the parent. The purpose is to avoid zombies, as usually in a GUI context parent/child doesn't mean much. (e.g. say Evolution launches your web browser there's no point really having the browser be a child of evolution)
Thanks to all who explained. There is also a mail thread from 2000 on gnome-devel-list titled "Process Tree."
I updated the gconfd-2-killing gnome-session patch I have submitted to GNOME's bugzilla to use execvp/waitpid instead of gnome_execute_async. Is there a more GNOME/glib-happy way to wait for a forked process?
I also send the following very simple patch to the gdm folks. It fixes my problem with X programs hanging around when pam_close_session is called, but I'm not sure if it would break anything else. Here it is:
[...]
These problems still exist in Fedora Core 2 Test 1.
Though gconfd-2 seems to have been resolved, the following processes still have problems quiting when a user logs out:
bonobo-activation-server keeps $HOME open as its CWD (libbonobo-2.5.3-1) gnome-vfs-daemon keeps $HOME open as its CWD (gnome-vfs2-2.5.7-1) mapping-daemon keeps $HOME open as its CWD (nautilus-cd-burner-0.6.5-1) gnome-settings-daemon?
All of these processes make unmounting $HOME on logout difficult.
See also:
http://bugzilla.gnome.org/show_bug.cgi?id=97361 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=67605
Havoc Pennington wrote:
I think the simple solution is to exec "gconftool-2 --shutdown" as the last thing gnome-session does before exiting, or perhaps even in the X scripts in xinitrc. If you wrote and tested a patch along those lines it'd be useful.
Another possible solution is to have an X server monitor process for gconfd; basically gconfd would fork/exec a tiny little program that simply connects to the X server and sits there, exiting when it loses the X connection. gconfd would then exit when this program exits. This is conceivably a more robust approach and still pretty easy to implement.
Couldn't you also connect gconfd2 to the session manager? That would be more portable to systems which don't use X11, no?
On Thu, 2003-10-30 at 22:07, Gordon Messmer wrote:
Couldn't you also connect gconfd2 to the session manager? That would be more portable to systems which don't use X11, no?
Well, basically I don't care about those. ;-) The number of systems using the X Session Management Protocol but not X11 is pretty limited. And what we're talking about here is a short-term hack so why overengineer it.
No need to confuse gnome-session any more than it already is (http://mail.gnome.org/archives/desktop-devel-list/2003-April/msg00090.html)
Havoc
-
Barry K. Nathan -
Gordon Messmer -
Havoc Pennington -
Justin Mason -
W. Michael Petullo