Marvin Renich:
> * 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?
>
> [...]
>
> 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).
>
That sounds like a bug in invoke-rc.d according to the documentation of
`--disclose-deny`:
--disclose-deny
Return status code 101 instead of status code 0 if
the init script action is denied by the policy layer.
(Or possibly a broken policy).
> [...]
>
> 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
>
As I understand it, the 101 case is handled seemlessly by invoke-rc.d so
there is nothing for debhelper to do on that aspect. Thus, this can be
reduced to "should dh_installinit ignore start failures unconditionally
in all cases?".
>From here, there are about 60-70% of the --error-handler usage which is
just setting it to "true" or a wrapper calling true (krb-kdc) and about
30-40% which is a provided function that does something more complex.
Having ignore failures on startup might be a simplification for the
former 60-70% cases and I could consider doing that in a new compat level.
Thanks,
~Niels
