Bug#208010: Require init.d scripts comply with LSB

[Russ Allbery <rra@debian.org>]

Christoph Anton Mitterer <calestyo@scientia.net> writes:

> I recently had a case which made me looking into this and Carsten Hey
> pointed me to that specific bug report here.

> Has there been any progress on this?

> I mean we already use LSB init script headers for dependency based
> booting...

> Many scripts already have the status action (and then follow the exit
> codes as implied by LSB).

> In my opinion it would make sense, to quite closely follow
> http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html in Debian.

It looks like I didn't ever reply to the general question about the status
of this bug, so let me do that.  The following is my opinion about the
current status of this set of related issues.  Other people may have
different takes.  I personally think it would be useful to separate out
the various different things that could change in Debian to support LSB
init scripts and tackle them separately.

LSB init script headers are already widely adopted in the project and need
to be documented in Policy.  This is just waiting for someone to take the
wiki page at http://wiki.debian.org/LSBInitScripts and turn the
documentatino of the LSB header into Policy language and propose it for
inclusion.  I think this is completely uncontroversial and would go in
quickly, so it should be done independent of other LSB issues.

I believe there is general consensus that the status argument to init
scripts would be a good thing to support.  There may be some disagreement
over whether it should go directly into Policy or whether it's more of a
best practice thing.  I would support putting it directly into Policy as a
"should" directive, even though this would make a lot of packages buggy.
That may or may not end up being consensus.  This will also require
modifying the current Policy example of how to make an init script do
nothing when the package is not installed so that it can still return a
negative result to status.

Use of the LSB functions in init scripts and standardization of the output
format is a large and difficult discussion.  I think the first step in
that discussion would be to provide better wrappers around the LSB
functions, since right now using them is much more difficult than it
should be and results in complex and hard-to-read init scripts.  To
properly call those functions now, one has to turn straightforward logic
like:

    echo -n "Starting $DESC: "
    start-stop-daemon -c lbcd -g lbcd --start --quiet \
        --pidfile $PIDDIR$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
    echo "$NAME."

into:

    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    start-stop-daemon -c lbcd -g lbcd --start --quiet \
        --pidfile $PIDDIR$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
    case "$?" in
      0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
      2)   [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac

and it gets considerably worse if you're trying to manage multiple daemons
from the same init script.  We need some better functions for handling
this if we're going to ask people to use those functions across the board.
Only after some better abstractions are available do I think this is
likely to be able to go forward, and even then I think it should go
through the Developer's Reference first.

I think making developers aware of the LSB status codes is a good idea,
but I don't believe there's any consensus on asking all init scripts in
Debian to change.  I think that writing up a best practice for init script
exit codes following the LSB with the exception of how init scripts are
handled when the package is removed but not purged would be a good first
step.  That writeup would belong, IMO, in the Developer's Reference, not
in Policy, at least to start with.

I'm strongly opposed to changing Debian's requirements about init script
behavior when the package is removed but not purged, apart from the status
command, and I'm fairly sure I'm not the only one.  I doubt that
discussion will go anywhere, but of course you're free to try if you want
to.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>