[PATCH] Fancy rc startup style RFC

[Eric Anderson]

Coleman Kane wrote:
> On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote:
>> Eric Anderson wrote:
>>
>> Actually, some other things got changed somewhere in the history, that 
>> broke some things and assumptions I was making.  This patch has them 
>> fixed, and I've tested it with all the different options:
>>
>> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9
>>
>> It's missing the defaults/rc.conf diffs, but you should already know those.
>>
>>
>> Eric
>>
> 
> I have a new patch (to 7-CURRENT) of the "fancy_rc" updates.
> 
> This allows the use of:
> rc_fancy="YES"        --->  Turns on fancy reporting (w/o color)
> rc_fancy_color="YES"  --->  Turns on fancy reporting (w/ color), needs
>                             rc_fancy="YES"
> rc_fancy_colour="YES" --->  Same as above for you on the other side of
>                             the pond.
> rc_fancy_verbose="YES" -->  Turn on more verbose activity messages.
>                             This will cause what appear to be "false
> 			    positives", where an unused service is
> 			    "OK" instead of "SKIP".
> 
> You can also customize the colors, the widths of the message
> brackets (e.g. [   OK   ] vs. [ OK ]), the screen width, and
> the contents of the message (OK versus GOOD versus BUENO).
> 
> Also, we have the following message combinations:
> OK   --->  Universal good message
> SKIP,SKIPPED ---> Two methods for conveying the same idea?
> ERROR,FAILED ---> Ditto above, for failure cases
> 
> Should we just have 3 different messages, rather than 5 messages
> in 3 categories?

Yes, that's something that started with my first patch, and never got 
ironed out.  I think it should be:
OK
SKIPPED
FAILED
and possibly also:
ERROR

The difference between FAILED and ERROR would be that FAILED means the 
service did not start at all, and ERROR means it started but had some 
kind of error response.


> TODO: One thing I am trying to figure out is how to get the
>       terminal to report its width, in columns (which is something
>       that VT100+ supports). I just don't know how to do it from a
>       script.

I looked into that too, without finding a good way to do that.


> TODO: Get better reporting from the rc.d/* scripts (and whatever
>       other services we track). Right now, if verbose is on, many
>       services respond with OK when they aren't initialized, and
>       some respond with SKIP/SKIPPED/FAILED. E.g.: pcvt will show
>       "SKIP", but geli2 will show "OK". Neither of these two are
>       enabled for me though.


I agree here, and started looking into many of the scripts there now. 
There are a lot that need tweaking, but in the long run, I think it 
would be very nice and clean, and allow for some nice reporting and logging.

> You may get it from here:
> http://www.cokane.org/files/rc_fancy-cokane5.patch
> 
> 
> Further:
> 
> I am very open to suggestions regarding the rc.d/* system and its
> reporting mechanisms. I am even thinking that it might be a good 
> idea to offer an overhauled set of scripts that forces functionality
> into the following framework:
> rc job offers result code (from which the OK,SKIP,ERROR, etc... are
> picked)
> rc job offers short (< 20 char) status message. This could be printed
> in a nice fashion just after the "Running start XXX", "Running stop
> YYY", which we currently display.
> rc job (or rc itself) offers name of job (geli2, moused, etc...).
> 
> Thus, the lines are nice, consistent, and fluid. The "short status
> message" above would most likely be truncated to 20 chars (or so.).
> 
> Hopefully, some of this can then start to be put into an rc-reporter
> such that I could run a command that could give me a nice report of
> rc/init:
> moused      FAILED                            "short message"
> 
> Gentoo has a nice script named rc-status that does similar. Though
> I am not too fond of its output format (job name at left, status at 
> right edge, hard to find out what failed in a multiline report).
> 
> Try this latest version, and drop a line back with your thoughts,
> criticisms, etc....


Thanks again for taking hold of this and driving it further!


Eric




-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------