Bug#208010: Require init.d scripts comply with LSB
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> On Thu, 2010-07-29 at 15:14 -0700, Russ Allbery wrote:
>> This is a design principle and design goal for Debian that goes beyond
>> just init scripts. Having a package removed but not purged should not
>> cause errors, send the administrator mail from cron jobs, and so forth.
> I just wanted two things well three... ;)
> 1) Suggesting that it's a good idea to at least suggest usage of LSB
> init script exit codes
I think LSB exit codes are by far the most controversial part of the LSB
proposal, are of dubious utility, and would mean declaring most of Debian
init scripts currently buggy. I would not start here. I think there are
other parts of LSB that can be more easily adopted, such as the header
format (already basically adopted and just requiring documentation) and
the init script actions.
I'm personally unconvinced that adopting the LSB exit code standard is
ever worth doing, but at the least, Policy is not the place to do it,
since it's not even close to existing practice in Debian. This is one of
those places where, if this is something that the project wants to do, it
should be done in the packages first and then documented in Policy once
that work is mostly done, similar to how the init script headers have been
handled.
> 2) At least let initscripts allow to fail (when the package is removed),
> if there's strong reason for them (as e.g. in my dm-crypt example).
Do you have an example of a bug or user problem where the current Debian
Policy caused problems and would have been fixed by having a different
requirement? I suspect this is only a theoretical issue.
> 3) Suggest to reconsider the above for initscripts. It's absolutely
> reasonable that left over configuration files shouldn't be allowed to
> break anything. But IMO it does not in the case of initscripts. You just
> get the warning message,.. but everything's fine.
I'm personally strongly opposed to changing this design principle in
Debian. If the package is removed but not purged, the init script should
not report errors. This is a common case in Debian, and I think it would
be a significant regression to have init scripts start producing errors in
this situation.
> Uhm... ok...
> Imagine a package using the status action from another facility to find
> whether it's running or not.
> If it runs, it starts its own daemon with different options e.g. to make
> use of that daemon.
That sounds like a rather dubious design. Do you have some specific case
in mind where you'd want to do such a thing?
> Now even if status is implemented,... the package of the initscript
> might be removed (!purged)... we get exit 0 then. The script believes
> the status would run. It does however not.
I can see how this is a problem for status in particular, since status has
different exit code requirements than normal init script actions. The
current Policy requirement:
These scripts should not fail obscurely when the configuration files
remain but the package has been removed, as configuration files remain
on the system after the package has been removed.
is still reasonable, but the specific recommendation:
Therefore, you should include a test statement at the top of the
script, like this:
test -f program-executed-later-in-script || exit 0
doesn't really make sense for status; it only makes sense for the init
script actions currently documented in Policy. If we standardize the
status action, we should at the same time alter that advice to not
recommend an 0 exit status for the status action if the package is removed
but not purged.
Exiting with a non-zero status when the daemon isn't running isn't
"failing obscurely" and is fine under the current Policy requirement; it
just doesn't work with the Policy recommendation for how to implement that
requirement.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: