Infrequent random login freeze after waking up from suspend

flooklab · 2024-12-04 15:11:21

Hey all,

every once in a while (not often, maybe twice a year) it happens that I cannot unlock/login after waking my system up from suspend.
I can normally type my session unlock password to the LightDM greeter but after pressing "unlock" nothing will happen
(the greeter seems to freeze for a while). I can still switch to another TTY and type username/password but cannot
actually login there either (also freezes for a while). After a reboot everything is back to normal.

The problem is that there is nothing helpful in the journal. If I compare to a successful suspend/wakeup cycle the only real
difference is that the following lines are missing in journalctl (which is no surprise as it fails to switch back to the running session):

systemd[1]: Stopping Session cX of User lightdm...
lightdm[...]: pam_unix(lightdm-greeter:session): session closed for user lightdm
systemd[1]: session-cX.scope: Deactivated successfully.
systemd[1]: Stopped Session cX of User lightdm.
systemd-logind[...]: Removed session cX.

Because the overall system does not really freeze and login via TTY is also affected I suppose that this problem is perhaps somehow related to PAM, though.
Does anyone know what could go wrong here? As I said, this problem rarely happens and thus I cannot really reproduce or debug it.

Concerning the logs: is there any way for me to provide some useful logs the next time this might happen (without having to have debug level logs for half a year...)?
Also, this time I rebooted using SysRq without trying anything else first; would it make any difference for the journal completeness if I tried e.g. a Ctrl+Alt+Del from tty1 or so?

System configuration:

Display server: Xorg
Display manager: LightDM
Desktop environment: Xfce
Screen locker: light-locker

flooklab · 2025-04-07 15:53:04

This happened again yesterday and I managed to restart the system via Ctrl+Alt+Del, but unfortunately I cannot provide much more information.

One unusual thing I noticed, though, is that there was a frozen mouse cursor on a black background for maybe a second right after I had triggered the wake-up and right before the lock screen showed up. Then (as always) I could normally type my password but could not unlock the sesson, nor login on another TTY.

(I failed to save the Xorg logs by the way, maybe there was something interesting in them...)

I checked/compared the journals again and here is the part that is *missing* this time (i.e. what was not reached due to the login freeze):

systemd[1]: Created slice User Slice of UID 973.
systemd[1]: Starting User Runtime Directory /run/user/973...
systemd[1]: Finished User Runtime Directory /run/user/973.
systemd[1]: Starting User Manager for UID 973...
(systemd)[2315]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[<unknown>] user=[lightdm] ruser=[<unknown>] rhost=[<unknown>]
(systemd)[2315]: pam_unix(systemd-user:session): session opened for user lightdm(uid=973) by lightdm(uid=0)
systemd-logind[856]: New session 4 of user lightdm.
systemd[2315]: Queued start job for default target Main User Target.
systemd[2315]: Created slice User Application Slice.
systemd[2315]: Reached target Paths.
systemd[2315]: Reached target Timers.
systemd[2315]: Starting D-Bus User Message Bus Socket...
systemd[2315]: Listening on ...
...
systemd[2315]: Reached target Sockets.
systemd[2315]: Reached target Basic System.
systemd[2315]: Reached target Main User Target.
systemd[2315]: Startup finished in 200ms.
systemd[1]: Started User Manager for UID 973.
systemd[2315]: Created slice User Core Session Slice.
...

So obviously the LightDM user usually opens some session, which it didn't do this time. Don't know what you can deduce from this, maybe a question to LightDM people?
A LightDM issue wouldn't explain the login freeze on TTY, though, would it?

indianahorst · 2025-04-20 18:54:45

Can't add any information, but the same problem occurs on my system, also with lightdm as display manager.

Last edited by indianahorst (2025-04-20 18:55:21)

flooklab · Today 01:45:19

Just got the next such freeze.

This time I managed to log back into my session by entering my password and then waiting for a few minutes.
But I could not really use the system anymore because everything was insanely slow.
I could start 'htop', though, which showed a high CPU load for the X11 process

/usr/lib/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

I think it went up to ~25% (i.e. one full thread on a hyperthreaded dual core). This seems way too much but not enough to slow down all the other unrelated TTYs as well, right?
Also the 'htop' process itself sometimes went to roghly 40% CPU load, so I'm really not sure if this problem is even related to X11. To check this, I stopped 'lightdm.service' (hence no X server running) and I still couldn't log into the TTYs (apparently there is a configured login timeout of 60s, which does not seem to apply to LightDM).

Maybe one further observation: I then rebooted - and I might be wrong here - but the system still felt a bit slower than usual until I powered off and manually powered on again. If my perception was correct, could this maybe point to a hardware issue even?

Edit: Again, nothing in the logs btw, neither in journalctl nor Xorg.log.

Last edited by flooklab (Today 01:47:04)

seth · Today 10:15:12

The xorg server load is usually driven by some client (asking it to do something) but the percentages might be high because you're stuck in the minimum frequency?
https://wiki.archlinux.org/title/CPU_fr … ng_drivers

Another problem (but that doesn't really fit htop) might be event polling, try t o detach all external (input) devices.

If you can cleanly reboot, the journal of the boot might hold some clues.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous ("-1") boot, you might have to go back further now and first look at the journal to check whether it's the relevant one before curling it to 0x0.st

flooklab · Today 17:43:54

but the percentages might be high because you're stuck in the minimum frequency?

Could be but I don't think so. The ratio of

/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_{max,min}_freq

is about 3 and I really could barely do anything. Every action seemed much more than 10 times slowed down.

Another problem (but that doesn't really fit htop) might be event polling, try t o detach all external (input) devices.

It's a notebook, unfortunately.
But, in general, as stated in the original post this situation occurs very seldom, so I have almost no chance to try it (or anything...) out anyway.

If you can cleanly reboot, the journal of the boot might hold some clues.

Will have another look at the logs when I have the time, just checked the vicinity of the suspend/wake cycle until the freeze. But I doubt that there is anything unusual this time, because it never was.

Arch Linux

#1 2024-12-04 15:11:21

Infrequent random login freeze after waking up from suspend

#2 2025-04-07 15:53:04

Re: Infrequent random login freeze after waking up from suspend

#3 2025-04-20 18:54:45

Re: Infrequent random login freeze after waking up from suspend

#4 Today 01:45:19

Re: Infrequent random login freeze after waking up from suspend

#5 Today 10:15:12

Re: Infrequent random login freeze after waking up from suspend

#6 Today 17:43:54

Re: Infrequent random login freeze after waking up from suspend

Board footer