Bug#680592: lsb-base: reporting errors and diagnostics in init scripts

[Jeff Licquia <licquia@debian.org>]

On 07/07/2012 01:21 AM, Russ Allbery wrote:
> To take an example, the openafs-client init script.  It loads a
> kernel module and then starts a daemon.  It can't load the kernel
> module unless the module is present; if it's not present, it does:
> 
>         cat <<EOF >&2
> AFS module $MODULEDIR/$LIBAFS does not exist.
> Not starting AFS.  Please consider building kernel modules using
> instructions in /usr/share/doc/openafs-client/README.modules
> EOF
> 
> I'm not sure how I should do this using the output functions provided
> by lsb-base.  Converting this to a one-line message feels like it
> would lose information.

It does feel that way.  OTOH, on a starting system, the information you
printed to the console could scroll off-screen and be lost.  With the
lsb-base function, a hook could capture and log that information.  So
there's a tradeoff here, I think.

Would it be acceptable to do something like this:

log_action_msg "Loading AFS module $MODULEDIR/$LIBAFS"
load_afs_module
if afs_module_load_failed; then
  log_failure_msg "Module not found; see \
     /usr/share/doc/openafs-client/README.modules"
fi

(with additional info like the message you currently write put into the
docs)

> Related, using the LSB functions seems to result in hard-to-read
> messages when the daemon that's being started produces an error.
> This is because the format necessarily involves printing out the
> start of a line, then starting a daemon and printing out the end of
> the line, reporting the status.  The traditional Debian output doesn't
> provide much better tools, but with the traditional output format I
> can at least just print out the full startup message first and then
> start the daemon, since the exit status isn't part of the output format.

I've seen that happen with other scripts.  I agree that it probably
involves some arcane shell-fu, but I would think that lsb-base should do
the arcane shell-fu for you.  Something like this:

log_begin_msg "Starting AFS services: afsd"
start_daemon /sbin/afsd || log_start_failure
log_success_msg "."

Success could look something like this:

[ok] Starting AFS services: afsd.

And failure:

[error] Starting AFS services: afsd
afsd: too much mimsy in the borogroves

Where start_daemon would do the funky output capture in a way that
log_start_failure would then be able to use.

(Apologies if I haven't represented Didier's excellent fancy-output
stuff right.)