Subject: Re: newsyslog and script execution instead of sending signal to process
To: NetBSD-current Users's Discussion List <firstname.lastname@example.org>
From: Brett Lymn <email@example.com>
Date: 07/19/2007 11:16:12
On Wed, Jul 18, 2007 at 03:31:54PM -0400, Greg A. Woods wrote:
> Anyone with any decent amount of experience managing unix systems, and
> I've got a whole hell of a lot more than many people do, can see from
> its manual page alone what its inherent design limitations are.
I am well aware of your experience - you should not assume everyone
else is a neophyte. Having used logadm I can tell you that just
reading the man page you have missed some important facilities.
> If it
> looks and smells like a rock, talks and walks like a rock, feels like a
> rock, and hurts like a rock, then it's either a rock or a very near
> relative of a rock, and we all know what rocks are like.
Yes, but is it kimberlite which may contain a diamond or a chunk of
slate? This is what I was getting at - you are says "oo look, here is
a rock", I am telling you you have missed some important information
because you have only looked at the man page.
> No, not really. newsyslog is meant only to keep syslog files (and other
> similar system log files) from growing to fill all available disk space,
> or more concisely to "maintain system log files to manageable
Oh dear, then I suppose you are going to argue what exactly
constitutes a system log? Why should newsyslog only deal with
syslogd? Isn't that against the unix philosophy? I think it should
be a tool that can, generically, manage logs - the right tool for the
right job instead of reinventing the wheel every time something else
needs to have logs managed.
> Anything over and above that is not, and never was, its job.
So, a syslog log is a totally different and separate thing from a
squid log, apache log, sendmail log, <inser foo here> log? No. We
need a tool that can flexibly handle rotating any log.
> Today the benefits of data compression, even that of historical log
> data, are highly over-rated.
I am glad to see that someone lives in a world where there are vast
vistas of disk to keep a reasonable depth of highly repetitive data.
Some places don't have this luxury and their management have an
expectation that reports can be generated on the data for a reasonable
> As I've explained ad nauseam in another post, it is quite trivial to
> design and implement additional programs which provide further abilities
> to fully "manage" log files, and to do so in a more safe and secure
> manner than could ever be done by extending or enhancing newsyslog.
What you have done is say "here is this round thing, it's not like
that syslog round thing". I have yet to see where you demonstrate
that using newsyslog is any less safe & secure, just saying so does
not make it fact.
> In this case if the person doing
> the design can fully understand and explain why syslogd doesn't create
> the files it writes to then perhaps they're qualified to come up with
> something half-way decent.
Or squid or apache or.... that's the problem there are a lot more
things generating log files apart from syslogd - all the logs should be
managed in a centralised consistent manner.
> Personally I like using config files to gather similar or related
> information about objects or tools, and I'm quite happy with the
> relatively free-style "table" form used by many unix tools.
Who said anything about this not being the case? The solaris
logadm.conf is precisely that - you can edit the file manually.
I may have missed it but I didn't see any mention of a suggested
format for the newsyslog changes - I don't think it progressed that