ipmon fills up partition
Dear list, I use ipfilter exclusively in all the FreeBSD systems I ever set up / administer since FreeBSD 4.x at least. In addition, in all my systems I have a habit of logging ipfilter to a different file, by using the following setting in /etc/rc.conf:- ipmon_enable=YES ipmon_flags=-D /var/log/ipflog and rotating it in newsyslog.conf:- /var/log/ipflog 640 7 1000 * J Reason for this is I also turn on /var/log/all.log (logging everything), so default ipmon settings tend to clutter the logs. Anyway, since FreeBSD v5.x (been using it since a while before 5.0-RELEASE), in at least 3 of the machines I administer, rotation works fine, and ipmon resumes logging afterwards. However the partition where /var/log/ipflog resides gradually fills up, until 100% full. Curiously, killing ipmon process releases back the space taken. Adding /var/run/ipmon.pid at the end of newsyslog.conf line above stops the above symptom, but ipmon stopped logging after each rotation. My last resort is to cook up own rotation, as some ppl have done here:- http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8threadm=br00p7%24b9o%241%40FreeBSD.csie.NCTU.edu.twrnum=5prev=/groups%3Fq%3Dipmon%2Brotation%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd But before that, any other ideas? Should I send-pr? Thanks. --mendonan Yang mimpikan secangkir kopi panas dengan selimut.. (Dreaming of a cup of hot coffee, and a blanket..) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipmon fills up partition
On Sat, Apr 17, 2004 at 10:16:26PM +0800, Canggung Mendonan wrote: I use ipfilter exclusively in all the FreeBSD systems I ever set up / administer since FreeBSD 4.x at least. In addition, in all my systems I have a habit of logging ipfilter to a different file, by using the following setting in /etc/rc.conf:- ipmon_enable=YES ipmon_flags=-D /var/log/ipflog and rotating it in newsyslog.conf:- /var/log/ipflog 640 7 1000 * J Reason for this is I also turn on /var/log/all.log (logging everything), so default ipmon settings tend to clutter the logs. Anyway, since FreeBSD v5.x (been using it since a while before 5.0-RELEASE), in at least 3 of the machines I administer, rotation works fine, and ipmon resumes logging afterwards. However the partition where /var/log/ipflog resides gradually fills up, until 100% full. Curiously, killing ipmon process releases back the space taken. Yes. This is one of those unixy things that makes a great deal of sense only after you've stopped and thought about it for a while. What's happening is this: ipmon has an open filehandle onto the logfile it's writing. Which means that even if you delete the file or overwrite it in the filesystem, the kernel still sees that file as active and doesn't free up the space it takes until the ipmon process closes the file. There's a conceptual difference between a file name -- which is just an entry in a directory structure with a pointer to the file's location -- and to the file itself. A file can have many different names in many directories so long as they are all on the same filesystem -- this is the concept known as 'hard linking' as described in ln(1). A file is only deleted once all filesystem links to it have been removed and all open file descriptors on it have been closed. Adding /var/run/ipmon.pid at the end of newsyslog.conf line above stops the above symptom, but ipmon stopped logging after each rotation. This should be the correct thing to do: ipmon should interpret a HUP signal to mean 'reopen log files' -- unless it's changed dramatically between 4.x and 5.x[*], in which case you'll have to hunt down what should be done instead by reading the documentation or the code or something. Have you tried recompiling without any extra optimization and without and CPUTYPE flags? Is your system up-to-date with the latest patches for whatever code branch you're tracking, and does your kernel match correctly with the system you're using (ie. they were both compiled from the same sources and you followed the procedure in /usr/src/UPDATING to do any upgrades)? Does the ipmon process actually quit when sent a SIGHUP? If the answer is yes to two or more of those, then it's worth using send-pr(1) to report this as a bug. Cheers, Matthew [*] It hasn't, at least in this respect, as can be seen using cvsweb. -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: ipmon fills up partition
On Saturday 17 April 2004 18:00, Matthew Seaman wrote:
Adding /var/run/ipmon.pid at the end of newsyslog.conf line above stops
the above symptom, but ipmon stopped logging after each rotation.
This should be the correct thing to do: ipmon should interpret a HUP
signal to mean 'reopen log files' -- unless it's changed dramatically
between 4.x and 5.x[*], in which case you'll have to hunt down what
should be done instead by reading the documentation or the code or
something.
It does:
ipmon.c:1452
if (donehup) {
donehup = 0;
if (newlog) {
fclose(log);
log = newlog;
newlog = NULL;
}
}
And:
static void handlehup(sig)
int sig;
{
FILE*fp;
signal(SIGHUP, handlehup);
if (logfile (fp = fopen(logfile, a)))
newlog = fp;
init_tabs();
donehup = 1;
}
The only codepath I can see, that could cause this behavior, would be if the
fopen fails, because newsyslog is holding a lock on the file at the time it
signals ipmon.
--
Melvyn
===
FreeBSD sarevok.webteckies.org 5.2-CURRENT FreeBSD 5.2-CURRENT #3: Sun Apr 4
02:24:06 CEST 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOAPM_NODEBUG i386
===
pgp0.pgp
Description: signature
Re: ipmon fills up partition
On Sat, Apr 17, 2004 at 06:31:24PM +0200, Melvyn Sopacua wrote:
On Saturday 17 April 2004 18:00, Matthew Seaman wrote:
Adding /var/run/ipmon.pid at the end of newsyslog.conf line above stops
the above symptom, but ipmon stopped logging after each rotation.
This should be the correct thing to do: ipmon should interpret a HUP
signal to mean 'reopen log files' -- unless it's changed dramatically
between 4.x and 5.x[*], in which case you'll have to hunt down what
should be done instead by reading the documentation or the code or
something.
It does:
ipmon.c:1452
if (donehup) {
donehup = 0;
if (newlog) {
fclose(log);
log = newlog;
newlog = NULL;
}
}
And:
static void handlehup(sig)
int sig;
{
FILE*fp;
signal(SIGHUP, handlehup);
if (logfile (fp = fopen(logfile, a)))
newlog = fp;
init_tabs();
donehup = 1;
}
The only codepath I can see, that could cause this behavior, would be if the
fopen fails, because newsyslog is holding a lock on the file at the time it
signals ipmon.
Yes. It's not obvious what's wrong. However, if donehup is non-zero,
and logfile is not NULL but newlog is still NULL, then the fopen() in
the signal handler must have failed -- and it should be quite simple
to track that in a debugger or instrument the code to show that is
what's happening. If it had failed, then the logging data would still
go to the old log file, but that's not what was observed.
I kind of wonder why it opens the new logfile, reallocates and
populates a bunch of lookup tables in the signal handler, but then
waits until the next time round main event loop to actually close the
old logfile and switch to the newly opened logfile for writing the log
data to. Why not leave the logfile open to the main loop as well? But
I'm no expert on these things.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
pgp0.pgp
Description: PGP signature
