SDDM - occasional hang during login.

This is now happening on approx 10-15% of boots. Machine boots as normal up to the sddm login screen. After entering the password there is brief disk activity then login hangs, still at the sddm screen. Mouse cursor is active, keyboard is not. Unable to Ctrl-Alt-Fn to a virtual console. Close down has to be done via the SysReq “REISUB” sequence.

This started happening after TW 20180131 -> 20180202 but that may be just coincidence as I don’t see anything in “Changes.date” that directly relates to sddm.

20180201 delivered kernel 4.14.15 -> 4.15.0 which I thought may be a contender, but this is just as likely to happen when booting from the previous (4.14.15) kernel.

Affects existing users and a new test user. This is on a rotational drive which I have no reason to suspect, and looking at the smartctrl data for the drive it looks perfectly healthy.

The machine is dual boot (via bios, not grub), I have an older unmaintained TW on a second drive, booting to that I’m able to access the logs for the failed login attempt on the main drive.

There appears nothing to indicate a problem, at least as far as I can tell, with the exception of some rather curious entries in Xorg.0.log



    22.649] (II) config/udev: Adding input device (unnamed) (/dev/ttyS0)
    22.649] (II) No input driver specified, ignoring this device.
    22.650] (II) This device may have been added with another device file.
    22.650] (II) config/udev: Adding input device (unnamed) (/dev/ttyS1)
    22.650] (II) No input driver specified, ignoring this device.
    22.650] (II) This device may have been added with another device file.
    22.650] (II) config/udev: Adding input device (unnamed) (/dev/ttyS10)
    22.650] (II) No input driver specified, ignoring this device.
    22.651] (II) This device may have been added with another device file.
    22.651] (II) config/udev: Adding input device (unnamed) (/dev/ttyS11)
    22.651] (II) No input driver specified, ignoring this device.
    22.651] (II) This device may have been added with another device file.

snip - through to /dev/ttyS31

    22.664] (II) config/udev: Adding input device (unnamed) (/dev/tty0)
    22.664] (II) No input driver specified, ignoring this device.
    22.664] (II) This device may have been added with another device file.
    22.664] (II) config/udev: Adding input device (unnamed) (/dev/tty1)
    22.664] (II) No input driver specified, ignoring this device.
    22.664] (II) This device may have been added with another device file.
    22.665] (II) config/udev: Adding input device (unnamed) (/dev/tty10)
    22.665] (II) No input driver specified, ignoring this device.
    22.665] (II) This device may have been added with another device file.
    22.665] (II) config/udev: Adding input device (unnamed) (/dev/tty11)
    22.665] (II) No input driver specified, ignoring this device.
    22.665] (II) This device may have been added with another device file.

snip - through to /dev/tty63


Whether that is in any way relevant I don’t know. They are only informational, and X is, as it says, “ignoring this device”…

Whilst googling for similar problems I came across an entry for sddm on the Arch wiki which indicated that a hang in sddm may be due to (presumably a corrupted? or stale?) ~/.Xauthority file, with the suggestion to delete the file and then retry. It seems that file is now located at ~/.local/share/sddm. Deleting it makes no difference as far as I can tell, but as this isn’t happening every time I can’t be certain.

So I’m rather stuck and clean out of light bulb moments… As it’s not every time I wonder if it’s some sort of race condition, or something of that ilk…

Maybe it does not hit anything, but did you change the sddm theme from systemsettyngs?


su -c 'journalctl | grep -i udev

shows anything, Paul ?

On “Configure Login Manager?” No, using “Breeze for openSUSE”, not changed anything there apart from the cursor theme, and that was two or more years ago…

Rather stuck in the past, still using rsyslog…

Nothing relating to udev is shown in (/var/log/) boot.log, boot.msg, messages, or warn

the only mention appears in Xorg.0.log

http://paste.opensuse.org/7471edf5

which all looks normal apart from the tty/ttyS entries shown in the original post.

I can get SDDM to hang sometimes if I log in, log out, init 3, init 5, and log in again. I wonder if it’s related. I discovered that a week or two ago. Sometimes recoverable, sometimes have to log in remotely and reboot.

The problem here appears completely random, if there is a pattern I’ve yet to spot it.

I may get several consecutive good logins… good, fail, good… several consecutive fails… fail, fail, good… Just like tossing a coin :wink:

On a “bad” login, check


su -c 'systemd-analyze blame'

