2009/8/4 Trent W. Buck <trentb...@gmail.com>: > Is the XAUTHORITY environment variable defined within your X session? > > If so, the reason the Emacs daemon can't connect to your X server is > because it is trying to use ~/.Xauthority, but the file is in some > other place. > > GDM puts the .Xauthority file in a different place when $HOME is on a > root-squashed NFS filesystem, because when the file is created GDM > runs as root, and can't write the file to ~/.Xauthority as normal. It > sets the XAUTHORITY environment variable to the other place (in > /tmp/), so all the child processes know to look there. > > But emacs --daemon was started outside of the GDM process tree, so it > doesn't "see" the XAUTHORITY environment variable. > > When I ran into this problem (using screen, not emacs --daemon), I > worked around it with the following code in my .xsession file: > > ## Dance so screen subprocesses can talk to GDM-spawned X servers. > if test -n "$XAUTHORITY" > then > xauth extract - $DISPLAY | > xauth -f ~/.Xauthority merge - > unset XAUTHORITY > fi > > Note that depending on your DM, .xsession may be called .xinitrc or > .Xclients. Typically you also have to choose "default X session" or > similar, rather than "GNOME" or whatever. >
Thank you for a very helpful response! I don't use NFS, but the problem was indeed in my ~/.Xauthority (it was owned by root and 600 for some reason). I've removed my ~/.Xauthority and restarted X, and now my Emacs can survive X crash :-) Andrey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
