package: debhelper
version: 9.20141003
severity: wishlist

I suspect a lot of folks will be writing  systemd service units in the
future.
While writing units for krb5-kdc, I ran across an issue.

On first install, until you set up your database, it's kind of expected
that krb5-kdc will fail to start.
Systemd is a lot more careful about noticing this than sysvinit, and
gives significantly less flexibility for hiding the error.

I'd really like to say that errors starting krb5-kdc on install or
upgrade should not break the installation run, but errors stopping it in
prerm should.

I can do that using the --error-handler parameter to dh_installinit.
That means I need to actually create an error handler in my prerm and
postinst.
I think this situation is going to be common enough that I want such an
error handler available with a command line option to dh_installinit.

Or perhaps we should decide that ignoring stop errors on upgrade or
uninstall is OK and I can just do --error-handler=true?

Thoughts welcome.

Control: tags -1 moreinfo

Hi Sam,

Thanks for the bug report.

It sounds like you rather want krb5-kdc not to start on initial
installation.  This is doable via the --no-start (possibly combined with
--no-enable).  Note: I do not remember if both these options were
available in 2014 when you filed this bug.

Do you feel that approach handles your particular issue?

Thanks,
~Niels

control: tags -1 -moreinfo

(I hope this supplies the info you need; obviously retag if you have
more questions.)


    Niels> Hi Sam,

    Niels> Thanks for the bug report.

    Niels> It sounds like you rather want krb5-kdc not to start on
    Niels> initial installation.

That's not what I want at all.

I want to try and start it, but I don't want a failure to start to be
considered an error that causes package installation to fail.
This ended up being effectively what happened with the  sysvinit script,
but systemd is much more pro-active at noticing unit start errors.

Sam Hartman:

It did; but it gave me a new question. :) Just remove it again, when you
answer.  I have been using a BTS filter to keep the debhelper bug list
(more) manageable - See [1] vs [2] for comparison (which filters out
about 25% of the open bugs).


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?


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.

Thanks,
~Niels

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debhelper

[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?exclude=tags%3Awontfix;exclude=tags%3Apending;exclude=tags%3Amoreinfo;exclude=tags%3Ahelp;src=debhelper

* Niels Thykier <niels@thykier.net> [180521 05:29]:

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.
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

    Marvin> * Niels Thykier <niels@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?

    Marvin> I'm not sure, so this may not be Sam's issue, but perhaps it
    Marvin> should be attempted to start the service, but it might fail,
    Marvin> and such failure should be ignored.  I'm not sure if
    Marvin> dh_installinit can do different things on initial install
    Marvin> and upgrade, and it almost certainly cannot determine if a
    Marvin> proper configuration has been put in place by the sysadmin
    Marvin> before the initial install that would allow the service to
    Marvin> start correctly.  I don't use krb5-kdc, and don't know what
    Marvin> the real issue is.

My bug can probably be closed.
My bug was filed at a point in time when dh_installinit
1) handled systemd service starting

2) tended to fail every time a systemd unit failed.

It sounds like neither of those are still true.

Marvin Renich:

That sounds like a bug in invoke-rc.d according to the documentation of
`--disclose-deny`:


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