[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: [PATCH] Fancy rc startup style RFC
From:       Eric Anderson <anderson () centtech ! com>
Date:       2006-05-25 20:15:53
Message-ID: 44761079.4080801 () centtech ! com
[Download RAW message or body]

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


-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]