Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#49988 - [sddm] broken after recent updates, stuck in login screen

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Thursday, 07 July 2016, 15:28 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 08 July 2016, 03:21 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


After one of the recent updates, multiple X11-related problems emerged, some of which affect sddm and/or startkde.
When a user enters their password, the sddm login screen just freezes and does nothing. Logging in on the console and calling startx works just fine (with exec startkde in .xinitrc).
In the attached log (journalctl -b | grep -i sddm), it looks like startkde might be freezing when called from sddm. The last few lines ending with "Process is already running" repeat on each press of the Enter key in the frozen login screen with password filled in.

Tried to remove .Xauthority. That didn't help.
Tried to restore /etc/sddm.conf to its default version generated by sddm. That didn't help.
Things like systemctl --failed look OK, no failures.

I'm attaching the output from the startx command (something like a .xsession-errors equivalent). There's a complaint about a missing libkdeinit5_plasma-desktop library. (But I have all the plasma-meta stuff installed.) My GPU type is also shown there. (The output also contains a few other errors that may have been around for a long time already.)

I do see one suspicious entry in dmesg:
[ 897.680245] kactivitymanage[2739]: segfault at 7fae3576fcf0 ip 00007fae35787ce1 sp 00007ffc60a57828 error 4 in[7fae35771000+46000]
The corresponding stack trace is attached (kactivitymanage_stacktrace.txt). Multiple things crash upon login from sddm. I tried to reinstall all XCB stuff that I could find, but the problem is still the same.
Sadly, when searching through the logs, I found that these^^^ crashes already occurred in the past, perhaps a few times a month, and never caused logins to fail or sessions to hang. So they may be just a red herring. (However, now they occur all the time, not just spuriously.)

Apart from the sddm malfuncftion, X11 sessions started from startx has severe latency issues -- not sure to what extent they can be related to the sddm problem, but they appeared at the same time:
* terminal programs that contact (vim, mc) take *long* to start. I tried strace -r to track syscall durations and there was a 2.4-second delay waiting for a response from the X-server. However, GUI applications such as KWrite start immediately; no delay there.
* konsole takes a huge amount of time (~seconds) to respond to its default F12 show/hide key.
* other bits of unexpected latency all over the desktop. :-(

Could this have something in common with the recent Qt 5.7 update? Any testing plasma stuff that I could try?

Additional info:
* package version(s)
Quite a standard rolling release state from Thu Jul 7 16:51:45 CEST 2016
Qt 5.7.0
KDE stuff on 16.04.2 or 5.23.0 (depending on versioning scheme); will paste the exact list upon request.

* config and/or log files etc.
A few logs are attached; will look also at other logs if requested.
/etc/sddm.conf comes from sddm --example-config, just the minimum user ID needs to be set to ~500 on my system, otherwise it's in the default state.

Steps to reproduce:
Boot on a system with sddm enabled and try to log in.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 08 July 2016, 03:21 GMT
Reason for closing:  Not a bug
Comment by Andrej Podzimek (andrej) - Thursday, 07 July 2016, 15:46 GMT
I also filed, which appears to be related, albeit distantly.
Comment by Andrej Podzimek (andrej) - Thursday, 07 July 2016, 16:51 GMT
Yet another bit of information: KDE screen locker is also affected (freezes forever and doesn't let the user unlock the screen).
Workaround: chmod ugo-x /usr/lib/kscreenlocker_greet # and then just kill kscreenlocker_greet from a text console.
Grrr, this issue is really annoying.
Comment by Andrej Podzimek (andrej) - Thursday, 07 July 2016, 22:00 GMT
Update: There appears to be no relationship between the desktop latency issues and the login / screen lock issues.

I've just realized, after lots of trial&error, that the screen lock issue was caused by an update to fingerprint-gui (1.07-2 -> 1.08-1). I'm not sure how this could have blocked sddm, but it just did. Uninstalling all the fingerprint stuff and removing it from /etc/pam.d is a workaround that makes sddm operational again. Both sddm and the screenlocker work fine now. (Presumably, this disables fingerprint authentication altogether.)

The thing is that sddm has *never* been compatible with fingerprint readers (or too buggy to even bother), so sddm and fingerprint reading just coexisted without interaction. The fingerprint reader only worked in terminals for sudo etc. But it was still very useful, for sudo, yaourt, you name it. Well, not any more; because the latest fingerprint-gui causes sddn and the KDE lock screen to hang rather than just ignoring fingerprint readers.

Anyway, this bug report is obsolete now, because the fingerprint reader issue and the terminal latency issues should be tackled separately, without all the noise I produced above. :-(