Re: [logcheck] I hear you...

[karlheg@hegbloom.net (Karl M. Hegbloom)]

>>>>> "Alec" == Alec Smith <alec@shadowstar.net> writes:

    Alec> On 24 Nov 2001, Karl M. Hegbloom wrote:
    >> Perhaps we should assimilate "chkconfig" then?  Embrace and extend
    >> it?
    >> 
    >> I kind of like that [Ok] green lights thing they do with the init.d
    >> output also.  If that is accomplished in a suitably object oriented
    >> style; that is, through a documented call interface... the actual
    >> output routine can be changed and made to do special things.
    >> 
    >> What ever got done with that dependancy based init script setup that
    >> got tossed around for a while?  Has anyone ever implemented it?

    Alec> The whole [OK], [FAILED], etc thing that RedHat does with
    Alec> colors is nice, but not really necessary. While some
    Alec> additional things can be useful, others are mainly eye
    Alec> candy. I believe adding the kind of success/failure system
    Alec> RedHat uses is mainly eyecandy.

 But that "eyecandy" gives it a "more finished", "polished", "sexy",
 or "professional" look.  Compare a Debian box booting to a Red Hat
 one (prior to the inevitable upgrade to Debian; ahmen brothers and
 seesters).  Which one is more estheticly appealing, to anyone besides
 it's mother or maintainer fanatic association?

 On the Empcoreour's New Red Hat machine, you can see right away, from
 across the room even, that either all services are started, or that
 some have failed.  On the Debian machine, you must read each message.
 The green [OK] lights are more than just eye candy -- they have
 practical utility as well.

 I think we can take it a step or two farther than mere colored
 lights.  If all output goes not through "echo", but through a
 function or program, it can not only be formatted nicely, with a
 blank line between each script's output, for instance, it can be
 logged, next to the boot time dmesg log.  Both stderr and stdout must
 be logged there...  What other requirements and wishlists are there
 for this?

 A program, rather than a function, might be better, in case an init.d
 script is written in something other than shell?  Hmmm.  They appear
 to all be shell scripts on my machine, so never mind.

 One thing that bugs me, that I see also on Red Hat and Mandrake
 machines, is when a module gets inserted, the kernel printk's with no
 regard for what your init.d scripts are printing.  The "dmesg"
 command can be used to control the kernel console logging level.  It
 should be squelched unless output is desired, and then, unsquelched
 only around the block where we are explicitly modprobing, perhaps.

 Error output from subprograms often screws up the display also...blah: file or directory not found
 done.

 Ick.  The stderr from those commands ought to be caught, captured,
 and printed under supervision:

 Handing system control over to dufus...                        [OK]

 Installing super-duper cracker-snoop kernel override module... [FAIL]
 ERROR: modprobe: sdcs.o: no such file or directory

 ^^^ blank line between them, "ERROR:" and "[FAIL]" in red.  Maybe
 stderr in brightyellow?  Make it stand out.  The RH scripts try to be
 careful to only use color control codes when the terminal can use
 them.  I don't know how well that works with serial consoles...  Does
 anyone else?  Did they get it right?  If I've got a control console
 with a minified xterm open to the serial console of each of 10
 machines in a cluster, do I see green lights?

 ... I suppose that in that situation, the output via a function
 really comes in handy.  A special little setup could be made that
 sends that info to the management console, perhaps via SNMP traps.

 Is there any way of capturing the kernel printk output?  Hmmm... the
 klogd does it.  Perhaps it can provide us with some feedback?  Can
 two processes read from the same pipe and both get the same data?  Or
 would klogd need to temporarily hand us a copy, during the bootup
 phase?

    Alec> Personally I've never had any problems with the current
    Alec> system startup script system, other than a tool like
    Alec> chkconfig being useful. Actually, I'd be willing to bet
    Alec> update-rc.d could be extended to support similar
    Alec> functionality.

 If we are name and interface compatible with "chkconfig" perhaps we
 wind up being able to utilize some tools assimilated from RH?  (Let
 us not forget the the "install-info" debacle.)

 <rhetorical /What does the LSB say, I wonder?/

-- 
I was Linux when Linux wasn't cool.