On 09/06/17 18:55, Niels Thykier wrote:
Alan Jenkins:
On Thu, 24 Dec 2015 00:34:22 -0300 Felipe Sateler <fsate...@debian.org>
wrote:
[...]
Hi Alan,
Why don't we use `update-rc.d FOO remove` on package removal? This
would simply remove all the symlinks. [...]
As I read the "update-rc.d" manpage, the symlinks are a part of the
customization that a admin can do. So if we remove them, then we remove
configuration during "remove" (which must only be done during "purge").
Note this paragraph in update-rc.d(1):
"""
A common system administration error is to delete the links with the
thought that this will "disable" the service, i.e., that this will
prevent the service from being started. However, if all links have been
deleted then the next time the package is upgraded, the package's
postinst script will run update-rc.d again and this will reinstall
links at their factory default locations. The correct way to disable
services is to configure the service as stopped in all runlevels in
which it is started by default. In the System V init system this means
renaming the service's symbolic links from S to K.
"""
Thanks,
~Niels
:-(. I guess my hope was, this bug report showed some sort of
precedent, that policy did not prevent the idea. Otherwise, this bug
would have been shut down earlier on.
I.e. the code running `update-rc.d FOO disable` at removal, would surely
overwrite the customization done by the admin, but that didn't stop that
code being pushed to unstable. (And it's not the reason it was reverted).
Huh, even more confusing: if the package script runs `update-rc.d FOO
disable` at removal, and then you install the package again and it runs
`update-rc.d FOO defaults`, I think the init script would stay
disabled?! I probably need to stop making assumptions from the history
of this issue.
It suggests, this proposal would also need to save the enabled state(s)
at package removal and be able to restore them later... but that's more
than I'd be willing to implement.
However I can imagine saving a "mask" under /var/lib/update-rc.d/, which
has a similar disabling effect to a systemd mask. Implementing this in
/etc/init.d/rc. And patching the systemd-sysv-generator to match it.
For native systemd services... I would then be able to simply remove all
the `mask` code in dh_systemd_enable, to solve my issue (described in
#864504)
Alan
