http://qa.mandrakesoft.com/show_bug.cgi?id=6140
------- Additional Comments From [EMAIL PROTECTED] 2003-15-10 17:04 ------- Hmm, there is something I still don't understand : killing X using Ctrl-Alt-backspace should not affect gconfd which is not using X at all.. Moreover, if you are trying to login from the SAME computer at killing X, it should work (well, it works here, when I tried).. But if you are trying to log from ANOTHER system using NFS home, it will fail. I've fixed this particular problem, which is not a NFS lock problem (well, it is needed to workaround broken NFS lock system) : in GNOME 2.4, GConf is using "local" lock which are stored in a temporary directory, which is, by default, /tmp.. Unfortunately, Mdk Linux is setting TMPDIR to $HOME/tmp, so the local lock is NOT local, when $HOME is NFS mounted.. So, if you are trying to run on a single workstation at a time, just grab test packages from http://people.mandrakesoft.com/~fcrozat/gconf/ , they should fix the problem I was explaining just above. If you are trying to use log twice using the same NFS account on two different workstations, you'll have to : -allow ORBit2 to accept incoming TCP/IP connection by adding "ORBIIOPIPv4=1" to /etc/orbitrc -tel GConf to use global lock (this time, shared over NFS), by setting GCONF_GLOBAL_LOCKS=1 (in /etc/profile.d/gconf.sh, for instance).. So, could you try test packages I've uploaded ? -- 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 ...
