I lock my screen whenever I leave my desk, after one of the last updates I enter my password to unlock, and I get a message that I have failed 3 attempts, and have to wait 10 minutes. Sometimes this comes up after 1-2 attempts. I have clicked the little “eye” to make sure I am typing my password correctly, and it still gives me a failure. If I reboot, it logs in no problem.
I have ruled out:
someone trying to login while I’m away from my desk
me typing my password wrong
This only started happening after maybe 3 updates ago
Manjaro gnome vanilla, stable, linux54
Set deny = 0 in /etc/security/faillock.conf
Ruled out someone else trying to log in by locking my door, I’m the only one with a key. I’m usually away from my desk for 5-10 minutes at a time, and my door is to a cubespace, I’m sure nobody was picking my lock to try and login to my computer randomly.
I will switch my login failures back to 3, and then test with TTY.
Indeed it is very weird, as it is not a problem on login if I reboot, or leave it on the login screen for the weekend, then come in monday for a fresh login.
It’s not because you’re paranoid that they’re not out there to get you!
Seriously now: Did logging in to a TTY still work?
If yes, can you try creating a new user and see if you have the same symptoms there too?
Turned my faillock back to 3, locked the screen, swapped to tty, tried to login - got the message (after typing my pw correct) that my account was locked for 10 minutes.
Interesting things I noticed:
- I changed the fail time to 60 seconds so I wouldn’t have to wait 10 minutes, it still told me 10 minutes
- I didn’t have my faillock on 0 as a fix, I had set it to 10 to alleviate the problem. So with 10 allowed wrong passwords, I never have trouble, but with 3 max attempts, I’m in trouble.
This is getting to be more strange the more I work on it. Sorry for making you wait on a new user, but It’s the end of the day at the office. I’ll take a look at that in the morning.
Tried with 2 additional users (admin/standard) and had the same results. I think I’ll just set the failure limit back to 10 and live with it, it must be something unique to my install, I don’t have the problem on my other two linux installs.
Nope, not giving up yet. Can you:
get rid of
pamac --no-save remove gnome-screensaver
Install the X screensaver by:
pamac install xscreensaver xscreensaver-data xscreensaver-gl
and see if you still have the issue?
If yes, we’re sure it’s PAM that’s the issue as it also happens under a new user, it’s not a profile but a system issue.
Then we’ll have a deeper look at your PAM settings.
I figured out where the problem is coming from, but how to fix it is above my level of brains…
I have a fingerprint reader attached for my Windows VM, my account in linux isn’t set for fingerprint login in gnome settings, but it seems that every few minutes or so, the computer is getting a bad fingerprint read, and after 3 it locks up. I noticed it happen while eating my lunch. I changed the failure interval to 10 minutes, and it no longer locks out the computer. (That is why I assume it is about every 3-4 minutes, the default interval is 15 minutes)
Why the computer is being sent/requesting fingerprint reads every few minutes is strange, as fingerprint login is disabled for my account. Also strange that it happened in TTY…
This is with an imprivata fingerprint reader, a "surface " not “swipe” reader. It is used in our enterprise login system with windows. It was never recognized in linux before, so it makes more sense this just started happening, it was likely added to either linux-firmware or manjaro-firmware.
If you want to investigate why the reader is getting queried, I’ll help if it helps someone else, but I can live with a shortened fail interval to circumvent the issue.
Thanks for looking at this with me, sorry I never brought up the reader, since it was only used in my VM, it never crossed my mind, and it had been hooked up for over a year without issue.
The only thing I can do is to blacklist the fingerprint reader, but then it will not be recognized by the VM any more neither, so I think your solution of setting the timeout to is the most elegant workaround…
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.