After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 75568 - GConf doesn't restart after a crash well
GConf doesn't restart after a crash well
Status: RESOLVED DUPLICATE of bug 107693
Product: GConf
Classification: Deprecated
Component: gconf
1.0.5
Other other
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-03-20 10:45 UTC by Ross Burton
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Ross Burton 2002-03-20 10:45:13 UTC 
If GConf is killed so that it doesn't die gracefull, the file
~/.gconfd/lock/ior is left behind.

With this file present starting gconfd results in no server, no error. 
Only by running "strace gconfd-1" can this problem be seen.  Removing this
file allows gconf to start correctly.

The server should have some way of detecting if this lock is a stale lock,
and display a message if it cannot safely delete it and start afresh.
Comment 1 Havoc Pennington 2002-03-20 13:27:36 UTC 
You should try gconf 1.0.9 or other recent versions. They come with a
gconf-sanity-check-1 app that will look for problems.

However even 1.0.5 I believe does log a message to syslog 
(user.* syslog though, off by default in Red Hat at least).

There is no way to detect stale locks though, and AFAIK they only
happen when an NFS client crashes or you pull the power cord. If you
know how to detect stale locks, please let me know - it's impossible
AFAIK.
Even the crash should not cause a problem, except that various 
Linux distributions have a bug in nfs-utils that keeps the NFS 
client from releasing its previously-held locks on restart.

You are using NFS, correct?
Comment 2 Ross Burton 2002-03-20 14:11:40 UTC 
We are actually using 1.0.7, the list of versions needs updating...

And yes, this is NFS...  :)  NFSv3 client, v2 server for laughs.

Would it be possible to put the PID of the gconf server in the lock,
and see if that PID exists/is actually GConf?  I don't know enough
about the locking architecture here so I might be talking garbage...
Comment 3 Havoc Pennington 2002-03-20 14:26:48 UTC 
The PID approach has several problems:
 - what if the gconfd is on another machine
 - there's an inherent race condition between checking 
   if the PID exists and deleting the possibly-stale lock
 - there's no portable way to see if a PID exists, I don't think
 - PIDs wrap around

Basically, if there were a way to catch the stale locks, the kernel 
would do it. ;-) Stale locks are caused by the NFS server telling the
kernel that the lock is held - and gconfd has no more information than
the kernel does, so trust what it's told by the kernel.

I think if the bug in nfs-utils is fixed, people won't see this issue
much.
Comment 4 Havoc Pennington 2003-03-06 03:46:00 UTC 

*** This bug has been marked as a duplicate of 107693 ***