[PATCH] Fancy rc startup style RFC

[Eric Anderson]

On 05/25/06 15:15, Eric Anderson wrote:
> Coleman Kane wrote:
>> 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
> 
> 
> Ok - just making sure it had not been forgotten. :)
> 
> Thanks Coleman!
> 
> Eric
> 
> 

Any progress on this?  Maybe another committer could take a look at it 
if you are too busy?

Eric



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