[PATCH] Fancy rc startup style RFC

[Coleman Kane]

On Wed, May 24, 2006 at 12:29:28PM -0500, Eric Anderson wrote, and it was proclaimed:
> Eric Anderson wrote:
> >Coleman Kane wrote:
> >>On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote:
> >>>On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote:
> >>>>Brooks Davis wrote:
> >>>>>On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote:
> >>>>>>Brooks Davis wrote:
> >>>>>>>On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote:
> >>>>>>>>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.
> >>>>>>>FAILED vs ERROR seems confusing.  I'd be inclined toward WARNING vs
> >>>>>>>FAILED or ERROR.
> >>>>>>True, however I still see a difference between FAILED and WARNING. 
> >>>>>>For instance, as an example: a FAILED RAID is different than a 
> >>>>>>RAID with a WARNING.
> >>>>>For that level of detail, the ability to provide additional output 
> >>>>>seems
> >>>>>like the appropriate solution.
> >>>>Yes, true, but you'd still want to show something (I would think) in 
> >>>>the  [ ]'s to keep it consistent.
> >>>My feeling is that anything short of complete success should report
> >>>WARNING and a message unless it actually totally failed in which case
> >>>FAILED or ERROR (I slightly perfer ERROR) should be used.
> >>>
> >>>-- Brooks
> >>
> >>What situations are we determining get flagged as ERROR versus FAILED?
> >>Is FAILED considered to be 'I was able to run the command, but it
> >>returned an error code', versus ERROR being 'I could not even run the
> >>command!' like bad path, file not found, etc...
> >>
> >>This point still kind of confuses me (and needs to be well defined). I
> >>am an advocate of having three distinct messages: OK, SKIPPED, ERROR.
> >>And not even bothering with the different types of ERROR/FAILED other
> >>than having extra reporting output.
> >
> >I'm ok with just OK, SKIPPED, ERROR..  If there's ever a need for more, 
> >it's easy to add it.
> >
> >Eric
> >
> >
> >
> 
> 
> Is this still planned to make it into -CURRENT?
> 
> Thanks,
> Eric
> 
> 
> -- 
> ------------------------------------------------------------------------
> Eric Anderson        Sr. Systems Administrator        Centaur Technology
> Anything that works is better than anything that doesn't.
> ------------------------------------------------------------------------

Yeah, I've been working on it in my spare time. I am investigating some
avenues regarding status reporting from the rc scripts to the console. 
Also been slow getting some hardware together to put cokane.org back up
and online.

Mostly real-life just got in the way of freebsd for a little while.

--
coleman kane