I've been looking at converting the rest of the init scripts in my
packages to lsb-base, but it still seems difficult to me to get
good error reporting and longer error messages when using only the
LSB functions. This is the long-overdue bug report in the hope that
the maintainers might be able to help. :)
There are two related problems: I'm not sure how to report verbose
error messages, and I'm not sure how to handle cases where starting
up the daemon produces an error.
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
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.
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.
So, for example, in the openafs-client init script:
which means that any error messages produced by afsd are on their own
line. With the LSB functions, I would normally print the start
message with log_daemon_msg, run afsd, and then run log_end_msg, but
that means that any errors printed by afsd will start at the end of
that line and be rather hard to read.
I could run afsd first and then report its status together with the
start message, but then any errors will be *before* the starting message,
which is awkward and potentially confusing.
I'm not sure if there's any good way around this... all the ways that
I can think of would involve dark magic, like somehow trying to
intercept the output from the daemon. But I thought I'd ask for advice.