http://qa.mandrakesoft.com/show_bug.cgi?id=6140
------- Additional Comments From [EMAIL PROTECTED] 2003-14-10 18:01 ------- I do gconftool --shutdown and gconftool-2 --shutdown and set TMPDIR in my .bashrc Note : There was still some gconf process and also some evolution process. Besides this I was able to log normally ( don't even have the gnome preference bug ! ) concerning lokcing on my server and client ... don't really know. I have nfslock installed and running ... never have problem with others apps/DE. Only gnome and gconf was behaving badly [EMAIL PROTECTED] admin]$ ls -l | grep tmp drwx------ 5 admin admin 4096 oct 14 15:29 tmp/ [EMAIL PROTECTED] admin]$ ls -l tmp/gc* total 4 drwx------ 2 admin admin 4096 oct 14 15:31 lock/ [EMAIL PROTECTED] admin]$ ls -l /tmp/gc* total 4 drwx------ 2 admin admin 4096 oct 14 17:54 lock/ - client : [EMAIL PROTECTED] root]# service nfslock status lockd (pid 1558) est en cours d'ex�cution... rpc.statd (pid 1139) est en cours d'ex�cution... [EMAIL PROTECTED] root]# nfsstat -nc Client nfs v2: null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Client nfs v3: null getattr setattr lookup access readlink 0 0% 16102 41% 608 1% 7151 18% 198 0% 2 0% read write create mkdir symlink mknod 7328 18% 3545 9% 657 1% 1 0% 2 0% 431 1% remove rmdir rename link readdir readdirplus 1091 2% 2 0% 1023 2% 84 0% 283 0% 0 0% fsstat fsinfo pathconf commit 32 0% 32 0% 0 0% 591 1% - server : [EMAIL PROTECTED] root]# service nfslock status lockd (pid 1472) est en cours d'ex�cution... rpc.statd (pid 1004) est en cours d'ex�cution... [EMAIL PROTECTED] root]# nfsstat -ns Server nfs v2: null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Server nfs v3: null getattr setattr lookup access readlink 0 0% 125297571 30% 80241 0% 1157302 0% 36876 0% 680 0% read write create mkdir symlink mknod 703807 0% 833844 0% 58503 0% 807 0% 248 0% 3831 0% remove rmdir rename link readdir readdirplus 44037 0% 1013 0% 45274 0% 5756 0% 13259 0% 0 0% fsstat fsinfo pathconf commit 63550 0% 63550 0% 0 0% 98905 0% -- 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 ...
