SCIENTIFIC-LINUX-USERS Archives

December 2005

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jan Iven <[log in to unmask]>
Reply To:
Date:
Fri, 16 Dec 2005 09:10:57 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
On Thu, 2005-12-15 at 13:29 -0600, Ken Teh wrote:
> On a 3.03 system, running Ximian Evolution does bad things to gconfd.  It 
> no longer runs the next time someone logs in.  There are also side-effects 
> without gconfd.  They are not fatal.  For example, the CD player does not 
> know how to retrieve song titles, etc.
> 
> I've looked on the web for a solution.  It is apparently a common 
> situation, but I've not found a solution for it short of not running 
> Evolution.

Your description is a bit vague, but IIRC the following happened to us,
maybe it helps: 

evolutions runs evolution-alarm-notify in the background (and this
process usually does not exit, even when the evolution windows is
closed). This thing (like pretty much any other GNOME application) uses
gconfd via OAF, to get/store various configuration parameters.

gconfd will keep running while a single client is connected, and then
stay around for a few seconds. It uses lockfiles, by default in
~/.gconfd/, and seems to do something weird (open+unlink, for one) that
made AFS unhappy (corrupted directory, "invisible but present" files).

Our problem was that at session exit we gave up the user credentials
(AFS home directories..). That means we had a process that could not
remove its own lockfile (and could not exit gracefully either), but
wasn't doing very much else. New GNOME processes (e.g. from a different
session) saw the lock, saw that the owning process was still running,
and tried to contact it. -> Session Lockup (since getting config data is
pretty much the first thing a process does).

Alternatively, they hit the above AFS problem when a new session wanted
to launch a new gconfd, which couldn't start because of the half-present
former lockfile. Funky error messages (something about NFS) and weird
"defaults".

Our solution was to modify gnome-session to 

* redirect the lockfile to /tmp/.... (set GCONF_LOCAL_LOCKS=1)

* explicitly kill all "bad" long-running GNOME processes via
        /usr/bin/evolution --force-shutdown
        /usr/bin/oaf-slay
        /usr/bin/gconftool-2 --shutdown

These modifications/hacks are in the SL_startgnome_afs-1.1-1 RPM.


Hope this helps..
Jan

ATOM RSS1 RSS2