On Thu, Oct 06, 2005 at 02:06:24PM -0400, Brian Akins wrote: > My problem with piped loggers is there is no fast way to make sure you > have a "complete" line. This is especially hard when you buffer the logs.
If httpd writes a complete line, to any kind of a file descriptor, anything beyond that is out of our control and becomes a question of the quality of the piped logger, filesystem or whatever else is on the other side of that file-descriptor. > Think of a situation where the piped logger is supposed to write to a > socket, for example. If the piped logger has the ability to "fail over" > to another socket, there is a great chance that you may get partial lines. That would be a question of the code and design quality of the piped logger though. Having the code in-httpd just moves the question, it wouldn't remove it. Within the POSIX model though, we should consider piped loggers more reliable for similar scenarios. Piped logging and standard logging are basically just writing to a file descriptor, one which children inherit and in turn just write to. The extreme example is the stderr of an CGI - which can successfully log to a piped logger, because POSIX makes it trivial. Now, imagine we had a few different types of logging in-httpd, MySQL, XML, and all that; in this scenario we can no longer simply write to an fd, instead we have to intercept the writes and mogrify them by some means. The first problem is that this makes error logging really really hard, and the second and even worse problem is that when httpd is crashing we really arn't going to want the complexity of all of that going on. A piped logger on the other hand, lives in a seperate process entirely, relatively isolated from any problems httpd itself may be having, and can be trusted to log the information when a crash is happening. Of course when implementation is bad, bad things happen, but than be applied to anything. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
