Re: [PATCH] Fancy rc startup style RFC

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