After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 685988 - Unable to unlock the screen after locking it, session state is closing
Unable to unlock the screen after locking it, session state is closing
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-11 16:44 UTC by Elad Alfassa
Modified: 2012-10-25 13:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Output of ls -ltr /var/log/gdm (4.13 KB, text/plain)
2012-10-11 16:44 UTC, Elad Alfassa
  Details
:0-slave.log (59.54 KB, text/plain)
2012-10-11 16:45 UTC, Elad Alfassa
  Details
:0-slave.log.1 (103.87 KB, text/plain)
2012-10-11 16:46 UTC, Elad Alfassa
  Details
.cache/gdm/session.log (307.12 KB, text/plain)
2012-10-11 16:46 UTC, Elad Alfassa
  Details
journalctl -ba (297.39 KB, text/plain)
2012-10-11 16:51 UTC, Elad Alfassa
  Details
slave: don't fail if user session already active when activating from unlock (11.21 KB, patch)
2012-10-11 21:34 UTC, Ray Strode [halfline]
committed Details | Review

Description Elad Alfassa 2012-10-11 16:44:49 UTC
Created attachment 226275 [details]
Output of ls -ltr /var/log/gdm

Well, bug title says it all. I'll attach all relevant logs shortly.

loginctl show-session

Id=2
Timestamp=Thu, 11 Oct 2012 03:39:11 +0200
TimestampMonotonic=72679483
DefaultControlGroup=name=systemd:/user/elad/2
VTNr=1
Display=:0
Remote=no
Service=gdm-password
Leader=684
Audit=2
Type=x11
Class=user
Active=no
State=closing
KillProcesses=no
IdleHint=yes
IdleSinceHint=1349972617819769
IdleSinceHintMonotonic=11720703558
Name=elad
Comment 1 Elad Alfassa 2012-10-11 16:45:33 UTC
Created attachment 226276 [details]
:0-slave.log
Comment 2 Elad Alfassa 2012-10-11 16:46:00 UTC
Created attachment 226277 [details]
:0-slave.log.1
Comment 3 Elad Alfassa 2012-10-11 16:46:49 UTC
Created attachment 226278 [details]
.cache/gdm/session.log
Comment 4 Elad Alfassa 2012-10-11 16:51:07 UTC
Created attachment 226282 [details]
journalctl -ba
Comment 5 Ray Strode [halfline] 2012-10-11 21:28:55 UTC
well one thing that's interesting is this part from attachment 226276 [details]:

gdm-simple-slave[522]: DEBUG(+): GdmSimpleSlave: trying to migrate session
gdm-simple-slave[522]: DEBUG(+): GdmSlave: Activating session: '2'
gdm-simple-slave[522]: DEBUG(+): GdmSlave: unable to activate session: 2

If we look in the code we see this bit:

activate_session_id_for_systemd (GdmSlave   *slave,
       GError *error = NULL;
       GVariant *reply;
 
       /* Can't activate what's already active. We want this
       * to fail, because we don't want migration to succeed
        * if the only active session is the one just created
        * at the login screen.
        */
       if (sd_session_is_active (session_id) > 0) {
               return FALSE;
       }

Of course the session is going to be active in the unlock case.  It doesn't completely explain the wonky behavior you're seeing (at least as far as I can tell) but it's a real problem we should fix, since I think it could lead to the current not getting unlocked.
Comment 6 Ray Strode [halfline] 2012-10-11 21:34:47 UTC
Created attachment 226295 [details] [review]
slave: don't fail if user session already active when activating from unlock

After GDM successfully reauthenticates a user it runs

gdm_slave_switch_to_user_session

to jump to the user's VT and unlock it.  Of course, if the user
is reauthenticating from an unlock screen instead of a user
switched login screen, then they'll already be on the right VT.

gdm_slave_switch_to_user_session fails if the user is already
switched to the session specified.  This failing behavior is used
at login time to decide start a user's session (versus switching
to a user's already running session).

This commit changes gdm_slave_switch_to_user_session to take
an additional parameter to decide whether or not switching to
an already active session should fail, or merely skip to the
unlocking step.
Comment 7 Ray Strode [halfline] 2012-10-11 21:35:53 UTC
Comment on attachment 226295 [details] [review]
slave: don't fail if user session already active when activating from unlock

Attachment 226295 [details] pushed as 99c4f96 - slave: don't fail if user session already active when activating from unlock

Leaving the bug open since I don't think the full mystery is uncovered yet.
Comment 8 Ray Strode [halfline] 2012-10-12 18:00:45 UTC
Okay, Owen figured out what's going on here.

if a user does:

$ sudo su -

Then su will run open it's session modules, including pam_systemd.  That session module will call CreateSession which instead of creating a new session transparently returns the user's current session (determined via a mapping with /proc/self/sessionid).  Then at pam_close_session time, pam_systemd runs ReleaseSession() on the session returned from CreateSession earlier (which was the user's original session), so the user's session gets closed.
Comment 9 Ray Strode [halfline] 2012-10-12 20:39:10 UTC
<poettering> halfline: ouch
<poettering> halfline: hmm
<halfline> http://lists.freedesktop.org/archives/systemd-devel/2012-October/006891.html <-- is the mail i sent too
<poettering> yuck
<poettering> but the fix should be easy
<halfline> oh?
<elad> remove fingers of people who type sudo su?
* elad hides
<poettering> and invoke REleaseSessopn only if we are the instance that created it
<poettering> will fix it
<poettering> give me 10
<halfline> okay i put a patch to do that
<poettering> elad: good idea, too, that probably would work too
<halfline> poettering: on the mailing list message
<poettering> oh
<poettering> tsss
<poettering> ah, i see
...
<poettering> ok, will merge your stuff, and upload it to f18
Comment 10 Elad Alfassa 2012-10-25 13:26:16 UTC
Problem disappeared with latest systemd. Closing.