Ubuntu
systemd package

Upgrading systemd to 204-0ubuntu1 clears running XDG_RUNTIME_DIR ?!

Bug #1187579 reported by Dimitri John Ledkov
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

After recent upgrade [1] my current in-flight user session has lost support for GPG and SSH agents.

My XDG_RUNTIME_DIR also looks suspiciously emptyish.

$ du -a $XDG_RUNTIME_DIR
0 /run/user/1000/dconf
0 /run/user/1000/pulse/native
4 /run/user/1000/pulse/pid
4 /run/user/1000/pulse
0 /run/user/1000/gvfs
4 /run/user/1000

$ env | grep AUTH
SSH_AUTH_SOCK=/run/user/1000/keyring-mOahZg/ssh

And indeed it looks like the above SSH_AUTH_SOCK is no longer there.

I'm blaming upgrade of systemd packages =) And suspecting they are not safe to upgrade. Fedora applies upgrades on shutdown/startup, and thus there are usually no in-flight user-sessions.

[1] http://paste.ubuntu.com/5734272/

Dimitri John Ledkov (xnox)
Changed in systemd (Ubuntu):
importance: Undecided → High
summary: - Upgrading to 204-0ubuntu1 clears running XDG_RUNTIME_DIR ?!
+ Upgrading systemd to 204-0ubuntu1 clears running XDG_RUNTIME_DIR ?!
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

I tried tons of upgrades from 202 to 204 yesterday during packaging, and I just re-tried it again on yesterday's daily with udev/logind 202. Do you still have the screen output of the update? (/var/log/dist-upgrade if you used update-manager, or maybe in scrollback?)

udev isn't concerned about /run/user, logind is not restarted during upgrades, and libpam-systemd should only get active if you create a new user session for the same user. The latter is most likely to have happened, can you remember having done something like that? If you still have that broken boot, could you please check the creation and modification dates of /run/user/1000 to see whether it was created before or after the update?

Finally, can you please attach /var/log/auth.log? It may have something interesting.

Thanks!

Changed in systemd (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I don't have screen output.
But auth.log does show a stray/additional session being opened for my user account in a timeframe: well after systemd upgrade, and well before I reported this bug.
Let's call it my fault, until I can reproduce it.

Revision history for this message
Martin Pitt (pitti) wrote :

Discussed further on IRC. It's not quite clear how this could happen, but killing and respawning logind after the upgrade before rebooting is definitively broken (the upgrade doesn't do it by default, but it might have happened somehow). We resolved to triggering a reboot notification when upgrading from < 204.

Changed in systemd (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: High → Medium
status: Incomplete → In Progress
Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 204-0ubuntu2

---------------
systemd (204-0ubuntu2) saucy; urgency=low

  * debian/rules: Add /system/firmware and /vendor/firmware to firmware search
    paths. (LP: #1187616)
  * debian/libpam-systemd.postinst: Notify about required reboot when
    upgrading from < 204, as due to changed cgroup layout restarting logind
    after the upgrade would lose all existing sessions. (LP: #1187579)
 -- Martin Pitt <email address hidden> Wed, 05 Jun 2013 11:07:38 +0200

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.