Package: debhelper Version: 10.4 Severity: wishlist Dear Maintainer,
dh_systemd_enable switched from `disable` (on package removal) to `mask` in 2013-09[1]. I noticed[2] each such removed service causes a warning at boot time. `rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked`. I think boot warnings like this are undesirable. `mask` is intended as one of those "big hammers" for users, when the system doesn't do what they want and they're happy to take responsibility for any resulting messes.[3] This would explain why systemd considers its use suspicious, and logs such a message at boot time. Other advantages: * Fix #796884 dh_systemd: should preserve static masks between remove and purge * No other confusion about why /etc/systemd/system/FOO.service exists when the package has been removed. * No confusion about why /etc/systemd/system/multi-user.target.wants/FOO.service exists when the package has been removed. * No user confusion about why /etc/systemd/system/multi-user.target.wants/FOO.service exists but points to a non-existent file. * No user confusion about why one removed service is unmasked when the package is reinstalled, but another is not. Disadvantage: * User `disable` of a service does not persist across package remove+reinstall. This behaviour would become consistent with init scripts - assuming #749400 is implemented - see below (last paragraph). There were two reasons `mask` was used here. 1. #722521. Removing a package naturally deletes most of its files, including deleting the systemd service unit. However the system V init script is preserved, because it might include user changes. This can work OK under system V init, but systemd also picks up the initscript, and will show it as a started service in messages, logs, `systemctl list-units` etc. 2. #722521. Disabling services on package removal also requires some extra care when the package is re-installed. At the time, the re-install failed to re-enable the service. (It was treated as if it was an upgrade where the service had been enabled by the user). #722521 seems perfectly possible to resolve, without resorting to masking. #714903 seems more fundamental. Then I noticed there was an attempt to disable system V initscripts on package removal: #749400. If that could be resolved - which I have posted a suggestion for - there would be no problem. Regards Alan [1] https://anonscm.debian.org/git/collab-maint/init-system-helpers.git/commit/autoscripts/postrm-systemd?id=34f1de71a363168bb62161f9796eb727df8ab797 [2] Longer transcript at https://unix.stackexchange.com/questions/369713/removing-debian-package-automatically-masks-systemd-service-causes-a-systemd-w/369745#369745 [3] https://github.com/systemd/systemd/issues/5750#issuecomment-296662267 -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.11.3-202.fc25.x86_64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: pn autotools-dev <none> pn binutils <none> pn dh-autoreconf <none> pn dh-strip-nondeterminism <none> ii dpkg 1.18.24 pn dpkg-dev <none> ii file 1:5.30-1 pn libdpkg-perl <none> ii man-db 2.7.6.1-2 ii perl 5.24.1-3 pn po-debconf <none> debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make <none>
