On Mon, Feb 15, 2016 at 4:46 PM Joe Orton <[email protected]> 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
[email protected]
