Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-14 Thread Michael Biebl
Am 14.12.2018 um 22:29 schrieb Rebecca N. Palmer:
> On 14/12/2018 20:26, Michael Biebl wrote:
>> https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/
>>
> 
> That's not the one that gets installed -
> https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/debian/sddm.service/
> is.

That one looks indeed incorrect.

While you are fixing debian/sddm.service, you might also drop

# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStartPre=/bin/sh -c '[ "$(basename $(cat
/etc/X11/default-display-manager 2>/dev/null))" = "sddm" ]'

That safe-check is not necessary anymore.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-14 Thread Rebecca N. Palmer

On 14/12/2018 20:26, Michael Biebl wrote:

https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/


That's not the one that gets installed - 
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/debian/sddm.service/ is.




Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-14 Thread Michael Biebl
On Fri, 14 Dec 2018 19:04:51 + "Rebecca N. Palmer"
 wrote:
> Control: tags -1 patch
> 
> That works (starts successfully with the desktop on tty1) - due to the 
> intermittent nature of the bug I can't be sure it's gone, but if we're 
> right about the cause it should be.
> 
> Full sddm.service tested:
> 
> [Unit]
> Description=Simple Desktop Display Manager
> Documentation=man:sddm(1) man:sddm.conf(5)
> # Change this if you want to start sddm in a different tty
> Conflicts=getty@tty7.service getty@tty1.service
> After=getty@tty7.service getty@tty1.service
> 


I'm a bit confused now.

Looking at
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/
it already has

Conflicts=getty@tty1.service
After=getty@tty1.service

So what exactly does your patch change?

If it is the addition of

Conflicts=getty@tty7.service
After=getty@tty7.service

why would that be necessary? There is no getty by default on tty7, so
this appears to be no-op change unless you explicitly configured your
system to start a getty on tty7.


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-14 Thread Rebecca N. Palmer

Control: tags -1 patch

That works (starts successfully with the desktop on tty1) - due to the 
intermittent nature of the bug I can't be sure it's gone, but if we're 
right about the cause it should be.


Full sddm.service tested:

