* Niels Thykier <ni...@thykier.net> [180521 05:29]:
> As I understood your original mail, it sounded like we expect the
> service to fail because the user has not configured it yet. I think I
> am missing the point of having it start automatically if it will not
> work out of the box.
> Can you elaborate on what makes you want it to start automatically?
I'm not sure, so this may not be Sam's issue, but perhaps it should be
attempted to start the service, but it might fail, and such failure
should be ignored. I'm not sure if dh_installinit can do different
things on initial install and upgrade, and it almost certainly cannot
determine if a proper configuration has been put in place by the
sysadmin before the initial install that would allow the service to
start correctly. I don't use krb5-kdc, and don't know what the real
issue is.
> Note that debhelper's tooling for init scripts vs. systemd has the
> asymmetry that the systemd tooling ignores all failures basically. As I
> understood the systemd maintainers who wrote the original systemd
> tooling, they were of the mind that failing installation because a
> service fails to start was not desirable.
> But unlike sysvinit, systemd makes it easy for the administrator to
> tell which services have issues - so I am a bit hesitant to make these
> symmetric in general.
My bug is very closely related; tell me if I should file it separately.
I am approaching this from a different perspective: that of a sysadmin
who has deliberately ensured that a service (docker in this case) will
not start automatically, by setting all the rc*.d links to "K01docker".
On every upgrade, this causes the installation to be stuck in a
half-configured state (from dpkg's pov). I must manually edit the
postinst script to complete the upgrade, and my edit is lost during the
next upgrade.
This is, in my opinion, a normal, not wishlist, bug. And, it is
probably a bug in both dh_installinit and invoke-rc.d. In the man page
for invoke-rc.d, it says status codes 1-99 are reserved for the init.d
script, and:
101 Action not allowed. The requested action will not be performed
because of runlevel or local policy constraints.
The actual return code from invoke-rc.d for my case is 1, but should be
101 according to the man page (runlevel does not allow start or
restart).
But whether or not invoke-rc.d is fixed, dh_installinit will emit code
that ignores the sysadmin's explicit configuration and causes a failure
at upgrade (or initial installation).
I suspect that 99.9% of all Debian packages that have services should
not treat failure of the service to start during installation or upgrade
as a dpkg failure. At worst, it is a bug in the package. Since a bug
in a non-service executable that causes the executable to crash
immediately when invoked from the command line (e.g. if ls were to cause
a segfault) is not treated as an installation failure, why should a bug
in the package that causes the service to fail to start be treated
differently?
I think you should change dh_installinit so that if invoke-rc.d returns
101, you should treat it as success for the postinst's purposes, and any
other return code (other than 0) should produce a warning, but not fail
the postinst.
...Marvin
