On Thu, Oct 06, 2005 at 03:49:10PM -0400, Brian Akins wrote: > Colm MacCarthaigh wrote: > > >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. > > Maybe I'm just being difficult, but I'm still not sold on it :) While I > understand all that you wrote, the possibilities of getting "partial > line" with normal piped logs irks me. Maybe it's just a personal thing... > > I prefer to have something like: > > length of message, message, sync bit > > (message could be many log lines)
Or you could just do read() on a pipe. If the last character you receive is '\n' then you have a high degree of confidence that you have received an entire line or a number of whole lines. I don't think it's possible for logs generated by Apache to contain newlines mid-way (if there are any such cases, they probably should be fixed) If you're talking about log output from a CGI, then there's nothing to guarantee that a CGI will write anything sensible which ends with newline, or that it will write whole lines atomically rather than writing a few characters at a time (which therefore could get mixed up with stderr output from other CGI processes); but equally you cannot enforce that a CGI uses your tagged protocol either. CGI error logs are a bit of a pain. Since Apache is the parent process, and the CGI is the child, Apache would be a good place to: (a) receive bytes from stderr and reformat them into whole log lines, prefixed by timestamp, server_name etc to allow post-processing; and (b) log the CPU time used by a CGI after it has completed Since Apache does neither of these, I have been doing this in a hacked version of suexec to avoid having to hack mod_cgi itself. This costs an extra fork() in suexec though. Regards, Brian.
