Christoph Anton Mitterer <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
