Xauthority lock timeout?
in [UK Linux]
|
Prev: sshd known_hosts query
Next: Open source asm2c
From: Martin Gregorie on 3 Jul 2006 10:25 When I login to one specific user via ssh I'm getting the "Last Login" message as usual, but just recently its been followed by a long pause and the message: /usr/bin/xauth: timeout in locking authority file /home/website/.Xauthority Logging in to a different user via ssh doesn't show the pause but I do see a long pause when I use su to become root from this apparently unaffected user. This started to happen yesterday after I got unexpectedly dropped out of an ssh session while debugging a gawk script under the user that now shows the timeout. Initially I was unable to log in again, but after a reboot I can login again, but only slowly thanks to the timeout. I've rebooted the laptop I run ssh sessions from as well, but that hasn't helped. A related problem is that I can't run gftp within an ssh login to the affected user. gftp fails to run (the GUI doesn't appear) and it almost immediately shows the message: X11 connection rejected because of wrong authentication. The application 'gftp-gtk' lost its connection to the display localhost:11.0; most likely the X server was shut down or you killed/destroyed the application. I upgraded from FC4 (which never did this) to FC5 two weeks ago, did a full package update after installing FC5 and again last week, which picked up kernel 2.6.17-1. After getting the lock timeout I've just done another full package update but the problem remains. Obviously, there's a stuck flag somewhere in the X authorization system, but where should I look for it and how can I clear it? TIA Martin -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Martin Gregorie on 4 Jul 2006 08:51 Martin Gregorie wrote: > > Obviously, there's a stuck flag somewhere in the X authorization system, > but where should I look for it and how can I clear it? > I've just tried using the "xauth -b" option, which is claimed to break locks on .Xauthority files. I've run it from root and from the locked-up user. From root it apparently works but does nothing to clear the timeout. Within the user it just times out on the lock. Duh! Any suggestions welcome. Also, where do the following files come from. Could they have any bearing on this problem? ..esd_auth ..ICEauthority -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Nix on 6 Jul 2006 18:40 On Tue, 04 Jul 2006, Martin Gregorie moaned: > Martin Gregorie wrote: >> Obviously, there's a stuck flag somewhere in the X authorization >> system, but where should I look for it and how can I clear it? The problem is rather that when a heap of SSH sessions all fire up at once, they all run xauth simultaneously, and xauth's locking blocks most of them from adding their authentication tokens. > I've just tried using the "xauth -b" option, which is claimed to break > locks on .Xauthority files. I've run it from root and from the > locked-up user. From root it apparently works but does nothing to > clear the timeout. Within the user it just times out on the lock. Duh! Rebuild openssh with --with-xauth pointing to a shell script looking vaguely like #!/bin/sh exec /usr/bin/xauth -i "$@" (WARNING: this may lead to a corrupted .Xauthority file, if you're unlucky.) > Also, where do the following files come from. Could they have any bearing on this problem? > > .esd_auth esound's awful broken authentication system cookie; these get dropped all over the place, even in / if you start esd systemwide (even if / is not root's home directory). esound itself is awful and terminally broken. I recommend fixing it by switching to polypaudio (which has esound network protocol emulation, so you don't have to recompile anything and can avoid running the bloody esound daemon for good). > .ICEauthority The X Inter-Client Exchange protocol. See the `iceauth' program to manipulate this file. It uses much of the same code as xauth, but serves a somewhat different purpose. A major user of this system is KDE's DCOP interprocess communication layer. -- `She *is*, however, one of the few sf authors with a last name ending in O, which adds some extra appeal to those of us who obsess about things like having a book review of an author for each letter in the alphabet.' -- rra
From: Martin Gregorie on 9 Jul 2006 10:15 Nix wrote: > On Tue, 04 Jul 2006, Martin Gregorie moaned: >> Martin Gregorie wrote: >>> Obviously, there's a stuck flag somewhere in the X authorization >>> system, but where should I look for it and how can I clear it? > > The problem is rather that when a heap of SSH sessions all fire up at > once, they all run xauth simultaneously, and xauth's locking blocks > most of them from adding their authentication tokens. > I this case I was the only user. OK, I may have had 2 - 3 ssh sessions connected to the same user, but the ssh set-up was apparently stable and working correctly. Then something crashed when I was running a gawk script and killed that ssh session, dropping me back to the original machine. At this point I couldn't login to that user. After rebooting both systems (I'm not sure the local machine needed a reboot) I was able to login to that user again but now with the pause and Xauthority access timeout. The problem still persists despite two reboots and a kernel upgrade. I'm happy to agree that there is some corruption in the relevant ..Xauthority file or elsewhere. What's the best way to clear it? Would deleting the .Xauthority file in the affected user help? > Rebuild openssh with --with-xauth pointing to a shell script looking > vaguely like > > #!/bin/sh > exec /usr/bin/xauth -i "$@" > I'll bear that in mind if there's no other way to sort the problem out. >> .esd_auth > > esound's awful broken authentication system cookie; these get dropped > all over the place, even in / if you start esd systemwide (even if / is > not root's home directory). esound itself is awful and terminally > broken. > I haven't knowingly run esound or started esd. Does Helix use it? >> .ICEauthority > > The X Inter-Client Exchange protocol. See the `iceauth' program to > manipulate this file. It uses much of the same code as xauth, but > serves a somewhat different purpose. > > A major user of this system is KDE's DCOP interprocess communication > layer. > I don't use KDE - just Gnome. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Nix on 12 Jul 2006 15:40
On Sun, 09 Jul 2006, Martin Gregorie gibbered uncontrollably: > Nix wrote: >> On Tue, 04 Jul 2006, Martin Gregorie moaned: >>> Martin Gregorie wrote: >>>> Obviously, there's a stuck flag somewhere in the X authorization >>>> system, but where should I look for it and how can I clear it? >> The problem is rather that when a heap of SSH sessions all fire up at >> once, they all run xauth simultaneously, and xauth's locking blocks >> most of them from adding their authentication tokens. >> > I this case I was the only user. OK, I may have had 2 - 3 ssh sessions > connected to the same user, but the ssh set-up was apparently stable > and working correctly. Then something crashed when I was running a > gawk script and killed that ssh session, dropping me back to the > original machine. At this point I couldn't login to that user. After > rebooting both systems (I'm not sure the local machine needed a > reboot) I was able to login to that user again but now with the pause > and Xauthority access timeout. Strange: I'd expect stale locks to exist only if xauth was killed while it was running, which is generally the instant after you establish an SSH connection with X tunnelling. > The problem still persists despite two reboots and a kernel upgrade. The lock is a file on disk, so I'd expect it not to budge. > I'm happy to agree that there is some corruption in the relevant > .Xauthority file or elsewhere. What's the best way to clear it? Judging from X11/lib/Xau/AuUnlock.c, the lock file's called ..Xauthority-l. Zap that. > Would deleting the .Xauthority file in the affected user help? Perhaps. It would certainly zap your X authentication tokens, as well, of course, so restarting X would be a good idea. >>> .esd_auth >> esound's awful broken authentication system cookie; these get dropped >> all over the place, even in / if you start esd systemwide (even if / is >> not root's home directory). esound itself is awful and terminally >> broken. >> > I haven't knowingly run esound or started esd. Does Helix use it? It's GNOME's sound server. Everyone hates it. (Everyone hates KDE's sound server too, and everyone also hates NAS. polypaudio seems to be the least hateful network-capable sound server around right now.) >>> .ICEauthority >> The X Inter-Client Exchange protocol. See the `iceauth' program to >> manipulate this file. It uses much of the same code as xauth, but >> serves a somewhat different purpose. >> >> A major user of this system is KDE's DCOP interprocess communication >> layer. >> > I don't use KDE - just Gnome. Other things use it, too, but KDE is an especially heavy user. (Note that if you've ever started even *one* KDE app, it'll have established ICE authentication tokens.) -- `She *is*, however, one of the few sf authors with a last name ending in O, which adds some extra appeal to those of us who obsess about things like having a book review of an author for each letter in the alphabet.' -- rra |