From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 Galeon/1.3.17 Description of problem: There have been a few cases where on multiuser machines gconfd-2 has continued to run even though the user has logged out of X and no other processes with the same uid as gconfd-2 are running. Version-Release number of selected component (if applicable): GConf2-2.8.1-1 How reproducible: Didn't try Steps to Reproduce: 1. Unknown (I am only seeing the aftermath) but presumably log in and log out of Gnome. 2. Do a ps auxw | grep [2]3022 (23022 is the uid of the user with the errant gconfd-2) Actual Results: 23022 10573 0.0 0.6 7560 1540 ? S Dec07 0:00 /usr/libexec/gconfd-2 9 Expected Results: No matching processes to be found. Additional info: This is very intermitant and certainly doesn't happen every time. It is unknown what causes this or why gconfd-2 hasn't quit. Home directories are mounted on an NFS share. Part of the growing family of "...continues to run after X has exited" bugs (see bug #138249, bug #139372, bug #139834, bug #140262). Not devastating but annoying on multi user desktops.
(sorry for the long unwrapped lines - I was using the Beta bugzilla)
Can you confirm some things for me: 1) If you actually log out using the "Log Out" button rather than by killing X with Ctrl-Alt-Backspace, it quites immediately 2) It always quits eventually (I think it should be after 30 seconds) 3) It doesn't actually cause you any serious problems
1) I can't do this because I am away from FC3 machines until after Christmas (I suppose I could use VNC...) 2) It never quits. You can wait seemingly days with only gconfd running and it will hang around indefinitely. 3) It never causes any noticible problems (did I accidently set the severity on this bug? If so I apologise). I do have a 100% reproducable case using ssh forwarded program though (although this is obviously not a full log in) which always left gconfd running forever even after the original program exited. This may or may not be related to this problem.
This stayed in the NEEDINFO status despite my adding a comment due to a (reported) bug in the beta bugzilla. I can now answer 1) too: 1) If I log out using the "Log Out" button gconfd quits immediately (at least all the times I have checked). I still have that testcase involving ssh and ggv that shows the problem though.
I'm not sure this fits in, but I had a problem today with FC3 that might help to reproduce this problem with gconfd-ngadamri. [using a pre-existing Debian /home with a user ngadamri having uid 1000 gid 1000] *install and login with the user created at install [uid 500, gid 500] *realized that it doesn't to well because of existing file permissions *logout *as root, manually change /etc/passwd and /etc/group -> uid 500, gid 500 to uid 1000, gid 1000 *kill X (CTRL-ALT-BACKSPACE) *try to log back in - lots of permissions denied on /tmp/gconfd-ngadamri/*, toolbar won't start *notice that gconf.d is running as a process with uid 500, gid 500! *reboot *same errors, logout *chown -R 1000:1000 /tmp/gconfd-ngadamri *able to log back in, but logging out is very very slow. Very strange, I wouldn't have expected so many problems doing this simple uid/gid change.
This seems to happen with gconfd-2 on Enterprise-4. I can usually create a lingering gconfd-2 like this: 1) Log in to machine from a remote terminal (eg I used a Windows machine with XStart using ssh protocol). 2) Run a graphical application which runs gconfd-2 (I ran firefox). 3) Quit the application. 4) Do a ps -u <user> and you'll notice gconfd-2 running. If you log out and log in again, it's still running. 5) This doesn't seem to be a problem when I log in directly on the machine but only when I do remote connections and run x-applications remotely. I'm just curious, is it a problem if lots of these are lingering by different users or they basically harmless? Thank you
It _seems_ to be harmelss. One thing to note though is that there aren't any other programs keeping gconf open. For example things like gnome-keyring and esd often remain open and jam gconf open too.
This is still here in FC4 GConf2-2.10.0-4 . Updating version.
GConf also stays open on our system, and this persistance seems to be the cause of an annoying probem: sometimes when users login to a new GNOME session, they see only the blue background and a cursor. The splash screen and desktop never come up. I come to the conclusion that the login stall is GConf's fault two ways: 1. "rm -rf /tmp/gconfd-usernamefoo/" solves the problem 2. killing the user's gconfd-2 process solves the problem However, sometimes although gconfd-2 is running, users can login without the stall. Also, I notice one user has 6 gconfd-2 processes running now, and he isn't even logged in. The dates of the processes go back to Nov 15. System: - Fedora Core 4, x86 32-bit - GConf2-2.10.0-4 - /home on NFS - all sessions either remote X or VNC - users often disconnect by turning off power to their terminals
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Just did a quick check on this and a bunch of FC6 machines are not showing any stray gconf-2 processes. Resolving FIXED.