[PATCH] Fancy rc startup style RFC

[Eric Anderson]

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



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