Bug 1051876 - Unable to unlock session
Summary: Unable to unlock session
Keywords:
Status: CLOSED DUPLICATE of bug 1043212
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-12 12:56 UTC by Frederic Grelot
Modified: 2014-02-26 08:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-26 08:25:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Frederic Grelot 2014-01-12 12:56:42 UTC
Description of problem:
I am in a multiseat environment.
The First seat (default seat0) has no problem.
However, once the screen on the second seat is locked, I can not unlock it anymore.
The password field appears correctly, and if I type a wrong password, it is actually rejected. However, if I type the correct password, the field becomes gray for half a second, as if everything were OK, then it reapperas white, empty, and with the cursor in it waiting for me to reenter the password.
Nothing special appears on journalctl.
I can still unlock the session from seat0 using "loginctl unlock-sessions" or "loginctl unlock-session 2".

Version-Release number of selected component (if applicable):
gnome-shell-3.10.2.1-3.fc20.x86_64
systemd-208-9.fc20.x86_64

How reproducible:
always

Steps to Reproduce:
1-Create a 2-seat environment
2-login 2 different users on seat0 and seat1
3-wait for the screen in seat1 to lock after a few minutes
4-try to unlock

Actual results:
the password field reappears and the screen does not unlock

Expected results:
The lock screen should disappear and the screen become unlocked

Additional info:
A few days ago, I had errors like "can not login, see pam_nologin(8)", on both screens. I did not report a bug since I cannot reproduce it anymore (it happened few time though). I'm not sure if it's related, but if yes, it might help.
About the current bug : in journalctl, there was some output about fingerd, and I removed the package, but it did not change anything.
As I can see it, the "pam" part seems OK, since the password is effectively rejected when it's wrong and effectively accepted when it's not, so I think the problem relies in either loginctl/systemd or gnome-shell, not in the pam stack.

Frederic.

Comment 1 Frederic Grelot 2014-02-26 08:25:07 UTC

*** This bug has been marked as a duplicate of bug 1043212 ***


Note You need to log in before you can comment on or make changes to this bug.