On Mon, Feb 15, 2016 at 4:46 PM Joe Orton <jor...@redhat.com> wrote: > > On Fri, Feb 12, 2016 at 02:25:49PM -0500, Eric Covener wrote: > > Recall that 2.2 ran piped loggers under a shell until somewhat late in > > life, and 2.4 runs them directly [by default]. > > > > rotatelogs currently doesn't do anything to block sigterm. The > > default ahndler for sigterm writes a short message to stderr, which is > > the only reason I noticed. > > > > It seems like a lose/lose scenario though: > > > > If rotatelogs exits early due to sigterm before all writing ends of > > the pipe are closed, it's not there to log the stragglers for e.g. a > > graceful restart > > If rotatelogs waits... then replacement rotatelogs processes are > > likely to write to the same log [if using time based rotation]. > > > > Any other ideas/observations/trivia? > > I've looked at this before too but got lost in the second problem, the > implications of having multiple concurrent piped loggers. If we really > want to allow that we need to make rotatelogs assume atomic log writes > and probably drop various (mis-?)features like -t. > > It certainly seems to make more sense to design the logging interface as > "log everything from stdin till you read EOF", rather than "log > everything until you get randomly SIGTERMed". I've also wondered > whether it's right to restart the piped loggers during a restart if the > config hasn't actually changed. That might make this problem a bit > easier, not sure. > > Regards, Joe
Something tangentially reminded me of this thread. Does anyone see harm in reversing the order here so that if a piped logger gets EOF and exits, it doesn't have to also worry about signals? server/log.c: static apr_status_t piped_log_cleanup_for_exec(void *data) { piped_log *pl = data; apr_file_close(pl->read_fd); apr_file_close(pl->write_fd); return APR_SUCCESS; } static apr_status_t piped_log_cleanup(void *data) { piped_log *pl = data; if (pl->pid != NULL) { apr_proc_kill(pl->pid, SIGTERM); } return piped_log_cleanup_for_exec(data); } -- Eric Covener cove...@gmail.com