Re: Logging practices (and why does it suck in Debian?)
On Wed, 11 Apr 2001, Jamie Heilman wrote:
> Dan Bernstein's multilog program is the only logger I've seen that offers
> various reliability guarentees and actually delivers on them, but it has
> some prerequisites for usage that can frequently be difficult to meet.
> What I'd really like to see is a facility logger that could collect logs
> like traditional syslog but then would let me hand them to something like
> multilog to be stored on disk.
I wrote something like that some time ago. Basically a listener that
listens on /dev/log and sends it to multilog, or anything that
reads from stdin. With multilog doing the logging there is no need for a
crond to call logrotate anymore. Unless you need crond for other
Of course, I may have made some horrible assumptions and introduced some
really bad bugs when I wrote this, so just audit the source yourself :-)
Also, I have some similar code somewhere, probably on my non networked
host at home, that uses select() on two sockets, one being /dev/log and
the other a UDP network thing, so you can also log remote things.
There were some issues with klogd, or at least, someone reported
issues. I never had any problems, I simply started klogd after gluelog
and it worked. I know it is possible to modify the code to read from
/proc/kmsg instead, then you can also replace klogd.
The only problem with this code is that it does not do any filtering based
on the "facilities", and it simply dumps them to a file as is, ie, you get
the ugly numbers straight into the file.
Anyway, the code is unmaintained atm, so if anyone wants to take over and
do something with it, be my guest :-) It is of course GPL'ed.
I also remember seeing a solution with some kind of preloaded library that
makes writes to the syslog go to stdout instead. You can then simply pipe
it into multilog.
Izak Burger (email@example.com)
Tel. +27 83 274 9199
chown -R us.enemy your_base