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

Borsenkow Andrej Andrej.Borsenkow@mow.siemens.ru
01 Jun 2002 22:40:19 +0400

=F7 =F3=C2=D4, 01.06.2002, =D7 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 =
related to
> > the fact that syslog-ng recreates /dev/log on HUP. It means that =
> > program that has opened syslog connection won't be able to write to =
> > anymore.
> Not quite. I had the same problem with syslog-ng 1.4.something (I =
> I recompiled a Mandrake source rpm on Redhat, but I'm not 100% sure) =
> 1.5.13. When I investigated the problem I found two bugs: One in
> syslog-ng and one in glibc 2.1:
> The bug in syslog-ng was related to recreating /dev/log on HUP. It =
> fixed in 1.5.15, I think (mentioned in the changelog), so I didn't
> bother to report it.=20

I am not as sure:

{pts/1}% rpm -q syslog-ng
{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:
> Apparently[1] the syslog library function works like this:
>     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).
>     Write message to the socket.
>     If this fails, close socket.
> So, if syslog-ng (or syslogd, for that matter[2]) recreates the =
> the next write will fail, syslog will silently drop the message, but =
> 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 =
> how often you switch logs), don't you think?

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 =
> 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 =
> messages, but no "from=3D" messages.
> 	hp
> [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 =
> 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 =
> behaviour if you kill and restart syslogd.

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