Very simple. "xauth" (sshd calls xauth to edit .Xauthority) does not do
any file locking or atomic capable operations. NFS does not support
locking (atleast NFS3, I have not really read up on NFS4.)
You would have to do something like:
1) move xauth to xauth.bin
2) create a shell script called xauth that contains:
################################################
#! /bin/sh
XAUTHCMD="/usr/bin/xauth.bin"
LOCK="$HOME/.Xauthority.lock"
mkdir $LOCK > /dev/null 2>/dev/null
while [ "$?" -ne "0" ]; do
sleep 1
mkdir $LOCK > /dev/null 2> /dev/null
done
$XAUTHCMD $*
RETVAL=$?
rmdir $LOCK
exit $RETVAL
################################################
On 6/9/05, Irfan or Sarah Elahi <elahi@rocketmail.com> wrote:
I just upgraded from SLES8 to SLES9 and have started
getting this hard to recreate problem.
We have a 64-node cluster with a shared NFS as $HOME.
Sometimes when a user "ssh -X" to two or more nodes in
quick succession the .Xauthority file ends up
corrupted and the users first session works fine while
X11forwarding for the second and third sessions do not
work.
This cannot be recreated easily but more than 5 users
have complained about it in the last one week alone
and the only solution was to ask the users to remove
their .Xauthority file and try again.
Any one has any clues why this is happening. I have
the same sshd_config on another cluster running SLES8
and the same problem has not occurred there even once.
Thanks in advance.
Irfan
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
--
END OF LINE
-MCP
