Created attachment 226276 [details]
:0-slave.log

Created attachment 226277 [details]
:0-slave.log.1

Created attachment 226278 [details]
.cache/gdm/session.log

Created attachment 226282 [details]
journalctl -ba

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.

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 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.

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.

<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

Problem disappeared with latest systemd. Closing.