restarting logind during systemd update causes screen to lock

[Michael Blennerhassett]

When systemd is updated (through the update manager), the screen/session locks when processing the update.

I've had this happen twice I think, and the only suspicious packages are the systemd ones.

SRU INFORMATION:
================
- Fix from wily/xenial: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/diff/?id=b8c239 ; This follows other distributions like Fedora which never restarted logind on package upgrades. This just causes too much fallout from clients which listen to the D-Bus address and get confused when logind goes away and comes back.
- Regression potential: This is harmless as long as we don't push an urgent fix to logind itself as an SRU. In this case we might need to re-add the restart on upgrade (with a version guard). This is unlikely/seldom, though. For this particular upgrade there is no regression potential as there are no logind changes (for the record, we've never had a logind SRU so far).
- Test case:
  * Check "pidof systemd-logind"
  * Upgrade "systemd-services" and "libpam-systemd" to the -proposed version
  * The above upgrade will restart logind (as we can't retroactively fix the prerm of the old package) and "pidof systemd-logind" should now show a different pid.
  * sudo apt-get install --reinstall libpam-systemd → now "pidof systemd-logind" should be identical to the previous one, i. e. from now on upgrades of libpam-systemd do not restart logind any more.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: systemd 222-1ubuntu3
ProcVersionSignature: Ubuntu 4.0.0-4.6-generic 4.0.7
Uname: Linux 4.0.0-4-generic x86_64
ApportVersion: 2.17.3-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jul 13 09:49:47 2015
InstallationDate: Installed on 2015-01-31 (162 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.0.0-4-generic root=UUID=4c827ac5-3a87-4443-86eb-a55dca9626ad ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/31/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P2.30
dmi.board.name: FM2A88X Extreme4+
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP2.30:bd07/31/2014:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnFM2A88XExtreme4+:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Martin Pitt (pitti)]

This seems to happen on "systemctl try-restart systemd-logind.service".

[Martin Pitt (pitti)]

When doing "systemctl daemon-reexec; [optional sleep]; systemctl try-restart systemd-logind", loginctl show-session reveals that the current session gets IdleHint=yes for a second or two, which causes the screen lock. This does not seem to happen when *only* restarting logind without a previous daemon-reexec.

[Martin Pitt (pitti)]

This sounds related: http://cgit.freedesktop.org/xorg/xserver/commit/?id=dc48bd653c7e1013e2d69e3f59ae3cbc0c893473 -- Seems current X.org does not like logind to be restarted, but that's what we do right now in the systemd package (so that after a dist-upgrade you actually run the current version).

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 225-1ubuntu7

---------------
systemd (225-1ubuntu7) wily; urgency=medium

  * Don't restart logind on upgrades any more. This kills X.org (#798097)
    while logind doesn't save/restore its open fds (issue #1163), and also
    gets confused about being idle in between (LP: #1473800)
  * debian/extra/initramfs-tools/hooks/udev: Copy all
    /etc/udev/rules.d/*.rules rules which are not merely overriding the one in
    /lib/, not just 70-persistent-net.rules. They might contain network names
    or other bits which are relevant for the initramfs. (Closes: #795494)
  * ifup@.service: Drop PartOf=network.target; we don't want to stop these
    units during shutdown. Stopping networking.service already shuts down the
    interfaces, but contains the safeguard for NFS or other network file
    systems. Isolating emergency.target still keeps working as before as well,
    as this also stops networking.service. (Closes: #761909, LP: #1492546)
  * networkd: Change IPForward= default to "kernel". This keeps compatibility
    with lots of packages which expect to be able to enable global forwarding
    in /proc/sys/net/ipv4/ip_forward. (LP: #1500992)

 -- Martin Pitt <email address hidden> Mon, 05 Oct 2015 15:53:26 +0200

[Launchpad Janitor (janitor)]

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

[Martin Pitt (pitti)]

Adding trusty task, as trusty is apparently also affected (see duplicate bug 1543883).

[Brian Murray (brian-murray)]

Hello Michael, or anyone else affected,

Accepted systemd into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Seth Arnold (seth-arnold)]

Worked for me on trusty.

I had trouble with sudo apt-get install systemd-services/trusty-proposed -- it wanted to uninstall too many things. Probably it would have worked fine with sudo apt-get install systemd-services/trusty-proposed libpamd-systemd/trusty-proposed. Oops.

I instead asked apt to upgrade all the binary packages built from the systemd source package:
sudo apt-get install -t trusty-proposed gir1.2-gudev-1.0 libgudev-1.0-0 libpam-systemd libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1 systemd-services udev

This restarted systemd-logind as expected (and blanked my screen momentarily).

I asked apt to re-install all those packages:
sudo apt-get install -t trusty-proposed --reinstall gir1.2-gudev-1.0 libgudev-1.0-0 libpam-systemd libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1 systemd-services udev

This time systemd-logind did not restart and my screen did not blank.

Thanks Martin!

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 204-5ubuntu20.19

---------------
systemd (204-5ubuntu20.19) trusty-proposed; urgency=medium

  * Add upstream-uaccess-Add-new-DRM-render-nodes.patch: Add uaccess tag for
    "renderD*" devices for AMD GPUs. (LP: #1536438)
  * libpam-systemd: Don't restart logind on upgrades, this confuses too many
    clients and causes effects like screen blanking. (LP: #1473800)
  * debian/extra/initramfs.hook: Fix typo in path of udevadm.upgrade : The
    binary is /bin/udevadm.upgrade while udev is unpacked and not configured
    (see debian/udev.{pre,post}inst. (LP: #1535255)

 -- Martin Pitt <email address hidden> Thu, 25 Feb 2016 16:49:20 +0100

[Martin Pitt (pitti)]

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.