Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jan 1998 16:40:45 -0200 (EDT)
From:      Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>
To:        tom@sdf.com (Tom)
Cc:        danny@panda.hilink.com.au, freebsd-hackers@FreeBSD.ORG
Subject:   Re: 2nd call for comments: New option for newsyslog
Message-ID:  <199801171840.QAA16473@gaia.coppe.ufrj.br>
In-Reply-To: <Pine.BSF.3.95q.980116232602.7843A-100000@misery.sdf.com> from Tom at "Jan 16, 98 11:39:42 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
#define quoting(Tom)
// On Sat, 17 Jan 1998, Daniel O'Callaghan wrote:
// > On Fri, 16 Jan 1998, Tom wrote:
// > > On Sat, 17 Jan 1998, Daniel O'Callaghan wrote:
// > > > I'm added a '-m' option to newsyslog which will allow it to process log 
// > > ...
// > > > Does anyone have any comments, positive or negative, about this extension 
// > > > to newsyslog?  I'd like to get this reviewed and into 2.2.6.
// > > 
// > >   I submitted on the PRs on this issue...

I've also submitted one PR about this problem, so I think I may comment 
a little here.

// > >   "-m" seems a bit specific.  What about weekly and daily options too?  If
// > > you do, newsyslog starts looking a lot like cron.  Using newsyslog to
// > > rotate non-syslog created log files is rather a stretch.  Using newsyslog
// > > for non-text "logs" is even more of stretch.
// > 
// > >   Perhaps wtmp rotation should just be done by cron right in the monthly
// > > script, where the accounting processing happens?
// > 
// > Valid points, but I don't see any reason not to use newsyslog for 
// > rotating a logfile.  newsyslog has the nice feature of rotating on size, 
// > which is irrelevant to the current problem, but it also gzips and rotates 
// > the gzipped files, which is nice.  Why create a bunch of Bourne shell 
// > commands, when an entry in newsyslog.conf will suffice?

Maybe it would be better to make a generic shell script to do file
rotation.  It would need some flags, like gzip compression needed,
etc.  It could be used by user scripts also.  I have some that would
be much simpler with such program available.

//   Well first all no _new_ Bourne shell scripts would be required, as we
// already have the accounting script in /etc/periodic/monthly.  For other,
// non-accounting stuff, you are still going to require special processing
// that newsyslog will _not_ do (like a log analyzer).

I think newsyslog needs an improvement, but not this one proposed by
Daniel.  newsyslog could have an extra parameter specifying a progrma
to run with the log file as argument.  This program would do something
after the log file is roteated, but before it's compressed.  If not
specified, use the default kill -HUP syslogd.

But this would not solve the wtmp problem.  It's more reasonable to 
get the wtmp logs once a month, and I must agree with Tom that this
kind of behaviour is cron's task, not newsyslog task.

The new newsyslog behaviour would be useful for squid logs, for example.

//   gzip is useless for user accounting, as you can't process the previous
// months info if it is gzipped.  You need to rotate the file, process it,
// then gzip it.  This is probably better handled by adding rotation to 
// existing script.

Is it easy to add libz support to last(1) and who(1) ?  This would help
administrators back analyse these logs.

// > As for the daily and weekly options, there are always 24 hours in a day
// > and 168 hours in a week, so fixed period rotations are correctly handled. 
// > Or are they?  In fact, rotating every 24 or 168 hours may not be what was
// > wanted, if the sysadmin really wants the files rotated as close as
// > possible to midnight with the week starting on Sunday. 
// 
//   In some cases, accurate midnight rotation is critical.  

Agree.  Accounting for billing, for example.

//   newsyslog works well when you need to rotate syslog logs, but if you
// need to do some pre or post processing too (like the login accounting
// problem), you might as well use cron.  You are going to have to create
// lots of shell scripts for all of these pre and post processing jobs
// anyhow, so you might as well let cron process it.
//
//   I feel uncomfortable for using newsyslog for processing anything other
// than syslog generated logs, especially considering how newsyslog HUPs
// syslog whenever it moves a log file.

Would the modification I proposed above satisfy you ?

					Jonny

--
Joao Carlos Mendes Luis			jonny@gta.ufrj.br
+55 21 290-4698				jonny@coppe.ufrj.br
Universidade Federal do Rio de Janeiro	UFRJ/COPPE/CISI
PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2  83 5F E3 26 BF 0F EA 67



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801171840.QAA16473>