Bug#1019035: systemd-cron: prerm fails in unbooted systems

RjY rjy at users.sourceforge.net
Sat Sep 3 10:26:03 BST 2022


Package: systemd-cron
Version: 1.15.19-1
Severity: minor
Tags: patch

The package fails to remove when the system is not booted. I think this
is a bug; I think any package should be removable, regardless of the
boot status of the system.

#v+
Spawning container 220903 on /backup/220903.
Press ^] three times within 1s to kill container.
root at 220903:~# apt remove systemd-cron
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  cron-daemon-common* systemd-cron*
0 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
After this operation, 211 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 58695 files and directories currently installed.)
Removing systemd-cron (1.15.19-1) ...
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
dpkg: error processing package systemd-cron (--remove):
 installed systemd-cron package pre-removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 systemd-cron
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)
#v-

Now as you can see in the above reproduction transcript that when I
experienced the error I was nspawn'ed into a copy of the live system.
This was to perform some "trial surgery" on the copy without fear of
breaking the real one. But please consider also the case of performing
maintenance in rescue or emergency mode. I think packages should remain
removable even in such instances.

The fix is simple: do not call deb-systemd-invoke without first checking
for /run/systemd/system. This allows the package to be removed as
expected. It is worth noting the automatically added debhelper section
has the same check.

#v+
--- prerm.orig	2022-07-16 20:42:24.000000000 +0100
+++ prerm	2022-09-03 10:06:10.254464031 +0100
@@ -1,7 +1,7 @@
 #!/bin/sh
 set -e
 
-if [ "$1" = "remove" ]; then
+if [ "$1" = "remove" ] && [ -d /run/systemd/system ]; then
     deb-systemd-invoke stop cron-update.path
 fi
 
#v-

Thus, the package may now be removed as expected.

#v+
root at 220903:~# apt remove systemd-cron
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  cron-daemon-common* systemd-cron*
0 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
After this operation, 211 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 58695 files and directories currently installed.)
Removing systemd-cron (1.15.19-1) ...
Removing cron-daemon-common (3.0pl1-149) ...
Processing triggers for man-db (2.10.2-2) ...
(Reading database ... 58652 files and directories currently installed.)
Purging configuration files for systemd-cron (1.15.19-1) ...
Purging configuration files for cron-daemon-common (3.0pl1-149) ...
#v-

Thank you in advance for your consideration. I hope you will agree this
is a bug and apply the (trivial) patch, not send me away with an
admonishment that this is user error. :)

-- 
https://rjy.org.uk/
-------------- next part --------------
--- prerm.orig	2022-07-16 20:42:24.000000000 +0100
+++ prerm	2022-09-03 10:06:10.254464031 +0100
@@ -1,7 +1,7 @@
 #!/bin/sh
 set -e
 
-if [ "$1" = "remove" ]; then
+if [ "$1" = "remove" ] && [ -d /run/systemd/system ]; then
     deb-systemd-invoke stop cron-update.path
 fi
 


More information about the Pkg-systemd-maintainers mailing list