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 [EMAIL PROTECTED] 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/
How to use lsb init-functions
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. 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? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
On Tue, Nov 22, 2005 at 12:21:37PM +0100, Thomas Hood wrote: 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: I'm thinking that it would be very useful to redirect stderr to a file (say /var/log/boot/pacakge.error). It happens far too often that the error message scrolls off the screen, then fonty/gdm/etc. starts making scrolling back impossible. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
[Gabor Gombas] I'm thinking that it would be very useful to redirect stderr to a file (say /var/log/boot/pacakge.error). It happens far too often that the error message scrolls off the screen, then fonty/gdm/etc. starts making scrolling back impossible. There are ideas to send boot messages to syslog (bootlogd does this, but not very well), and it might be a better alternative then a separate file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
Only a thought that occured to me when reading this: Did you think about how your approach will work once the proposed parallel boot script execution is implemented? Best regards Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
On Tue, 22 Nov 2005, Benjamin Mesing wrote: Only a thought that occured to me when reading this: Did you think about how your approach will work once the proposed parallel boot script execution is implemented? It will be replaced by whatever is in the parallel system. So don't worry too much about it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
Benjamin Mesing wrote: Only a thought that occured to me when reading this: Did you think about how your approach will work once the proposed parallel boot script execution is implemented? If you want to see how it could look like when you have scripts with parallel output you could have a look at Initng [1]. The output of the scripts will be buffered and the init system will handle the it in some non parallel way. Regards, Armin [1] http://alioth.debian.org/projects/pkg-initng/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
