[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to use lsb init-functions



Thomas - My apologies for not getting back to you sooner on this; I've
been bouncing around the country due to holidays and job interviews.

On 11/22/05, Thomas Hood <jdthood@yahoo.co.uk> wrote:
> In trying to convert the initscripts in the "initscripts" package to use
> the logging functions in /lib/lsb/init-functions I have run into some
> problems.
>
> Currently there are two sets of functions intended to implement the several
> kinds of messages normally output by Debian and Ubuntu initscripts.  The
> first is for reporting the starting and stopping of services:
>
>     log_daemon_msg "Foo" "bar" ; log_progress_msg "baz" ; log_end_msg 0
>
>     Debian:     Foo: bar baz.
>
>     Ubuntu:     * Foo bar                          [ ok ]
>
> The second is for reporting actions to be taken:
>
>     log_action_msg "Foo"
>
>     Debian:     Foo.
>
>     Ubuntu:     * Foo
>
> The third is for reporting actions to be taken and their completion:
>
>     log_action_begin_msg "Foo" ; log_action_cont_msg "bar" ; log_action_end_msg 0
>
>     Debian:     Foo...bar...done.
>
>     Ubuntu:     * Foo...
>                 * bar...                           [ ok ]
>
> In addition there is a function for reporting success:
>
>     log_success_msg "Foo"
>
>     Debian:    Foo
>
>     Ubuntu:    * Foo
>
> one for reporting failure:
>
>     log_failure_msg "Foo"
>
>     Debian:    * Foo   [asterisk is red]
>
>     Ubuntu:    * Foo   [asterisk is red]
>
> and a function for warning:
>
>     log_warning_msg "Foo"
>
>     Debian:    * Foo   [asterisk is amber]
>
>     Ubuntu:    * Foo   [asterisk is amber]
>
> Finally there is a log_begin_msg which seems to be obsolete.

Note that the success/failure/warning message functions are the ones
specified by the upstream LSB... they aren't very pretty and don't
conform to Debian policy, and there's no real way to kludge them into
doing so.

> Now my question.  Suppose I have a script that does something and I want to do
> the following:
>
>     * Report that foo will be done
>     * Do foo
>     * Report that foo has now been done
>
> I am supposed to do:
>
>     log_action_begin_msg "Will do foo"
>     foo
>     log_action_end_msg $?
>
> But the problem is that foo may produce output and this will break up the nice
> single-line format.  I don't mind deverting stdout to /dev/null, but I am
> reluctant to divert stderr to /dev/null and error messages will also break up
> formatting:
>
>     Debian:    Foo...ERROR
>                failed.   [in red]
>
>     Ubuntu:    * Foo...
>                ERROR
>                                                       [fail]    [in red]
>
> It seems that in many cases we will have to adopt the following schema:
>
>     log_action_msg "Will do foo"
>     if foo ; then log_success_msg "Done foo." ; else log_failure_msg "Foo failed." ; fi
>
> Is this what I should do, or is there another solution I am overlooking; or
> do we need more functions; or does the whole system need to be reworked?

I think if you have a serious worry about stderr, you probably should
2> to a temporary file, then cat it after the failure message if
necessary.

e.g. something like:

f=`tempfile`
log_action_begin_msg "Will do foo"
foo 2>>$f
log_action_end_msg $?
if [ -s $f ]; then
    cat $f >/dev/fd/2
fi
rf -f $f

That idiom might be worth putting into a function in init-functions; I dunno.

Hope this helps...


Chris
--
Chris Lawrence - http://blog.lordsutch.com/

Reply to: