4

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:

$ echo $XAUTHORITY
/var/run/gdm/auth-for-anthony-ATsjnA/database

$ 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
 PID TTY      STAT   TIME COMMAND
 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 
XDG_RUNTIME_DIR=/run/user/1000 MANAGERPID=667

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:

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

[Service]
Type=forking
ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
Restart=always

[Install]
WantedBy=default.target

Any help would be greatly appreciated.

Edit

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

gdmauth=$XAUTHORITY
unset XAUTHORITY
export XAUTHORITY
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.

Community
  • 1
imperfectgrist
  • 225
  • 3
  • 6
  • Have you tried `DISPLAY=:0.0 emacsclient ...` ? – politza Feb 19 '15 at 07: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. – imperfectgrist Feb 19 '15 at 07: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`. – Kaushal Modi Feb 19 '15 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 Feb 19 '15 at 13:37
  • @user110524 I just remembered vaguely, that there was some bug regarding emacsclient and incomplete DISPLAY variable (`man X`). – politza Feb 19 '15 at 14:43
  • @kaushalmodi I'm working locally, but thanks. – imperfectgrist Feb 19 '15 at 22:20

2 Answers2

4

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:

gdmauth=$XAUTHORITY
unset XAUTHORITY
export XAUTHORITY
xauth merge "$gdmauth"
Stefan
  • 26,154
  • 3
  • 46
  • 84
  • Thanks, @Stefan. I tried your suggestions, but still no luck (details in the second edit). Might you have any other suggestions? – imperfectgrist Feb 20 '15 at 02: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 Feb 20 '15 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. – imperfectgrist Feb 21 '15 at 02:32
1

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.

Charles Zhang
  • 26
  • 1
  • Thanks @charles-zang. I didn't even think to try `emacs --daemon` manually. – imperfectgrist Feb 21 '15 at 02: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 Feb 21 '15 at 08:59
  • With the latest systemd release (in arch-testing repo, which i strongly suspect you are using) the bug should be fixed. – Charles Zhang Feb 25 '15 at 18:32