SDDM 0.20 uses random TTY, breaks autostart programs needing X server

[beermad]

Since upgrading to SDDM 20.0, my X server no longer starts reliably on TTY1, instead it seems to be fairly random, though it usually opens on TTY2.

In principle this shouldn't be a problem in itself, but unfortunately it has very problematic side-effects. I have a number of programs which I launch via KDE autostart options. Some of these need to open GUI windows (things like Firefox & Thunderbird, for example).

Other users on Reddit and the Manjaro forum also report that cron jobs and/or systemd timers which should open GUI windows are failing.

All failures are accompanied by the following messages:

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

[Edit]: the magic cookie message may be a red herring. But "Cannot open display" is the important message".

Non-startup jobs can be fixed by issuing:
xhost +

Startup jobs will work OK if I log out then log back in again, so it seems the problem is that somehow the change of TTY is causing an INITIAL problem opening the X display. I suspect other people's problem with cron/systemd jobs would also get fixed by that.

I have downgraded SDDM to the 0.19 and this has solved my problems, which proves the new version to be responsible.

[MrLavender]

This line

sddm/src/daemon/Display.cpp

Line 119 in c813b2f

m_terminalId = VirtualTerminal::setUpNewVt();

introduced in ebe6110 means it can never start on TTY1. Changing it to use fetchAvailableVt() instead restores the old behaviour.

DISCLAIMER I have no idea what the original reasons were for using VirtualTerminal::setUpNewVt() there instead of fetchAvailableVt(). And I have only tested this change with X11 on my system. It Works For Me^TM.

[davidedmundson]

It's the display something other than :0.0 in the broken case?

I strongly suspect this isn't about TTYS but about timing of the greeters x11 session and the magic cookie is the relevant part.

[kraithus]

I'm having similar problem. Cron jobs using xterm not working anymore since updating to this version.

Checking systemctl status cronie I get:

Authorization required, but no authorization protocol specified and

xterm: Xt error: Can't open display: :0

xhost +SI:localuser:username on each startup seems to fix the issue

[Vogtinator]

Other users on Reddit and the Manjaro forum also report that cron jobs and/or systemd timers which should open GUI windows are failing.

System wide ones? Probably because they use a hardcoded $DISPLAY or $XAUTHORITY, which is broken by design.

[beermad]

Probably because they use a hardcoded $DISPLAY or $XAUTHORITY

Perhaps a quote from Linus may be significant here: "We do not break user-space. If a change to the Linux kernel breaks a program it's automatically a kernel bug which needs to be fixed".

So when (probably large) numbers of users are following common practice and that's been working for years (in my case, decades), and what they're doing no longer works due to a change in SDDM, isn't it fair to say that the problem is the change rather than the users' settings?

[Vogtinator]

Hardcoding $DISPLAY was always wrong, it might randomly fail.

The change for $XAUTHORITY was needed to address important bugs.

We don't just break stuff to annoy users, there are valid reasons behind it.

[beermad]

Hardcoding $DISPLAY was always wrong, it might randomly fail.

It's certainly something I've often seen recommended and is very common practice. You're going to end up with an awful lot of people with broken computers when this release rolls out to slower-updating distros.

And it's curious that if I log out then back in again, background-launched GUI programs do run successfully. It seems that something SDDM is doing (or not doing) when first launched after a boot is causing the problem.

[Vogtinator]

Hardcoding $DISPLAY was always wrong, it might randomly fail.

It's certainly something I've often seen recommended and is very common practice. You're going to end up with an awful lot of people with broken computers when this release rolls out to slower-updating distros.

The $DISPLAY behaviour didn't actually change in SDDM 0.20, unless you use DisplayServer=x11-user.

And it's curious that if I log out then back in again, background-launched GUI programs do run successfully. It seems that something SDDM is doing (or not doing) when first launched after a boot is causing the problem.

What do you mean by "background-launched GUI programs"? Autostart applications get the environment from the DE.

[Edit]: the magic cookie message may be a red herring. But "Cannot open display" is the important message".

It's the other way around: The magic cookie message is the cause, the open failure is the outcome.

[beermad]

OK, I've now tested the "hard coded $DISPLAY" theory. Everywhere I was setting $DISPLAY is commented out and I re-installed 0.20 then rebooted.

Result: on the first login, GUI programs such as Firefox still fail to start. At the start of the script which runs Firefox, I've added "echo $DISPLAY" and this shows that no DISPLAY variable is set. But when the script attempts to launch Firefox it throws an error:
Error: no DISPLAY environment variable specified

When I log out and back in again, everything starts as it was doing in the past. The script starting Firefox now reports that when it starts, $DISPLAY is set to :0.

I'm now going to downgrade to 0.19 again to see what happens with no DISPLAY set in my startup scripts.

Note: I'm not setting $XAUTHORITY in any of my scripts.

[beermad]

Having gone back to 0.19 and rebooted, with the DISPLAY variable not being set, I find that none of my GUI programs will run without DISPLAY being set. Even after logging off and logging back in again. I'm not entirely sure that proves anything useful beyond what my last post said, except that one way or another I still need to be setting $DISPLAY for autostarts.

[Vogtinator]

How do you autostart those applications? If $DISPLAY is not set that means something is really broken with the DE setup.

[beermad]

How do you autostart those applications? If $DISPLAY is not set that means something is really broken with the DE setup.

A wrapper script is called as a KDE startup program so all the things I want to launch at startup run automatically. This script calls various others, one of which for example, starts Firefox, as previously mentioned.

So I assume KDE ought to be passing the necessary environment variables, though evidently this isn't happening.

[Vogtinator]

Which wrapper script and how did you set up the startup program? Do you use systemdBoot (default since Plasma 5.26)?

[medmedin2014]

On Manjaro KDE, my Wayland session boots using tty1, but when I press CTRL+ALT+F2 I don’t get the textual virtual terminal, I see only a frozen SDDM screen, while with F3,F4,F5,F6 it works fine.

[Vogtinator]

On Manjaro KDE, my Wayland session boots using tty1, but when I press CTRL+ALT+F2 I don’t get the textual virtual terminal, I see only a frozen SDDM screen, while with F3,F4,F5,F6 it works fine.

Yeah, the greeter is in a zombie state while a Wayland session is open. This should not be an issue in practice.
I'd expect SDDM to be on tty2 though and the wayland session on tty3. That tty1 is available for the wayland session but not the greeter one is odd. Maybe systemd has ownership of the VT only until booting finishes.