Date: Sat, 17 Apr 2004 19:18:43 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Melvyn Sopacua <freebsd-questions@webteckies.org> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: ipmon fills up partition Message-ID: <20040417181843.GA90463@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <200404171831.32687.freebsd-questions@webteckies.org> References: <20040416230102.H2835@ybpnyubfg> <20040417160012.GA75477@happy-idiot-talk.infracaninophile.co.uk> <200404171831.32687.freebsd-questions@webteckies.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Apr 17, 2004 at 06:31:24PM +0200, Melvyn Sopacua wrote:
> On Saturday 17 April 2004 18:00, Matthew Seaman wrote:
>=20
> > > Adding /var/run/ipmon.pid at the end of newsyslog.conf line above sto=
ps
> > > 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.
>=20
> It does:
> ipmon.c:1452
> if (donehup) {
> donehup =3D 0;
> if (newlog) {
> fclose(log);
> log =3D newlog;
> newlog =3D NULL;
> }
> }
>=20
>=20
> And:
> static void handlehup(sig)
> int sig;
> {
> FILE *fp;
>=20
> signal(SIGHUP, handlehup);
> if (logfile && (fp =3D fopen(logfile, "a")))
> newlog =3D fp;
> init_tabs();
> donehup =3D 1;
> }
>=20
> The only codepath I can see, that could cause this behavior, would be if =
the=20
> fopen fails, because newsyslog is holding a lock on the file at the time =
it=20
> 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
--=20
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
--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAgXUDdtESqEQa7a0RAvs5AKCSMcI8msLU8/7CwFRPJN7ZqVC18gCggi7Q
p/5Nxb4BjhW4HXauVREeQio=
=HSM7
-----END PGP SIGNATURE-----
--azLHFNyN32YCQGCU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040417181843.GA90463>