[syslog-ng]lost logs when using syslog-ng on Linux due to /dev/log reopen

[Peter J. Holzer]

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2002-06-01 22:40:19 +0400, Borsenkow Andrej wrote:
> ? ???, 01.06.2002, ? 00:14, Peter J. Holzer ???????:
> > On 2002-05-28 12:50:04 +0400, Borsenkow Andrej wrote:
> > > I am using syslog-ng on Mandrake (8.2 and post-8.2), glibc-2.2.5.
> > >=20
> > > Unfortunately, it tends to lose logs. As far as I can tell it is rela=
ted to
> > > the fact that syslog-ng recreates /dev/log on HUP. It means that every
> > > program that has opened syslog connection won't be able to write to /=
dev/log
> > > anymore.
> >=20
> > Not quite. I had the same problem with syslog-ng 1.4.something (I think
> > I recompiled a Mandrake source rpm on Redhat, but I'm not 100% sure) and
> > 1.5.13. When I investigated the problem I found two bugs: One in
> > syslog-ng and one in glibc 2.1:
> >=20
> > The bug in syslog-ng was related to recreating /dev/log on HUP. It was
> > fixed in 1.5.15, I think (mentioned in the changelog), so I didn't
> > bother to report it.=20
> >=20
>=20
> I am not as sure:
>=20
> {pts/1}% rpm -q syslog-ng
> syslog-ng-1.5.18-0.3mdk
> {pts/1}% LC_TIME=3DC ll /dev/log
> srw-rw-rw-    1 root     root            0 Jun  1 22:32 /dev/log=3D
> {pts/1}% sudo kill -1 1301
> {pts/1}% LC_TIME=3DC ll /dev/log
> srw-rw-rw-    1 root     root            0 Jun  1 22:33 /dev/log=3D
>=20
> actually it quite happily does recreate /dev/log every time.

Yes, that's ok. Existing connections shouldn't be affected by that. The
problem was (IIRC) that existing connections were thrown away even
though keep-alive(yes) was set. Maybe Bazsi can provide the details, I
gave up trying to understand libol at 4:00 am and the next day I saw
that 1.5.15 was out and it seemed to fix the problem.=20

Before that I already had found a workaround, which I kept using, so I
wouldn't encounter the problem anymore, even if it still existed (I had
tested it, though and couldn't reproduce it anymore):

Don't use logrotate to switch logs - let syslog-ng write to a new file
every day by using a file directive like this:

file("/var/log/$HOST/$YEAR/$MONTH/$DAY/$FACILITY.$PRIORITY"

And then gzip or remove the files after n days.

> > Apparently[1] the syslog library function works like this:
[... why the syslog function in glibc reproducably loses messages ...]
> > Doesn't matter much if you lose one message every 24 hours (or
> > how often you switch logs), don't you think?
> >=20
>=20
> You are not serious, are you?=20

No I'm not. But the guy who wrote the syslog function was obviously
thinking along those lines. Given that syslog has traditionally been
implemented over an unreliable transport protocol (UDP) the assumption
that nobody would rely on getting all messages probably wasn't that
unplausible.=20

> So you mean that it does not matter if
> you lose
>=20
> - early warning about possibly intrusion attempt
>   - or -
> - hardware problem report (like ECC warning)
>   - or -
> - amount of download used for accounting

If you cannot afford to lose messages ocassionally, don't use syslog.
It was never meant for that, as can be seen from the choice of UDP for
transport and the missing return values from openlog(3) and syslog(3).
Some implementations at least use a transport protocol which doesn't
lose packets, but if the server isn't running for some reason, the
client still has no chance of noticing that.

> > [2] Syslogd doesn't recreate the socket on SIGHUP. But you get the same
> > behaviour if you kill and restart syslogd.
> >
>=20
> Yes I know. Actually you just gave perfect explanation why syslog is not
> suitable for mission critical application :(

Yep.=20

	hp

--=20
   _  | Peter J. Holzer     | > Ben=F6tigt man f=FCr Linux einen Virenscann=
er?
|_|_) | Schriftf=FChrer LUGA  | Nein.
| |   | hjp@luga.at         | Linux bootet und l=E4uft auch ohne Virenscann=
er
__/   | http://www.luga.at/ | einwandfrei.	-- Heimo Schoen in al

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8+THAfZ+RkG8quy0RAugbAJ9PMJBXDSpWl7JIvuSXVCxxnPh4hACguqt9
GoRuAwHfm7PUTW0v5onLLJc=
=7iWf
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--