to see if some process is taking a lot of time.

Try changing the display manager.

You could install kdm from the repos and try that, or you could try lightdm, and see if the problem goes away.

But, in my own case (running Xfce), I solved a similar problem by installing kdm and switching to it from lightdm.

On another system, running KDE, I switched from sddm to kdm, again solving a somewhat-similar problem.

When the login fails I’m unable to Ctrl-Alt-Fn to a virtual terminal so can’t run systemd-analyze blame.

I don’t think it’s a process (or processes) taking longer than normal, as on one failed login attempt I left the machine for around 20 minutes to see if it would eventually complete the login, (which it didn’t).


Since my last post:

I’ve cold booted to run level 3 and used zypper to remove the sddm packages: sddm, sddm-branding-openSUSE, sddm-theme-openSUSE, and even kcm_sddm.

Manually removed: /var/lib/sddm/.cache, /var/lib/sddm/.config, /var/lib/sddm/.local, /etc/sddm.conf, and ~/.local/share/sddm. So as far as I’m aware that’s pretty much all sddm gone.

Then (for good measure) rebooted, again to run level 3, and used zypper to install the previously removed sddm packages. At this point it’s my belief that sddm is in it’s default configuration.

Rebooting again, as normal, to the sddm (now rather blue!) login screen… and… the first login failed, Alt-SysRq (RESIUB) out of the hung situation, second login also failed, the third succeeded. The following two logins, without a reboot, also succeeded, the third failed.

I think I can safely say the situation is unchanged… :frowning:

Yes, it had been my thinking the next stage was to try a different display manager.

After a “zypper in kdm” and an “update-alternatives --config default-displaymanager” I’m now using kdm.

So far I’ve had no login failures, I’ll leave it like this for a few days to see how it goes.


Although kdm “serves it purpose” I’d prefer to use sddm, so it would be good to resolve this issue. Is there any way of making sddm more verbose in terms of logging what it’s doing. I don’t feel a bug report would be of much use at this stage as I’ve nothing other than “Sometimes it hangs.”

Have you tried to start Icewm with SDDM?

No, I’d not tried that.

So, I’ve just reset sddm as the display manager and tried logging in to Icewm a few times. Same result, random hangs of sddm.

I’m becoming quite convinced the problem lies with sddm itself…

Paul, I just experienced some other sddm issue, which was solved by clearing both ~/.cache for the user and /var/lib/sddm/.cache. It could very well be related.

In the end the login manager has to do only his job, if it does not, better change it

Thanks :slight_smile: … I’d already tried cache deletion ( post #9 https://forums.opensuse.org/showthread.php/529511-SDDM-occasional-hang-during-login?p=2854225#post2854225 ) as part of a total removal of sddm, prior to reinstalling it so I knew I had a completely default set-up…

I’ve temporarily changed to kdm as the display manager and so far I’ve not had a single login failure.

Yeah! Just had great fun with TW 20180205, everything working but with a blank screen. Solved by the deletion of the shader cache files in ~/.cache (I guess if I’d been using sddm I’d have seen it then, as you did).

I think opensuse should consider this, SDDM seems to be a hot button, crashing, dumping keyboard input to console, ignores system settings for tcp when launching X, several issues it seems.

Decided to give this another look, this time after enabling journal logging rather than rsyslog I’d previously used.

Then:

Cold boot - this was normal and reached the sddm login screen.

At the login screen, selected user and entered password - at this point there was brief (2-3 seconds) disk activity and then sddm apparently hangs at the login screen, it doesn’t progress to the spalsh screen. The mouse cursor is active but the keyboard is not, caps lock and num lock for example don’t work, I’m unable to ctrl-alt-fn to a virtual terminal.

After alt-sysrq-R I’m still unable to ctrl-alt-fn to a virtual terminal.

Using the remaining alt-sysrq-“EISUB” sequence I’m able to gracefully close and reboot.

After interrupting grub I booted to run level 3, logged in and was able to “sudo journalctl | grep -i sddm” …

The output of which is here:

http://paste.opensuse.org/90574d83

Don’t know if that’s enough for a meaningful bug report or not…

Bug report: https://github.com/sddm/sddm/issues/973 - not too hopeful, it’s still rather vague, and a slightly better extract from the journal: http://paste.opensuse.org/66a4205e

Updated to 20180206 and the problem still persists.

Meanwhile I’m continuing to use kdm with no login failures.