Date: Wed, 24 May 2006 12:29:28 -0500 From: Eric Anderson <anderson@centtech.com> To: Coleman Kane <cokane@cokane.org> Cc: hackers@freebsd.org Subject: Re: [PATCH] Fancy rc startup style RFC Message-ID: <447497F8.10009@centtech.com> In-Reply-To: <44577B56.70704@centtech.com> References: <20060424131508.GB23163@pint.candc.home> <444CD48A.4060501@centtech.com> <444CE475.30104@centtech.com> <20060430231621.GA551@pint.candc.home> <44557F34.3020906@centtech.com> <20060501190645.GB4315@odin.ac.hmc.edu> <44565DD2.1020604@centtech.com> <20060501191447.GD4315@odin.ac.hmc.edu> <44565E74.3060801@centtech.com> <20060501192920.GE4315@odin.ac.hmc.edu> <20060501212801.GA2254@pint.candc.home> <44577B56.70704@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?447497F8.10009>