Bug 67605 - shut down gconfd on logout
shut down gconfd on logout
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: GConf (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
: Triaged
: 75895 (view as bug list)
Depends On:
Blocks: 79579 CambridgeTarget
  Show dependency treegraph
 
Reported: 2002-06-27 23:04 EDT by Red Hat Bugzilla
Modified: 2008-03-13 15:18 EDT (History)
3 users (show)

See Also:
Fixed In Version: gnome-session-2.5.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-22 12:47:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Evil hack to get around AFS locking problems (900 bytes, patch)
2002-07-01 13:51 EDT, Red Hat Bugzilla
no flags Details | Diff

  None (edit)
Description Red Hat Bugzilla 2002-06-27 23:04:30 EDT
Description of Problem:
Gconf assumes it can write to your home directory after you log out.  If you are
using kerberos/AFS/some fancy shared home directory system the user will not
have access rights to his home directory after he logs out and krb tickets/AFS
tokens are destroyed.


Version-Release number of selected component (if applicable):
GConf-1.0.9-4

How Reproducible:
always

Steps to Reproduce:
1. put your home dir in AFS
2. log out
3. 

Actual Results:


Expected Results:


Additional Information:
I'm not going to complain too bitterly about AFS + GConf + file locking, but
lets just say that my GConf doesn't do file locking anymore.  Applied patches
can be made availible.
Comment 1 Red Hat Bugzilla 2002-07-01 13:51:44 EDT
Created attachment 63268 [details]
Evil hack to get around AFS locking problems
Comment 2 Red Hat Bugzilla 2002-07-01 14:00:39 EDT
More information:

Below is a snippet of syslog of what happens on log out.  I am not calling unlog
hoping that the PAG will stay around with the gconf daemon so that it might have
a chance of writing to my home dir.  The write still fails as my authentication
has still been removed.  

I have attached my patch to gconf to help with AFS locking being dirty like
zebra.  The syslog bits do show off some fun locking mess.  AFS bugginess aside,
I don't think it is a safe asumption that you can write to a user's home
directory after they have logged out.

The following occures several minutes after I logout via gnome's logout thingie.

Jul  1 13:25:39 rk-test gconfd (jjneely-10353): Failed to open saved state file:
Failed:  Failed to open gconfd logfile; won't be able to restore listeners after
gconfd shutdown (Permission denied)
Jul  1 13:25:39 rk-test last message repeated 5 times
Jul  1 13:25:39 rk-test gconfd (jjneely-10353): GConf server is not in use,
shutting down.
Jul  1 13:25:39 rk-test gconfd (jjneely-10353): Could not open saved state file
'/ncsu/jjneely/.gconfd/saved_state.tmp' for writing: Permission denied
Jul  1 13:25:39 rk-test gconfd (jjneely-10353): Failed to give up lock on XML
dir `/ncsu/jjneely/.gconf': We didn't have the lock on file
`/ncsu/jjneely/.gconf/%gconf-xml-backend.lock/ior', but we should have
Jul  1 13:25:39 rk-test kernel: afs: failed to store file (13)
Jul  1 13:25:39 rk-test gconfd (jjneely-10353): Error releasing lockfile: We
didn't have the lock on file `/ncsu/jjneely/.gconfd/lock/ior', but we should have
Jul  1 13:25:39 rk-test gconfd (jjneely-10353): Exiting
Jul  1 13:25:39 rk-test kernel: afs: failed to store file (13) 
Comment 3 Red Hat Bugzilla 2002-07-01 14:36:27 EDT
Well, disabling the locking is going to cause problems; if you get two gconfd
processes running at once, it gets ugly.

You might have a look at:
http://www.gnome.org/projects/gconf/
http://bugzilla.gnome.org/show_bug.cgi?id=84101

Comment 4 Red Hat Bugzilla 2002-07-25 19:40:13 EDT
My home directory is in NFS.  If I log out and immediately reboot
my system (or if I click on "Log Out" and select the Reboot check
box), gconfd prevents the system from unmounting /home (and /usr if
it is also NFS mounted).
 
This causes old lock files to pile up in the .gconf and .gconfd
subdirectories of my home directory.

gconfd needs to be cleanly killed during log out processing.
Comment 5 Red Hat Bugzilla 2002-12-19 18:57:30 EST
*** Bug 75895 has been marked as a duplicate of this bug. ***
Comment 6 Red Hat Bugzilla 2003-05-04 21:22:20 EDT
This is still a problem in RH9.  GRRR.  GNASH! ;)


Comment 7 Red Hat Bugzilla 2003-10-26 20:56:35 EST
This is still a problem with GConfd2-2.4.0-1 and presents a major problem with
automatically mounted home directories.

In addition, when using GNOME 2.4, there are four new programs that seem to hang
around unwelcome for a while after logging out.  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?)

Couldn't gnome-session or some other program simply send a signal to gconfd-2
(and these other new problem children) when a user logs out?  Gconfd-2 could
simply handle the signal by exiting gracefully.  I could write a patch if
someone gave me a satisfactory technique.

As also mentioned in bug #79579 this bug makes it very difficult to unmount a
home directory when a user logs out:

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.

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
Comment 8 Red Hat Bugzilla 2003-10-31 12:26:30 EST
This also exists as GNOME bug number 97361
(http://bugzilla.gnome.org/show_bug.cgi?id=97361).  I submitted a patch against
this GNOME bug report that causes gnome-session to shutdown gconfd-2 when a user
logs out.
Comment 9 Red Hat Bugzilla 2004-02-17 14:44:38 EST
I am going to focus on fixing this using GNOME bugzilla.  Technically,
this bug is fixed because gnome-session now shuts down gconfd
properly.  However, several other processes cause the same problem.  See:

http://bugzilla.gnome.org/show_bug.cgi?id=134666
http://bugzilla.gnome.org/show_bug.cgi?id=134668
http://bugzilla.gnome.org/show_bug.cgi?id=134667

I am going to mark this bug as resolved.
Comment 10 Red Hat Bugzilla 2004-03-22 12:47:49 EST
Closing as fixed in Raw Hide. Its been fixed since gnome-session-2.5.3-1.

Note You need to log in before you can comment on or make changes to this bug.