Re: [PATCH] Fancy rc startup style RFC

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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"