Lightdm doesnt recognize password after computer has been asleep

GG22GG · 2023-10-05 12:04:01

I have the same problem : arch with cinnamon desktop and screensaver will not accept my (correct) password

Inside the screensaver , I have an icon ( not the lock sign, but 2 persons) to the right of the password line,
which when pressed gives you a login window as if you pressed the logout buttom.

From here , my password works fine

Kind regards

Last edited by GG22GG (2023-10-05 12:05:14)

seth · 2023-10-05 13:43:43

Did you see the workaround in the previous post?
You can also disable https://wiki.archlinux.org/title/Securi … n_attempts

SecT0uch · 2023-10-13 22:07:58

I've been experiencing this exact same issue for a few months now.

I'm running Manjaro Cinnamon, kernel 6.5.5 (prev. version had issues too).

Error message:

oct. 13 19:11:51 Manjaro cinnamon-screensaver-pam-helper[58017]: pam_unix(cinnamon-screensaver:auth): conversation failed
oct. 13 19:11:51 Manjaro cinnamon-screensaver-pam-helper[58017]: pam_unix(cinnamon-screensaver:auth): auth could not identify password for [user]

I'm starting to see a pattern: It seems this issue happens when I am connected with second HID device.
When it happens, I am connected to an external (USB) keyboard via ThunderBolt dock, and more recently this issue happened without the dock but with another HID device: a dualsense controller connected via bluetooth.

I'm 200% the password and keyboard layout are correct and it only happens in those specific circumstances.

Any chance a second HID could mess up PAM authentication ?

Last edited by SecT0uch (2023-10-13 22:13:46)

seth · 2023-10-14 06:35:58

Unless it introduces a fingerprint reader or ends up resetting the input layout¹, only by causing spurious input.

This happens when the device is already attached while the screensaver activates?
*Not* by attaching it while the screensaver is already active?

Is this on X11? You could try to "xinput disable" the second device and/or run evtest on it to see whether it generates spurious input.

[1] Also rejected by https://bbs.archlinux.org/viewtopic.php … 7#p2088497

SecT0uch · 2023-10-14 16:21:59

I have no fingerprint reader.

I confirm this happens when the device is already attached while the lock screen activates.

I just tested evtest on the controller and it seems I have a little drift switch but not over the dead zone, (joystick mapped to the mouse pointer, which is not moving).

I'll try again with the keyboard with and without the dock.

I'm really curious to understand what causes that issue, I can see various threads describing the same issue, but none really useful. We all have the same config: Arch-based distro + Cinnamon

Last edited by SecT0uch (2023-10-14 16:22:32)

seth · 2023-10-14 19:46:43

The problem is the cinnamon screensaver (hence the workaround to use xscreensaver instead) and hopefully most people posting here use arch
Did you try to "xinput disable" the second input device before the screensaver hits?

I suspect you somehow™ trigger faillock, but don't really know why.
You could try to disable that, https://wiki.archlinux.org/title/Securi … n_attempts

SecT0uch · 2023-10-15 09:10:13

Well I known I'm not supposed to post here but I'm convinced this is the same issue and not specific to the distribution, but to the Arch family.

I will try xinput and let you know, but I have to reproduce because this does not happen every time.
Disabling failock is a no go for me, I'd rather use xscreensaver.

Last edited by SecT0uch (2023-10-15 09:10:51)

seth · 2023-10-15 13:07:07

Well I known I'm not supposed to post here

Sorry, that wasn't the point I was trying to make - you're actually perfectly allowed to *post* here, notably to comment on ongoing problems (or in the social threads about your favorite music and funny images etcetc)
Just not starting threads to ask for support on a manjaro system.

Disabling failock is a no go for me, I'd rather use xscreensaver.

You briefly could, just to see whether that's actually what gets triggered by the cinnamon screensaver, though…

because this does not happen every time

… so the second input device actually isn't deterministic?
(That means it might actually be just raising the likelyhood for a conflict)

mrkli · 2023-12-03 09:36:22

Extremely similar issue here. Both on plasma and cinnamon. (X11)
Setting "deny" to whatever value doesn't change a thing, it immediately fails all attempts, but in my case, most of the times, the desktop showed for a second and then the screen blacked out with "no signal".
I tried disabling faillock with "deny = 0", but black screen "no signal" persisted after entering the password, most of the times.
After black out, switching to tty and back sometimes shows the desktop for a second but then it blacks out again.
Restarting lightdm allowed normal log in without black out.. every time I tried, but there's no telling if it would've worked every time.

