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

[Borsenkow Andrej]

=F7 =F3=C2=D4, 01.06.2002, =D7 00:14, Peter J. Holzer =
=CE=C1=D0=C9=D3=C1=CC:
> 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 =
related 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

I am not as sure:

{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

actually it quite happily does recreate /dev/log every time.

> The bug in libc is more subtle:
>=20
> Apparently[1] the syslog library function works like this:
>=20
>     check if there is an open file descriptor to syslogd. If there is
>     none, try to connect in stream and dgram mode (one of them will
>     usually work).
>=20
>     Write message to the socket.
>=20
>     If this fails, close socket.
>=20
> So, if syslog-ng (or syslogd, for that matter[2]) recreates the =
socket,
> the next write will fail, syslog will silently drop the message, but =
at
> the next syslog call it will reopen the socket and continue to log
> happily. Doesn't matter much if you lose one message every 24 hours =
(or
> how often you switch logs), don't you think?
>=20

You are not serious, are you?  So you mean that it does not matter if
you lose

- early warning about possibly intrusion attempt
  - or -
- hardware problem report (like ECC warning)
  - or -
- amount of download used for accounting


> Unless you have a forking server like sendmail, which calls openlog =
in
> the parent process. Then the socket will always be open but invalid
> after the fork, so you will lose the first syslog message from each
> connection - in the case of sendmail, you will generally only see =
"to=3D"
> messages, but no "from=3D" messages.
>=20
> 	hp
>=20
>=20
> [1] I didn't have the source and was only looking at
> strace-Output, so I may be wrong. Because of this, and because I only
> tested it with glibc 2.1 and wanted to look at 2.2, I haven't =
reported
> this to the glibc maintainer yet. If anyone wants to, feel free.
>
> [2] Syslogd doesn't recreate the socket on SIGHUP. But you get the =
same
> behaviour if you kill and restart syslogd.
>

Yes I know. Actually you just gave perfect explanation why syslog is =
not
suitable for mission critical application :(

-andrej