В Сбт, 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.
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.
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:
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.
I am not as sure: {pts/1}% rpm -q syslog-ng syslog-ng-1.5.18-0.3mdk {pts/1}% LC_TIME=C ll /dev/log srw-rw-rw- 1 root root 0 Jun 1 22:32 /dev/log= {pts/1}% sudo kill -1 1301 {pts/1}% LC_TIME=C ll /dev/log srw-rw-rw- 1 root root 0 Jun 1 22:33 /dev/log= 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 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?
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=" messages, but no "from=" 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 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