Bug 142266 - gconfd-2 continues to run after X has exited
gconfd-2 continues to run after X has exited
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: GConf2 (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-08 12:30 EST by Sitsofe Wheeler
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: GConf2-2.14.0-8.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-24 12:22:50 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)

  None (edit)
Description Sitsofe Wheeler 2004-12-08 12:30:10 EST
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.
Comment 1 Sitsofe Wheeler 2004-12-08 12:31:08 EST
(sorry for the long unwrapped lines - I was using the Beta bugzilla)
Comment 2 Mark McLoughlin 2004-12-20 08:50:59 EST
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
Comment 3 Sitsofe Wheeler 2004-12-20 12:46:16 EST
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.
Comment 4 Sitsofe Wheeler 2005-01-16 05:12:50 EST
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.
Comment 5 Ricky Ng-Adam 2005-02-09 15:46:56 EST
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.
Comment 6 Andrew D. 2005-03-05 13:36:33 EST
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
Comment 7 Sitsofe Wheeler 2005-03-08 03:31:15 EST
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.
Comment 8 Sitsofe Wheeler 2005-11-11 14:33:08 EST
This is still here in FC4 GConf2-2.10.0-4 . Updating version.
Comment 9 Andrew 2005-11-30 19:32:54 EST
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
Comment 10 Christian Iseli 2007-01-22 05:53:18 EST
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.
Comment 13 Sitsofe Wheeler 2007-02-24 12:22:50 EST
Just did a quick check on this and a bunch of FC6 machines are not showing any
stray gconf-2 processes. Resolving FIXED.

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