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.
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.
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. 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?
You are not serious, are you?
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.
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
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.
Yes I know. Actually you just gave perfect explanation why syslog is not suitable for mission critical application :(
Yep. hp -- _ | Peter J. Holzer | > Benötigt man für Linux einen Virenscanner? |_|_) | Schriftführer LUGA | Nein. | | | hjp@luga.at | Linux bootet und läuft auch ohne Virenscanner __/ | http://www.luga.at/ | einwandfrei. -- Heimo Schoen in al