I downgraded cinnamon-screensaver and problem seemed to be gone for 3 wakes, but came back.

"Fractional scaling" intermittently showed up as true/false in the journal, but I'm guessing the unsupported resolution "2560x1440" actually caused the screen to black out, which I failed to notice earlier lol

org.cinnamon.ScreenSaver[24011]: Screen rect (0,0-1920x1080) and 1 monitor rects (0,0-1920x1080) add up, sending change notification
org.cinnamon.ScreenSaver[24011]: Screen rect (0,0-1920x1080) and 1 monitor rects (0,0-1920x1080) add up, sending change notification
cinnamon-screensaver-pam-helper[24303]: pam_faillock(cinnamon-screensaver:auth): conversation failed
cinnamon-screensaver-pam-helper[24303]: pam_faillock(cinnamon-screensaver:auth): conversation failed
dbus-daemon[733]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.163' (uid=1000 pid=24303 comm="/usr/lib/cinnamon-screensaver/cinnamon-screensaver")
dbus-daemon[733]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
org.cinnamon.ScreenSaver[24011]: Fractional scaling active: False
org.cinnamon.ScreenSaver[24011]: Fractional scaling active: False
org.cinnamon.ScreenSaver[24011]: Fractional scaling active: False
cinnamon-screensaver-pam-helper[24295]: pam_unix(cinnamon-screensaver:auth): conversation failed
cinnamon-screensaver-pam-helper[24295]: pam_unix(cinnamon-screensaver:auth): auth could not identify password for [mrkli]
org.cinnamon.ScreenSaver[24011]: Screen rect (0,0-2560x1440) and 1 monitor rects (0,0-2560x1440) add up, sending change notification
org.cinnamon.ScreenSaver[24011]: Screen rect (0,0-2560x1440) and 1 monitor rects (0,0-2560x1440) add up, sending change notification
org.cinnamon.ScreenSaver[24011]: Fractional scaling active: True
org.cinnamon.ScreenSaver[24011]: Fractional scaling active: True

It just so happens I was fiddling with the global scale setting on plasma before changing it on cinnamon as well, though plasma doesn't present a warning unlike cinnamon.
Also, some programs were intermittently not obeying the scale after logging in.

Needless to say, disabling fractional scaling solved all problems.

Last edited by mrkli (2023-12-05 17:50:48)

seth · 2023-12-03 12:13:15

Switching to tty and back sometimes shows the desktop for a second but then it blacks out again.

That's not the subject of this thread, but is this just DPMS, XSS?
Check "xset q" and "ps aux" for suspicious processes, also "xrandr -q" and then open a new thread, this one here is exclusively about your password not being accepted after/by the cinnabun screensaver, not output misconfigurations causing a "black" screen.

mrkli · 2023-12-05 00:51:22

Actually I failed to convey the erratic nature of the behavior. It seems totally possible that the screen might not loose signal at all, in some cases (as did happen to me when I thought downgrading had an effect, though it also happened a few times before, but not in a row, and also the screen stayed on at least once after switching back from tty), if one is unlucky, therefore having nothing useful in the log.

I have no idea what's causing the unpredictability, but checking for "fractional scaling" might be a good idea for anyone who's having the password rejection problem.

Last edited by mrkli (2023-12-05 01:03:58)

Arch Linux

#26 2023-10-05 12:04:01

Re: Lightdm doesnt recognize password after computer has been asleep

#27 2023-10-05 13:43:43

Re: Lightdm doesnt recognize password after computer has been asleep

#28 2023-10-13 22:07:58

Re: Lightdm doesnt recognize password after computer has been asleep

#29 2023-10-14 06:35:58

Re: Lightdm doesnt recognize password after computer has been asleep

#30 2023-10-14 16:21:59

Re: Lightdm doesnt recognize password after computer has been asleep

#31 2023-10-14 19:46:43

Re: Lightdm doesnt recognize password after computer has been asleep

#32 2023-10-15 09:10:13

Re: Lightdm doesnt recognize password after computer has been asleep

#33 2023-10-15 13:07:07

Re: Lightdm doesnt recognize password after computer has been asleep

#34 2023-12-03 09:36:22

Re: Lightdm doesnt recognize password after computer has been asleep

#35 2023-12-03 12:13:15

Re: Lightdm doesnt recognize password after computer has been asleep

#36 2023-12-05 00:51:22

Re: Lightdm doesnt recognize password after computer has been asleep

Board footer