[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty7.service getty@tty1.service
After=getty@tty7.service getty@tty1.service

After=systemd-user-sessions.service systemd-logind.service

# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service

[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager 
2>/dev/null)" = "/usr/bin/sddm" ]'

ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale



Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-13 Thread Michael Biebl
Am 13.12.18 um 23:52 schrieb Rebecca N. Palmer:
> 
> Possible solutions (I have *not* tried them yet):
> - Patch sddm (at [3]) to assume VT 1 is never free
> - or, add a Conflicts=getty@tty1.service (and After= ?) to sddm.service

This is what gdm.service does:

$ systemctl cat gdm.service | grep getty
# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service

Maybe sddm should do the same?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race

2018-12-13 Thread Rebecca N. Palmer

Package: sddm
Version: 0.14.0-4+deb9u1
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

With this /etc/sddm.conf:
[Autologin]
User=rnpalmer
Session=plasmawayland.desktop

autologin works only ~80% of the time; failures usually drop to a text 
login prompt (which works but leads to a text shell, not KDE), but 
occasionally to an sddm graphical login screen (which works).


The system log contains "Jumping to VT 2" on success and "Jumping to VT 
1" on failure (plus "Failed to take control of the tty: Operation not 
permitted" on failure to graphical login screen), which suggests the 
problem is sddm trying to start a desktop and getty@tty1.service trying 
to start a text terminal on the same VT.


This implies the problem is Wayland-specific (sddm only switches VTs 
under Wayland, not X [0]) and also Debian-specific (as the upstream 
configuration disables getty@tty1.service and runs sddm itself on tty1 
[1]), but I have *not* explicitly tested either of these.


Adding systemd-logind.service (like 0.18 has) and getty@tty1.service to 
After= of sddm.service does *not* fix this, probably because 
getty@tty1.service is Type=idle (immediately mark it as "done", but 
don't actually start it until the end of boot [2]) and TTYVTDisallocate=yes.


I hence believe the order of events on failure to be
- systemd "starts" getty@tty1.service
- systemd starts sddm.service
* sddm sees that tty1 is free, and opens it
- systemd really starts getty@tty1.service, and in doing so forcibly 
takes tty1 away from sddm
- sddm tries to use "its" tty1, and hits an error because it no longer 
has it
On success, * is instead reached after getty starts, sees that tty1 
isn't free, and uses tty2 instead.


(systemd maintainers: does this imply that _anything_ that takes the 
first available VT during boot and expects to keep it will have a 
similar problem?  I don't know of any other than sddm, but haven't looked)


Possible solutions (I have *not* tried them yet):
- Patch sddm (at [3]) to assume VT 1 is never free
- or, add a Conflicts=getty@tty1.service (and After= ?) to sddm.service

[0] 
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/src/daemon/Display.cpp/#L324
[1] 
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/

[2] man systemd.service
[3] 
https://sources.debian.org/src/sddm/0.18.0-1/src/daemon/VirtualTerminal.cpp/#L118 
- would need to look at vtState.v_state instead of using VT_OPENQRY


success:

Dec  4 20:55:14 rnpalmer-laptop sddm[843]: Initializing...
Dec  4 20:55:14 rnpalmer-laptop sddm[843]: Starting...
Dec  4 20:55:14 rnpalmer-laptop sddm[843]: Adding new display on vt 7 ...
Dec  4 20:55:14 rnpalmer-laptop sddm[843]: Display server starting...
Dec  4 20:55:14 rnpalmer-laptop sddm[843]: Running: /usr/bin/X -nolisten 
tcp -auth /var/run/sddm/{e8af3b0e-d914-4859-8325-863b144b07f8} 
-background none -noreset -displayfd 18 vt7
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Running display setup script 
"/usr/share/sddm/scripts/Xsetup"

Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Display server started.
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Reading from 
"/usr/share/wayland-sessions/plasmawayland.desktop"
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Reading from 
"/usr/share/wayland-sessions/plasmawayland.desktop"
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Session 
"/usr/share/wayland-sessions/plasmawayland.desktop" selected, command: 
"dbus-launch --exit-with-session /usr/bin/startplasmacompositor"
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Adding cookie to 
"/var/run/sddm/{e8af3b0e-d914-4859-8325-863b144b07f8}"

Dec  4 20:55:17 rnpalmer-laptop sddm-helper[863]: [PAM] Starting...
Dec  4 20:55:17 rnpalmer-laptop sddm-helper[863]: [PAM] Authenticating...
Dec  4 20:55:17 rnpalmer-laptop sddm-helper[863]: [PAM] returning.
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Authenticated successfully
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Jumping to VT 2
Dec  4 20:55:17 rnpalmer-laptop sddm[843]: VT mode didn't need to be fixed
Dec  4 20:55:17 rnpalmer-laptop sddm-helper[863]: Starting: 
"/usr/share/sddm/scripts/wayland-session dbus-launch --exit-with-session 
/usr/bin/startplasmacompositor"

Dec  4 20:55:17 rnpalmer-laptop sddm[843]: Session started

fail to text prompt:

Dec  4 20:52:09 rnpalmer-laptop sddm[852]: Initializing...
Dec  4 20:52:10 rnpalmer-laptop sddm[852]: Starting...
Dec  4 20:52:10 rnpalmer-laptop sddm[852]: Adding new display on vt 7 ...
Dec  4 20:52:10 rnpalmer-laptop sddm[852]: Display server starting...
Dec  4 20:52:10 rnpalmer-laptop sddm[852]: Running: /usr/bin/X -nolisten 
tcp -auth /var/run/sddm/{55773eae-98a2-43a8-904c-acea6cf1be7e} 
-background none -noreset -displayfd 18 vt7
Dec  4 20:52:12 rnpalmer-laptop sddm[852]: Running display setup script 
"/usr/share/sddm/scripts/Xsetup"

Dec  4 20:52:12 rnpalmer-laptop sddm[852]: Display server started.
Dec  4 20:52:12 rnpalmer-laptop sddm[852]: Reading from 
"/usr/share/wayland-sessions/plasmawayland.desktop"
Dec