Bug 962983 - logind forgets sessions on upgrade
logind forgets sessions on upgrade
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-14 17:19 EDT by Bill Nottingham
Modified: 2014-03-16 23:33 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-15 07:05:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2013-05-14 17:19:07 EDT
Description of problem:

Upgrading from 202-3.fc19, to:

May 14 16:48:16 nostromo.devel.redhat.com yum[9305]: Updated: systemd-libs-204-2.fc19.x86_64
May 14 16:49:07 nostromo.devel.redhat.com yum[9305]: Updated: systemd-204-2.fc19.x86_64
May 14 16:49:08 nostromo.devel.redhat.com yum[9305]: Updated: systemd-sysv-204-2.fc19.x86_64
May 14 16:50:53 nostromo.devel.redhat.com yum[9305]: 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):

204-2.fc19

How reproducible:

100% in one attempt so far.

Steps to Reproduce:
1. yum upgrade
  
Actual results:

Assorted things break because logind thinks I don't have a session.

Expected results:

Not that.

Additional info:

May 14 16:48:52 nostromo.devel.redhat.com systemd-logind[1040]: Lid closed.
May 14 16:53:33 nostromo.devel.redhat.com systemd[1]: Stopping Login Service...
May 14 16:53:33 nostromo.devel.redhat.com systemd[1]: Starting Login Service...
May 14 16:53:33 nostromo.devel.redhat.com systemd[1]: Started Login Service.
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: New seat seat0.
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: Watching system buttons on /dev/input/event2 (Power Button)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: Watching system buttons on /dev/input/event5 (Video Bus)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: Watching system buttons on /dev/input/event0 (Lid Switch)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: Watching system buttons on /dev/input/event1 (Sleep Button)
May 14 16:53:33 nostromo.devel.redhat.com systemd-logind[15105]: Watching system buttons on /dev/input/event6 (ThinkPad Extra Buttons)
May 14 17:01:03 nostromo.devel.redhat.com systemd-logind[15105]: Lid opened.
...
Comment 1 Michal Schmidt 2013-05-15 06:54:12 EDT
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?
Comment 2 Michal Schmidt 2013-05-15 07:05:06 EDT
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
   surprised.

Closing as WONTFIX. Reopen if you have a persuasive reason why this needs to be fixed.
Comment 3 Michal Schmidt 2013-05-15 07:17:31 EDT
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.
Comment 4 Bill Nottingham 2013-05-15 12:07:06 EDT
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.
Comment 5 Michal Schmidt 2013-05-15 12:26:13 EDT
(In reply to comment #4)
> It probably should be at least documented.

Where?

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:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum

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.
Comment 7 Bill Nottingham 2013-05-15 12:28:36 EDT
Yes, the 'upgrading fedora using yum' page is probably the right spot.
Comment 9 Miroslav Suchý 2013-05-16 05:30:10 EDT
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?
Comment 10 Zbigniew Jędrzejewski-Szmek 2013-05-16 08:43:43 EDT
Is stored in the dynamic pseudo-filesystem underneath /sys/fs/cgroup/systemd. It is correct after a reboot because it is built from scratch.
Comment 11 Miroslav Suchý 2013-05-16 10:18:06 EDT
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?
Comment 12 Bill Nottingham 2013-05-16 10:33:05 EDT
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.
Comment 13 Glenn L. Jenkins 2013-07-15 04:30:51 EDT
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.
Comment 14 Miroslav Suchý 2013-07-19 10:12:13 EDT
Workaround which worked for me is upgrade in screen(1). Which I can reconnect over ssh or on vt.
Comment 15 jonathan baron 2013-08-19 11:02:53 EDT
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.
Comment 16 Michal Schmidt 2013-08-19 11:15:19 EDT
(In reply to jonathan baron from comment #15)
I don't think your boot problem is related to the issue discussed in this BZ.
Comment 17 jonathan baron 2013-08-19 19:49:03 EDT
(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.
Comment 18 Miroslav Suchý 2013-08-20 03:18:03 EDT
Then MATE has something missing in Requires. Please file BZ against MATE.

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