Red Hat Bugzilla – Bug 962983
logind forgets sessions on upgrade
Last modified: 2014-03-16 23:33:41 EDT
Description of problem:
Upgrading from 202-3.fc19, to:
May 14 16:48:16 nostromo.devel.redhat.com yum: Updated: systemd-libs-204-2.fc19.x86_64
May 14 16:49:07 nostromo.devel.redhat.com yum: Updated: systemd-204-2.fc19.x86_64
May 14 16:49:08 nostromo.devel.redhat.com yum: Updated: systemd-sysv-204-2.fc19.x86_64
May 14 16:50:53 nostromo.devel.redhat.com yum: Updated: systemd-devel-204-2.fc19.x86_64
logind forgot about my session during the upgrade. After the upgrade:
[notting@nostromo: ~]$ loginctl
SESSION UID USER SEAT
0 sessions listed.
This breaks a variety of things, obviously.
Version-Release number of selected component (if applicable):
100% in one attempt so far.
Steps to Reproduce:
1. yum upgrade
Assorted things break because logind thinks I don't have a session.
May 14 16:48:52 nostromo.devel.redhat.com systemd-logind: Lid closed.
May 14 16:53:33 nostromo.devel.redhat.com systemd: Stopping Login Service...
May 14 16:53:33 nostromo.devel.redhat.com systemd: Starting Login Service...
May 14 16:53:33 nostromo.devel.redhat.com systemd: Started Login Service.
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: New seat seat0.
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: Watching system buttons on /dev/input/event2 (Power Button)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: Watching system buttons on /dev/input/event5 (Video Bus)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: Watching system buttons on /dev/input/event0 (Lid Switch)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: Watching system buttons on /dev/input/event1 (Sleep Button)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind: Watching system buttons on /dev/input/event6 (ThinkPad Extra Buttons)
May 14 17:01:03 nostromo.devel.redhat.com systemd-logind: Lid opened.
I haven't verified this, but I guess it's caused by this change in 203:
* The cgroup hierarchy has been reworked in many ways. All
objects any of the components systemd creates in the cgroup
tree are now suffixed. More specifically, user sessions are
now placed in cgroups suffixed with ".session", users in
cgroups suffixed with ".user", and nspawn containers in
cgroups suffixed with ".nspawn". Furthermore, all cgroup
names are now escaped in a simple scheme to avoid collision
of userspace object names with kernel filenames. This work
is preparation for making these objects relocatable in the
cgroup tree, in order to allow easy resource partitioning of
these objects without causing naming conflicts.
So v204 is probably confused by the hierarchy created by v202. We have no automatic conversion mechanism, but since this only affects an update within a not-yet-released product, do we actually need one?
For upgrades from previous Fedora releases:
- The recommended method (fedup) shouldn't care.
- Live yum upgrades would be affected, but one usually performs these from
a root login on a VT and with few services running, so the loss of session
information shouldn't cause much trouble. And if it does, one shouldn't act
Closing as WONTFIX. Reopen if you have a persuasive reason why this needs to be fixed.
I confirmed in a VM that this happens when updating from 202 to 203, but not when updating from 203 to 204, which matches my expectations.
It probably should be at least documented. And noted somewhere in systemd planning so that no one pushes the cgroup heirarchy change to an existing release.
(In reply to comment #4)
> It probably should be at least documented.
This kind of thing should have been in the Bodhi update description for F19. It's too late for that now.
Since live yum upgrades are expected to be affected, I can add it to the wiki:
Would that suffice?
> And noted somewhere in systemd planning so that no one pushes the cgroup
> heirarchy change to an existing release.
The only releases where a rebase across the v203 boundary could possibly happen is F18, and even there it's not very likely at this point. I would surely notice this change.
Yes, the 'upgrading fedora using yum' page is probably the right spot.
Added a warning box to
Just courious and want to understand the cause.
Why restart of systemd-logind is not sufficient? Where is stored that cgroup hierarchy? Why after reboot is session correct?
Is stored in the dynamic pseudo-filesystem underneath /sys/fs/cgroup/systemd. It is correct after a reboot because it is built from scratch.
Aha. And since it is used by systemd (that one with pid 1) we can't
mount -o remount /sys/fs/cgroup/systemd
Can systemd remount it? Is it correct solution to this BZ?
The heirarchy is created as part of the bootup process and starting the session and all services - it's not something that would magically appear via a remount.
Got caught out by this myself. Updating a laptop and it auto-locked the screen, when I returned to the machine I could not log in. Checked the update had finished via a console and rebooted. At the moment I'm trying to write a script to do the update on a lab full of machines and trying turn off the automatic screen lock as part of it.
Workaround which worked for me is upgrade in screen(1). Which I can reconnect over ssh or on vt.
I do not think that the warning about yum upgrade is sufficiently scary. I went ahead and tried to do it, and now I just can't boot, and the discussion in this bug report is too unclear for me to figure out what I could possibly do, or have done. There is a "rescue" version of the kernel, but that won't boot either.
The warning should say "absolutely do not use yum upgrade for going from Fedora 18 to 19".
I thought of using screen(1), but I did not know what that meant.
I'm not an idiot. I have used yum upgrade from the beginning, and I always managed to get it to work.
(In reply to jonathan baron from comment #15)
I don't think your boot problem is related to the issue discussed in this BZ.
(In reply to Michal Schmidt from comment #16)
> (In reply to jonathan baron from comment #15)
> I don't think your boot problem is related to the issue discussed in this BZ.
You're right. Sorry.
There were at least two problems. (Things are not fully fixed yet.) One was that Mate was not fully installed. I had to groupinstall "MATE Desktop", even though I had done that for Fedora 18. (No idea why it didn't upgrade by itself.) And then I did a whole bunch of other things but I think the one that did the trick was removing /etc/X11/xorg.conf.
Things were working well enough so that I could boot at level 3, or even level 5 and then log in from another computer. Everything was still there. It was just Mate that didn't seem to be starting.
Then MATE has something missing in Requires. Please file BZ against MATE.