emacs can't open display

Question

Just recently this has started happening; I run: /usr/bin/emacsclient --alternate-editor="" --no-wait -c and get:

ERROR: Display :0.0 can't be opened

No other applications do this.

The output from xdpyinfo:

name of display: 0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 10707000
X.Org version: 1.7.7

Edit: I discovered that old emacs servers/daemons are still running.

$ ps ux | grep [e]macs
richard   2642  0.0  0.8  38788 24984 ?        Ss   Jun22   0:25 emacs --daemon
richard   7512  0.0  0.6  33896 19720 ?        Ss   Jun23   0:05 emacs --daemon
richard  15458  0.0  0.6  32836 19076 ?        Ss   09:40   0:01 emacs --daemon

Does anyone have any ideas how these can be shut-down when I log-off?

Answer 1

Given the additional info, I guess that your emacsclient is connecting to the "wrong" emacs server. (Or better, the first one that was started: subsequent invocations of emacs --daemon will fail to start the server since the communication socket is already in use.) If the emacs daemon was started in a previous X session, then it's using the wrong credentials for connecting to the X display and thus fails.

You can find out which emacs process is running the server by connecting to it in non-graphics/tty mode; run emacsclient in a terminal with the -nw option:

emacsclient -nw

You can kill a running emacs by having it run LISP code through emacsclient:

emacsclient -t --eval '(progn (server-save-buffers-kill-terminal 1) (save-buffers-kill-emacs 1))' 

where:

• the -t option (alias for -nw or --tty) is to avoid Emacs connecting to the X display;
• the server-save-buffers-kill-terminal detaches the emacsclient before you tell Emacs to stop (otherwise it will issue a confirmation prompt);
• the save-buffers-kill-emacs function is what is normally invoked by C-x C-c, argument 1 tells Emacs not to ask for confirmation.

In addition, I guess the reason you are having so many emacs --daemon running is that you invoke emacsclient with the --alternate-editor="" option: the man page emacsclient(1) states that:

If the value of (the alternate) EDITOR is the empty string, then Emacs is started in daemon mode and emacsclient will try to connect to it.

It could be a better option to start emacs --daemon from your X session startup script (e.g., .gnomerc or the GNOME session configutation) so that the session manager will take care of killing the emacs daemon when the session terminates.

Answer 2

I think I guess what's going on. I'd need to know more about how you log in and how you start Emacs to tell you how to fix it.

An X program needs to have two pieces of information to connect to an X display. It needs to know the name of the display, which is typically taken from the DISPLAY environment variable. It also needs to have a password for the display, called an X cookie, and usually stored in a file called ~/.Xauthority or indicated by the XAUTHORITY environment variable. (More explanations here)

I suspect that Emacsclient is passing the right display information (:0.0) to the main Emacs process, but it's not passing the X cookie. Normally Emacsclient sends its own environment (including XAUTHORITY if present) to the Emacs server, and the two processes have access to the same filesystem to read the cookie file. This is failing here.

To find out why, here are questions whose answers are likely to be useful:

• What is the value of $XAUTHORITY? (If unset, it's as if the value was ~/.Xauthority.)
• Where is that file and what are the permissions on it?
• Were the Emacs process and the current client launched in a different context in some way (machine, user, chroot, …)?
• Does the Emacs process have a different value for $XAUTHORITY? (ps -C emacs wwe or grep -az XAUTHORITY= /proc/$(pidof emacs)/environ)
• How do you log in (in a display manager (which), in text mode, over SSH, …)? How is the Emacs process started (from where, at what point)? Is it started as a daemon?

Answer 3

Debian bug #586685 has a couple of workarounds for this problem; it seems to be a change introduced with gdm3 (where the Xauthority file is stored).

There is an upstream bug filed as well: Gnome bug #651431.