Subject: Re: newsyslog and script execution instead of sending signal to process
To: NetBSD-current Users's Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@planix.com>
List: current-users
Date: 07/17/2007 14:26:32
--pgp-sign-Multipart_Tue_Jul_17_14:26:31_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Mon, 16 Jul 2007 16:55:34 +0930, Brett Lymn wrote:
Subject: Re: newsyslog and script execution instead of sending signal to pr=
ocess
>=20
> There is already this wheel in Solaris called logadm - it allows
> pre/post log roll scripts.

That must be a very new feature in SunOS-5 -- they were in the dark ages
for log management up until recently.  Looks like it's only in 5.9 and
maybe newer.  Looks pretty horrible too -- designed by a committee and
implemented by a co-op student perhaps :-)

Note too that it's poor design and total lack of integration into the
overal system pretty much mandates that it have bot the pre and post
command hooks that it has.


>  Having yet another cron job that is just
> there to watch a directory and move the logs is rather inelegant in
> itself

No, it's not inelegant at all -- that's cron's ideal kind of job, that's
what it does best, that's what it was designed to do.

And no, the purpose would not to be to watch a directory and move the
log again -- the purpose would be to find a log ready to process and
then rename it to a safe and unique name and then actually process it.

> nevermind the race condition if the log is still in the
> process of being rolled when it is moved/compressed.

There is no race condition possible if you do it properly.

And if you're worried about race conditions with log handling then there
are dozens that are completely avoided by doing exactly as I have
suggested and there's no real reduction in race conditions just because
you think it's better to invoke a processing script from within
newsyslog.  That's the biggest fallacy there could be in this
department.  My version of newsyslog attempts to make sure it's the only
copy of itself running, but that's not true of the native version.

There really shouldn't be any issue with invoking both newsyslog and any
number of custom log processing scripts every minute, regardless of
whether newsyslog attempts to serialize its execution or whether it
allows parallel execution.

>  You don't have
> to run the scripts as root - you can always su to the correct user
> before running the roll script (if that is really necessary).

Cron already has this ability to safely run jobs as other users and it's
already cron's job to be invoking other scripts in the first place.

Neither of these things are newsylog's job.

Please try to keep in mind the unix toolbox philosophy -- use the right
tool for the job and don't try to make one tool do multiple different
jobs.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Tue_Jul_17_14:26:31_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: cZauuqKKPJFcq/T92aHU+87llnMxk1cD

iQA/AwUBRp0J12Z9cbd4v/R/EQJ/5ACeKMmoBeVhAmXwKl7X2cvTOY1FF/wAoLJM
vspVaJY9xkSd9lOTq9zR/BDm
=GX+V
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Jul_17_14:26:31_2007-1--