On 5/15/05, Joe Orton <[EMAIL PROTECTED]> wrote: > On Sun, May 15, 2005 at 09:22:57AM -0400, Jeff Trawick wrote: > ... > > >Joe Orton says, "To fix this properly, I suppose piped loggers should not > > >get > > >SIGTERMedduring a graceful restart, they should read till EOF then > > exit(0): then > > >when the last child attached to the piped logger for a particular > > >generation > > >quits, the pipe is closed and the piped logger terminates gracefully too, > > >without losing log messages." > > > > In that scenario, the patch I've attached here would not normally be > > needed, but would be a backup if that doesn't work. It is not clear > > to me that we can change that aspect of piped loggers anyway, since it > > can break third-party code. > > I have a patch in-progress somewhere which does attempt the alternative > approach, but I stalled on this exactly because of the concern for > breaking third-party loggers. (I think I checked cronolog and found it > would just spin forever calling read() if stdin was closed) > > I think it would be OK to make the behaviour change for 2.2 at least, > since the current behaviour of losing log entries during graceful > restart if using piped loggers is definitely Surprising Behaviour (tm).
That's probably MUCH more practical than waiting until the current generation is finished to send SIGTERM, but the latter could be put to use in other circumstances. (But no round tuits in sight for that.) > > b) wouldn't it be nice to have a hook similar to child-init which > > would be run in non-MPM child processes (e.g., mod_cgid's child or > > mod_fastcgi's child or children created in various other > > non-Apache-distributed modules) > > I suppose there is a better argument to start setting FD_CLOEXEC > everywhere... no exec() in sight though (or registering cleanup-on-exec would have worked)
