[PATCH] Fancy rc startup style RFC

[Coleman Kane]

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.

Of course, I am still willing to implement what the consensus is.

--
Coleman Kane