dlecocq
commented
11 years ago For the sake of keeping track of what ended up happening, we're not planning to implement it. The reason is that with multiple processes, it's kind of tricky to get log rotation right.
Log rotation is typically done in one of two ways: 1) the thing doing the logging keeps track of how much it has written and at then at the appropriate time, rename it, etc. and reopen the file. 2) have logrotate.d watch the file, rename it when appropriate and send a signal to the process to reopen the file.
The logging in the workers is such that the parent opens the log, and the child processes inherit copies of the file descriptor. So it seems we could trap HUP and rotate logs, and then the parent process could just forward 'HUP' to its children. Not terribly messy, but a bit of a pain relative to the alternative. While using the inherited file descriptor is probably ok, reopening said file descriptor from multiple children seems like it will probably cause some problems.
One option is to just log to stdout and pipe output to a utility that either: 1) knows about log rotation based on criteria (like rotatelogs, included with Apache), or 2) knows about reopening files in response to a signal.
I'll post once we've settled on something.
Is it possible to have the qless parent process catch a signal and reopen the logs? This will allow us to use our own logrotate scripts. USR1 is a widely-used signal for telling a process that its log files have changed.