Re: gconfd errors w/nfs mounted homedirs

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes:  
> what is the change notification feature? What does it buy me the
> sysadmin and what does it do for my users? What is wrong with just a
> config file? Most of the things in gnome's config seems to be a
> relatively simple config file - human readable and editable. I've
> noticed that evolution's config is base64 encoded (I think) and that has
> lead to some frustration for me b/c I can't grep through it as easily
> for something I want to change from a script.

Evolution doesn't use gconf at the moment. The default gconf backend
is text files.

You can also use "gconftool" to change things from shell scripts.
 
> Would it be possible to make gconfd support an option? Put it someplace
> in /etc, so I could toggle it off. The problem I have right now is if my
> users login on two systems its almost entirely unusable. Or if the
> system locks up for some reason and they attempt to login after it comes
> back up; the lock is still outstanding in ~/.gconfd/lock and they can't
> access their normal apps until they remove that lock/ dir.

I just don't think adding an option is the right way to fix bugs. The
issue with two systems is AFAIK addressed for the simple case by
enabling TCP/IP and the problem with system lockup is a bug in Red Hat
7.2 and possibly other distributions where they don't release locks
post-unnatural-system-death. (The way it's supposed to work is that
the NFS client releases its previously-held locks when it comes back
up. This is the way NFS works.)

So both of those things can/should be fixed. Galeon and Nautilus are
the first apps to try this setup, the technology is very new.

We may well need to move to the ACAP-server style solution for
networks like yours. It's a reasonably large implementation task
but not herculean by any means. One person could do it.

(I wouldn't actually use ACAP I don't think, though I might. I'd
probably go with a simpler custom protocol. Nothing speaks ACAP anyway
so following the RFC is sort of pointless.)

Anyhow, to answer the question, no gconfd support can't really be made
optional, the software depends on it working.

> If gconf could notice a stale lock and remove it then the latter
> problem would go away.

Unfortunately if the kernel says the lock exists there isn't any way
for gconf to detect that the kernel is on crack (if there were, the
kernel could do the same detection, there's no reason gconf can do
better).
 
At least, no way that I know of.

> Or would it be horrible to do something like wu-imap does? ie: if two
> sessions attempt to lock the same file the newest connection wins and
> the older connection gets a popup saying "no more write access to this
> file, you need to logout and back in to reenable it." I guess that is
> the perk of ACAP b/c a single server on a single port negotiates who has
> access to what and when.

Right, an ACAP-style gadget would make this easier. I can imagine
implementing it somehow for the current setup (maybe a protocol that
involves one process writing a magic file and other processes polling
for the existence of said file... I dunno it'd get weird).
 
> Hell, maybe just making the "gconfd has a locking problem and the
> "galeon cannot find its schema" errors to tell the user something more
> useful would be enough.

That's certainly true. I've added more info to the Galeon FAQ recently
(though I don't think they've copied that info to the Galeon web
site), and as I said added the small app that sanity-checks gconf on
login. I also want to make that app offer to fix common issues.

Additionally I've been reworking a new session manager, which would
know about multiple logins and could implement various UIs for
this. But I don't know when that will be deployed.


The UI advancements from gconf are very nice, at least according to
the UI expert types on the GNOME team, and the ability to do things
like set up (and lock down) systemwide defaults is much enhanced. If
you've seen the Windows XP config editor thingy, the idea is much the
same (docs for each setting, etc.) - though we had the idea before XP
was out, of course!

Havoc