[PATCH] Fancy rc startup style RFC

[Eric Anderson]

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.
------------------------------------------------------------------------