Bug 67605
| Summary: | shut down gconfd on logout | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Red Hat Bugzilla <bugzilla> | ||||
| Component: | GConf | Assignee: | Havoc Pennington <hp> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.3 | CC: | ericb, jroyse, redhat | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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 17:47:49 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 79579, 100644 | ||||||
| Attachments: |
|
||||||
|
Description
Red Hat Bugzilla
2002-06-28 03:04:30 UTC
Created attachment 63268 [details]
Evil hack to get around AFS locking problems
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) 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 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. *** Bug 75895 has been marked as a duplicate of this bug. *** This is still a problem in RH9. GRRR. GNASH! ;) 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 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. 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. Closing as fixed in Raw Hide. Its been fixed since gnome-session-2.5.3-1. |