Cannot open display ":0.0" since 2023-07-10 update

Support Graphics & Display
,
1

I first noticed this because KDE/Plasma startup scripts were failing to open windows (or run other commands such as setxkbmap) after the upgrade, however further investigation shows this is also a problem with anything launched from outside the X session also failing.

Curiously, this is only a problem for the first login after a reboot (either with auto-login or without). Once I log out then back in again, everything works.

Error messages seen:

Invalid MIT-MAGIC-COOKIE-1 key
Cannot open display ":0.0"

What’s affected:

  • Anything launched from KDE/Plasma autostart scripts.
  • systemd user units.

What I’ve found is that if I run “xhost +” from within the X session, scripts run from systemd units can interact with the X server. However, issuing “xhost +” in the startup scripts fails to allow access.

So it seems that the underlying problem is that a change has been introduced by this update which is more restrictive about what can access the X server. I’m very suspicious this may be in some way related to the fact that since this update, the X session is running on the second TTY rather than the first, though I have no way to prove this.

Research has suggested putting “xhost +” in ~/.xinitrc. This doesn’t work. Another suggestion was adding “localhost” to /etc/X0.hosts, which again doesn’t work.

Any suggestions what might solve this?

2 
mv ~/.Xauthority ~/.Xauthority.bak
3

You are aware that xhost + turns off access control completely and everyone on your network can connect to your xserver?

Anyway… the xserver is usually restricted to localhost.

@cscs points to the correct solution. The magic cookie is saved in that file.

4

[Edit]: I’ve just noticed that part of my title originally got stripped off. I need to point out that this only started since the 2023-07-10 update, as this is significant.

Thanks for the suggestion. Unfortunately it doesn’t help. Still the same - first login doesn’t work, subsequent logins work

Though it does change the error message. I’m now seeing
Authorization required, but no authorization protocol specified

Searches only find this mentioned when people are trying to run GUI applications either remotely or from other users.

I can see that a file with the magic cookie is being created in /tmp (presumably that was already being created, which is why ~/.Xauthority was causing problems. Though curiously, that file isn’t getting created until slightly after my startup script starts.

I’ve also noticed that the pamac system tray notifier isn’t appearing after this first login and the journal says

Jul 18 10:22:36 antwerp systemd[717]: app-pamac\x2dtray\x2dbudgie@autostart.service: Skipped due to 'exec-condition'.
Jul 18 10:22:36 antwerp systemd[717]: Condition check resulted in Update Notifier being skipped.
Jul 18 10:22:36 antwerp systemd[717]: app-pamac\x2dtray\x2dplasma@autostart.service: Skipped due to 'exec-condition'.
Jul 18 10:22:36 antwerp systemd[717]: Condition check resulted in Update Notifier Tray Icon being skipped.
Jul 18 10:22:36 antwerp systemd[717]: app-restore_kmix_volumes@autostart.service: Skipped due to 'exec-condition'.

As this is also before the magic cookie file has been created, this may be related.

Most curious…

5

Indeed. But as the only significant devices on my network are my computer and 'phone, it’s not a worry.

6

Do you find a solution?
Maybe I have a similar problem.
(For me just timeshift GUI with the message “cannot open display”)

7

The only solution at present is to downgrade SDDM.
I’ve raised a bug with the developers and I think they’ve worked out what’s going wrong, though when a fix will appear is another question.

1 Like