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

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to