http://qa.mandrakesoft.com/show_bug.cgi?id=6140


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1




------- Additional Comments From [EMAIL PROTECTED]  2003-14-10 15:37 -------
There is two different problems here, one in your environment, one in GConf :

-NFS locking should be working correctly on your environment. If it isn't,
strange behaviour can happen, like the one you are seeing. I'm almost sure
running /usr/lib/gconf-sanity-check-2 is complaining on NFS lock problem.

-in GNOME 2.4, GConf is using local lock by default (see
http://www.gnome.org/projects/gconf/ ), to workaround badly configured NFS
environment... Unfortunately, when using secure level > 1, TMPDIR is set to
$HOME/tmp, therefore defeating local lock in GConf..

Could you try setting SECURE_TMP=0 in ~/.bashrc to see if TMPDIR is correctly
set to /tmp ? It should workaround gconfd behaviour regarding TMPDIR.. If it
works, I'll try to fix that at GConf level.

-- 
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


------- Reminder: -------
assigned_to: [EMAIL PROTECTED]
status: NEW
creation_date: 
description: 
Environment :

/home NFS mount ( vers=3, tcp, rsize=8192, wsize=8192, nosuid, soft, intr,
timeo=600 )

serveur = mdk 9.1 + soft RAID1 ( ext3 partition ), PIV

client = current cooker ( 2.4.22-10mdk, GConf-1.0.9-11mdk, GConf2-2.4.0.1-1mdk,
nfs-utils-clients-1.0.5-1mdk, kdebase-3.1.92-2mdk, metacity-2.6.1-1mdk ), AMD

Symptoms :
if for example I quit abruptly gnome - CTRL+ALT+BACKSPACE ), next time I want to
log, I can't because gnome can't remove the lock ( or find a lock ) in
~/tmp/gconf-username/ ( this location change between mdk 9.1 and mdk 9.2, before
this was ~/.gconfd/... ). 
Sometimes you can read the message saying that you have a locking problem ( and
thus read the path to the lock ) but sometimes you see nothing ( just some
windows with dash instead of text ... ).
A bad combinaisaison is when you log in and have the gnome preference daemon bug
( see #6138 ), then you decide to stop everything before it mess up your session
config ( as it asks to remove some applets ... ) by hitting CTRL+ALT+BACKSPACE.
You reboot the computer to resolve the problem ( argh )and when you try to log
in again ... gconf locking problem ( so you need to remove manually the lock )
and then you can log in ( so 3 attempts and 1 reboot just to log in in Gnome ! ).
This is really painfull when you have several computers to administer under
gnome. the locking proble can be solve by erasing by hand the lock at each gnome
start ( i put this in /etc/gnome/gnomerc ), but this is just a hack. Gnome is
really too fragile in an NFS environment ...

Reply via email to