My problem is very similar to this one from Unix & Linux Exchange.

I use systemd to start emacs --daemon as my user account. Recently I have had the following problem when trying to open a new frame of my emacs process.

$ emacsclient -c
Waiting for Emacs...
*ERROR*: Display :0 can't be opened

In the question linked above, the user had old emacs daemons still running, but I only have one.

$ ps ux | grep  [e]macs
anthony    675  0.0  1.2 432560 103680 ?       Ssl  20:41   0:03 /usr/bin/emacs --daemon

I imagine my problem is related to $XAUTHORITY as suggested in the second answer of the question linked above, but I have been unable to solve the issue on my own and was hoping someone here could help. Possibly relevant information to follow:


$ ls -l /var/run/gdm/auth-for-anthony-ATsjnA/database
-rw------- 1 anthony anthony 106 Feb 18 20:41 /var/run/gdm/auth-for-anthony-ATsjnA/database

$ ps -C emacs wwe
 675 ?        Ssl    0:02 /usr/bin/emacs --daemon DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 
DISPLAY=:0 HOME=/home/anthony LANG=en_US.UTF-8 LOGNAME=anthony MAIL=/var/spool/mail/anthony 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin SHELL=/bin/bash USER=anthony 

I log in with gdm into gnome-shell, and the emacs process is started with systemctl --user start emacs.service. Here's the contents of the emacs.service:

Description=Emacs: the extensible, self-documenting text editor

ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"


Any help would be greatly appreciated.


At politza's suggestion:

$ DISPLAY=:0.0 emacsclient -c
Waiting for Emacs...
*ERROR*: Display :0.0 can't be opened

I connect to the server fine in gnome-terminal with emacsclient -nw as well.

Second Edit

At Stefan's suggestion, I edited my ~/.xsessions to the following

xauth merge "$gdmauth"

/bin/bash --login -i ~/.xinitrc

but I still have the same issue. I'm not sure if it matters, but it seems the value of XAUTHORITY changes with every log-in. I don't know when that value is assigned so that the script above will work.

Manually running xauth merge /var/run/gdm/auth-for-anthony-<random>/database finishes silently, but I still run emacsclient.

  • Have you tried DISPLAY=:0.0 emacsclient ... ?
    – politza
    Commented Feb 19, 2015 at 7:35
  • @politza Thanks for the suggestion. I get the same error. Sorry if this is obvious, but why the suggestion to try :0.0? I don't really know anything about what's going on. Commented Feb 19, 2015 at 7:41
  • Are you working via vnc on a remote machine? The reason I am asking is that if you are connected to a machine with IP a.b.c.d on display X (a.b.c.d:X), then you also need to set the env var DISPLAY to a.b.c.d:X. Commented Feb 19, 2015 at 11:49
  • It can happen if your machine's hostname has changed (for example if it gets its hostname from the network). Check your hostname with hostname, and see if there is a corresponding line in the output of xauth list. Also, can you start other graphical applications from the same terminal?
    – T. Verron
    Commented Feb 19, 2015 at 13:37
  • @user110524 I just remembered vaguely, that there was some bug regarding emacsclient and incomplete DISPLAY variable (man X).
    – politza
    Commented Feb 19, 2015 at 14:43

2 Answers 2


Since I don't have enough reputation to comment, I'll just say that I have this problem too, after updating to systemd 219. Apparently the changelog mentions automatically putting $DISPLAY and $XAUTHORITY into the environment of the systemd user daemons automatically, which is what's causing this problem. So we can isolate this as a new problem introduced with systemd, rather than gdm. From systemd 219 changelog:

  • An X11 session scriptlet is now shipped that uploads $DISPLAY and $XAUTHORITY into the environment of the systemd --user daemon if a session begins. This should improve compatibility with X11 enabled applications run as systemd user services.

As a temporary workaround you can just disable the unit and run emacs --daemon manually.

  • Thanks @charles-zang. I didn't even think to try emacs --daemon manually. Commented Feb 21, 2015 at 2:34
  • I suspect that @stefan is on the write track and the xauthority cookie is not being merged into the systemd process. The change in systemd has likely triggered this. As I notice your running gnome shell, an alternative would be to use tweak tool to add emacs --daemon into the startup programs run when you login, though this may slow down your login. I just use (server-start) in my init.el so that a server is started when I first run emacs
    – Tim X
    Commented Feb 21, 2015 at 8:59
  • With the latest systemd release (in arch-testing repo, which i strongly suspect you are using) the bug should be fixed. Commented Feb 25, 2015 at 18:32

Before running emacsclient you need to run xauth merge /var/run/gdm/auth-for-anthony-ATsjnA/database.

This is due to gdm3's braindead use of XAUTHORITY. One way to work around that is to use something like a ~/.xsession file where you do:

xauth merge "$gdmauth"
  • Thanks, @Stefan. I tried your suggestions, but still no luck (details in the second edit). Might you have any other suggestions? Commented Feb 20, 2015 at 2:45
  • ~/.xsession might simply not be used. IIRC this completely depends on the way you login (e.g. if you choose a Gnome session, or a KDE session or ...). Also I don't know what "but I still run emacsclient" means (does it means that emacsclient then succeeds or does it fail to start?).
    – Stefan
    Commented Feb 20, 2015 at 13:19
  • Sorry, that was a typo. It's supposed to say "but I still can't run emacsclient" (which is still too unclear admittedly). Looks like it's a systemd issue for me, but I very much appreciate your taking the time. Commented Feb 21, 2015 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.