Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

[Zack Weinberg]

Package: systemd
Version: 232-8
Severity: normal

When the systemd package is upgraded, the running instance of systemd is
likely to go into 'freezing execution' mode, in which it is unresponsive
to D-Bus requests until the computer is rebooted.  If a daemon package is
being upgraded at the same time, its postinst is therefore liable to fail,
as it will be unable to ask systemd to restart the daemon.  Here's what
this syndrome looks like in the upgrade crawl:

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 271106 files and directories currently installed.)

...
Preparing to unpack .../4-systemd_232-8_amd64.deb ...
Unpacking systemd (232-8) over (232-7) ...
Setting up systemd (232-8) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.

Broadcast message from systemd-journald at kenaz (Tue 2017-01-03 13:59:01 EST):

systemd[1]: Freezing execution.
Failed to try-restart systemd-networkd.service: Failed to activate service 'org.freedesktop.systemd1': timed out
See system logs and 'systemctl status systemd-networkd.service' for details.
Failed to try-restart systemd-resolved.service: Connection timed out
See system logs and 'systemctl status systemd-resolved.service' for details.
Failed to try-restart systemd-timesyncd.service: Failed to activate service 'org.freedesktop.systemd1': timed out
See system logs and 'systemctl status systemd-timesyncd.service' for details.
(Reading database ... 271105 files and directories currently installed.)
Preparing to unpack .../0-udev_232-8_amd64.deb ...
Unpacking udev (232-8) over (232-7) ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out

...
Preparing to unpack .../00-cups-daemon_2.2.1-4_amd64.deb ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out
Failed to retrieve unit: Connection timed out
Failed to stop cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
Failed to get load state of cups.service: Failed to activate service 'org.freedesktop.systemd1': timed out
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out
Failed to retrieve unit: Failed to activate service 'org.freedesktop.systemd1': timed out
Failed to stop cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
Failed to get load state of cups.service: Failed to activate service 'org.freedesktop.systemd1': timed out
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: error processing archive /tmp/apt-dpkg-install-RbqGAG/00-cups-daemon_2.2.1-4_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out
Failed to retrieve unit: Connection timed out
Failed to start cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
invoke-rc.d: initscript cups, action "start" failed.
Failed to get properties: Connection timed out
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1

...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-RbqGAG/00-cups-daemon_2.2.1-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

(There will usually then be a flood of additional error messages from packages
whose dependencies are broken.)

I have been able to work around this by temporarily creating an
/usr/sbin/policy-rc.d that always exits with code 101, but I shouldn't
have to do that.

An ideal fix would be for systemd to support seamless upgrades of itself,
i.e. pid 1 would re-exec itself using the new binary, without losing
any state.  I realize that if this were easy it would already have been
done.  An acceptable kludge would be for systemd, in "freezing execution"
mode, to continue _accepting_ D-Bus requests, and responding to them as
if they had been successful -- it just wouldn't actually _do_ anything.
Since the computer has to be rebooted anyway, this would not cause any
long-term problems.  (Bonus points for making sure that 'unattended-upgrades'
notices that the computer needs to be rebooted.)


-- Package-specific info:


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.115
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10.95-8
ii  libaudit1       1:2.6.7-1
ii  libblkid1       2.29-1
ii  libc6           2.24-8
ii  libcap2         1:2.25-1
ii  libcryptsetup4  2:1.7.3-3
ii  libgcrypt20     1.7.5-2
ii  libgpg-error0   1.26-1
ii  libidn11        1.33-1
ii  libip4tc0       1.6.0+snapshot20161117-4
ii  libkmod2        23-2
ii  liblz4-1        0.0~r131-2
ii  liblzma5        5.2.2-1.2
ii  libmount1       2.29-1
ii  libpam0g        1.1.8-3.4
ii  libseccomp2     2.3.1-2.1
ii  libselinux1     2.6-3
ii  libsystemd0     232-8
ii  mount           2.29-1
ii  util-linux      2.29-1

Versions of packages systemd recommends:
ii  dbus            1.10.14-1
ii  libpam-systemd  232-8

Versions of packages systemd suggests:
ii  policykit-1        0.105-17
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.126
ii  udev             232-8

-- no debconf information