[debhelper-devel] Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

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>