Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
On 16/10/17 16:44, Michael Biebl wrote:
Am 16.10.2017 um 12:40 schrieb Alan Jenkins:
I suspect this would end up with Debian carrying the patch to the
systemd generator. But all it needs to do is test for
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.
Alan
I'm not very enthusiastic of keeping and maintaining (yet another) state
directory/file which could potentially get out-of-sync .
A much simpler idea could be, to remove the -x bit from the SysV init
script on remove (and reapply it on re-install). Afair, the
sysv-generator already ignores such init scripts. So nothing would have
to change on the systemd side.
dh_installinit (shipped by debhelper) would have to be updated to
generate maintainer scripts code to remove and (re)add the executable bit.
Still, we'd have to consider that we have upgraded systems which have
not been rebuilt with the new debhelper so we can't just remove the
current logic which masks uninstalled-but-not-purged init scripts.
Maybe in two or three releases we could revisit that.
Removing the -x bit of removed-but-not-purged init scripts would have
the nice side effect, that those are also not executed under
sysvinit/startpar.
Are you interested in working on a patch for debhelper?
Sorry. I thought I should report my annoyance once I'd found the root
cause for it. But I don't think I can commit to writing patch(es) now.
Maybe you have the right idea about clobbering the executable bit. I
didn't like it because the reason for this annoyance was just such a
clobbering (v.s. systemctl mask).
It was already frustrating to prevent a Debian network service starting
before you'd configured it.[1] `systemctl mask` provides a way to do
it. For sysvinit, presumably assigning -x with `dpkg-statoverride`
would be an equivalent. Perhaps not a well-documented one. Such
procedures could be silently defeated if the install script applies +x.
[1]
https://unix.stackexchange.com/questions/321621/configuring-my-sshd-securely-with-automation/321622
> we can't just remove the current logic which masks
uninstalled-but-not-purged init scripts
Ouch, I'd forgotten about the transition issue. Yep, I guess wait for
long enough and then explain it in a release note. (Or write an even
more magic package script to apply the mask to residual conffiles in
/etc/rc.d).
Alan
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
Am 16.10.2017 um 12:40 schrieb Alan Jenkins:
> I suspect this would end up with Debian carrying the patch to the
> systemd generator. But all it needs to do is test for
> `/var/lib/update-rc.d/${script}.removed` and then skip ${script}.
>
> Alan
I'm not very enthusiastic of keeping and maintaining (yet another) state
directory/file which could potentially get out-of-sync .
A much simpler idea could be, to remove the -x bit from the SysV init
script on remove (and reapply it on re-install). Afair, the
sysv-generator already ignores such init scripts. So nothing would have
to change on the systemd side.
dh_installinit (shipped by debhelper) would have to be updated to
generate maintainer scripts code to remove and (re)add the executable bit.
Still, we'd have to consider that we have upgraded systems which have
not been rebuilt with the new debhelper so we can't just remove the
current logic which masks uninstalled-but-not-purged init scripts.
Maybe in two or three releases we could revisit that.
Removing the -x bit of removed-but-not-purged init scripts would have
the nice side effect, that those are also not executed under
sysvinit/startpar.
Are you interested in working on a patch for debhelper?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
On 14/10/17 13:27, Michael Biebl wrote:
On Fri, 4 Aug 2017 22:12:08 +0100 Alan Jenkins
wrote:
Can you please explain how #714903 can be fixed differently so masking
is not needed?
> There were two reasons `mask` was used here.
>
> 1. 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.
I believe the solution (which may or not be politically practical) is:
Implement an equivalent feature to masking for system V init scripts,
which is dedicated to handle removed packages only.
This only strictly needs to be respected by the systemd generator, which
converts init scripts to systemd services.
Probably the init scripts want to include the same feature themselves.
(Around the same point where they decide whether to dispatch to
`systemctl start` instead). I think that would also allow removing some
less regular weirdness from init scripts. Debian would no longer have a
special requirement that init scripts silently succeed if the daemon
binary does not exist. And I think the dnsmasq package (as opposed to
dnsmasq-core?) has even more special handling, which could go away.
I suspect this would end up with Debian carrying the patch to the
systemd generator. But all it needs to do is test for
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.
Alan
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
On Fri, 4 Aug 2017 22:12:08 +0100 Alan Jenkins wrote: > On 04/08/17 20:52, Michael Biebl wrote: > > On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins > >> 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. > >> > >> #722521 seems perfectly possible to resolve, without resorting to masking. > > How? > > > > You snipped my point 2, which also referred to #722521. Sadly this was > a typo. Point _2_ is the easy one to resolve. Point 1 should have > referred to #714903; I think it is the more fundamental issue. Can you please explain how #714903 can be fixed differently so masking is not needed? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
On 04/08/17 20:52, Michael Biebl wrote: On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins 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. #722521 seems perfectly possible to resolve, without resorting to masking. How? You snipped my point 2, which also referred to #722521. Sadly this was a typo. Point _2_ is the easy one to resolve. Point 1 should have referred to #714903; I think it is the more fundamental issue. Sorry! Alan
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins > 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. > > #722521 seems perfectly possible to resolve, without resorting to masking. How? signature.asc Description: OpenPGP digital signature
Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`
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 pn binutils pn dh-autoreconf pn dh-strip-nondeterminism ii dpkg 1.18.24 pn dpkg-dev ii file 1:5.30-1 pn libdpkg-perl ii man-db 2.7.6.1-2 ii perl 5.24.1-3 pn po-debconf debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make
