4 ms·
My knee-jerk reaction is that this is a terrible idea. Why would someone do this? Is this to workaround programs that respond to logs and can deadlock when log
by geocar 13y ago
My knee-jerk reaction is that this is a terrible idea. Why would someone do this?
Is this to workaround programs that respond to logs and can deadlock when logging (e.g. logrotate)? Workaround other broken programs (noncritical logspam at emergency level)?
- tptacek 13y agoBecause they want to do fine-grained logging in an evented C program, where repeated filesystem access will block and cause the program to stutter.
- mbell 13y agoI would think using an async logging framework is a cleaner and faster approach i.e. something like log4j or glog that does IO in a separate thread. I suppose such an approach is less ideal when using a language that isn't truly concurrent or if the code doesn't run long enough for it to be efficient to spawn a logging thread.
- geocar 13y agoOr just use stdout in those circumstances? Sysadmins are happy to pipe into grep and logger if they need to. We might prefer it if it is that shortlived
- geocar 13y agoSince when did syslog() perform filesystem access? Every implementation I have seen involved a fifo or stream socket write to syslogd. Also: Why are they using LD_PRELOAD to do this? I did not look too closely at the implementation, but are they actually using UDP and just throwing away log entries under load? That is bad engineering.
- knyar 13y agoLosing log data under load (or when your logging system is unavailable) might indeed sound awful, however this is a conscious design decision and the whole purpose of this library. Imagine you are running an application, which is some sort of a network server - it accepts a connection, parses the query, logs it using syslog(), and then returns some sort of response. If it gets blocked while logging, response might be lost or delayed. If serving the request is more important than logging it (which might not be the case for all applications), you might want to ensure that your logging does not block the request processing flow. If there is one application like this and it's open source, you can patch it directly. However, if you have several applications with similar logging behavior or if you cannot modify source code, overriding syslog() allows you to de-couple logging without changing the application. Of course, you should have monitoring in place to catch situations when your logging system cannot keep up (or malfunctions), but when that happens your application keeps running and you only lose your log data.