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
