On Wed, 2005-06-15 at 20:08 +1200, Jason Haar wrote:
Balazs Scheidler wrote:
Basically, this is how it was designed to work. The syslog() call in libc uses a blocking call to send messages to syslogd, if the socket is opened (e.g. syslogd is running) then there's no timeout involved.
So am alarm around the call should stop an app from hanging forever (i.e. set an alarm of 10 sec, call syslog and if it hasn't returned after 10 secs, the alarm will kill that exec)? Is there any way I can emulate this condition? I tried sending a STOP signal to syslog-ng - it stopped outputting to the syslog file all right - but didn't cause any apps to hang - so it's not quite what I'm after...
[I have an app I wrote that writes to syslog that I'm now concerned for it's reliability now that I've experienced this]
Thanks! Now that I've installed syslog-ng - I'm *not* expecting to come into work to see the same condition tomorrow ;-)
syslog-ng is not different in that regard from stock syslogd, if syslog-ng stops, and /dev/log is unix-stream then the application is going to block. if /dev/log is unix-dgram then it will probably not (I have not tested this myself), though in this case the log message will be dropped. I don't know whether alarm() is a good choice, I prefer not to rely on it too much as it might interfere with low-level libraries (libc might retry sending the message if it receives an EINTR from send() that alarm would cause) -- Bazsi