Date: Tue, 25 Feb 2003 12:55:48 -0800 From: Wes Peters <wes@softweyr.com> To: Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes Message-ID: <200302251255.48219.wes@softweyr.com> In-Reply-To: <p05200f1fba807dbb60c0@[128.113.24.47]> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <p05200f08ba7b59fffe0a@[128.113.24.47]> <p05200f1fba807dbb60c0@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 24 February 2003 18:08, Garance A Drosihn wrote:
> At 11:35 PM -0500 2/20/03, Garance A Drosihn wrote:
>
> >I'll soon have a second update, which will implement "-R requestor",
> >which Wes could then take advantage of with his syslog changes.
>
> Here is the second patch. This implements a -R option, where
> -R requires a name of the requestor, and it also requires that
> a list of filenames to rotate was given on the newsyslog command.
> Right now the "requestor" is only used in the message added to
> (non-binary) log files.
>
> The idea of -R is that newsyslog should always rotate the given
> list of files, whether or not *it* thinks they need to be rotated.
> It is only being used to govern how each of the files are rotated
> (such as gzip vs bzip2, and how many backup copies to keep).
Ah, good idea. We have the ability to "backup" a running system into a
file that can be used to restore it later on. We'd like to essentially
terminate all the log files in this backup and start the system with
fresh logs. This change will help us do that as well.
> For now it is assumed that the caller is the same process which
> usually writes to the file, and thus it does NOT use the pid_file
> to signal that process. The whole idea of this is to let Wes
> change syslogd to use this, and it would be silly for newsyslog
> to HUP syslogd when it's syslogd that is requesting the rotate.
> It may be that we should handle the pid-file signalling a
> different way.
Uh, actually, syslogd needs the HUP to re-open the file. ;^)
I can change that iff I run newsyslog -F, waiting for the "new" log file
to appear. Let me think about how to best do that...
Come to think of it, my current code doesn't do a very good job of
reaping the child newsyslog processes. That's going to need some work
anyhow, so I can probably do it there. I do like the idea of not
needing a HUP signal between the two since syslogd started the
newsyslog anyhow.
I'll get this hacked up ASAP, then get some of these patches out for
review.
> This is meant to be the "minimal change that gets the job done".
> I expect to make additional changes to newsyslog which will clean
> this up a bit more (while cleaning up some other things too).
>
> Let me know if there are any better ideas for this. I'll probably
> commit this on Thursday night unless there's some objections, or
> if someone wants some more time to think about it.
It sounds good to me. I'll review your patch, then dump it into my
newsyslog for testing, so I can make sure I run newsyslog correctly.
Thanks for the collaboration.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302251255.48219.wes>