> -----Ursprüngliche Nachricht----- > Von: "Plüm, Rüdiger, VF-Group" > Gesendet: Donnerstag, 31. Juli 2008 08:15 > An: [email protected] > Betreff: Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c > > > > > -----Ursprüngliche Nachricht----- > > Von: William A. Rowe, Jr. > > Gesendet: Donnerstag, 31. Juli 2008 06:17 > > An: [email protected] > > Cc: [EMAIL PROTECTED] > > Betreff: Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c > > > > [EMAIL PROTECTED] wrote: > > > Author: rpluem > > > Date: Wed Jul 30 14:08:33 2008 > > > New Revision: 681204 > > > > > > URL: http://svn.apache.org/viewvc?rev=681204&view=rev > > > Log: > > > * Give possible piped loggers a chance to process their > > input before they get > > > killed by us. > > > > This is only useful if you did so AFTER logs were closed and > > flushed - is > > this the case? Knowing how d&e_process used to work, I don't > > think it's > > true. > > Good point. I will have a look, but it works for unbuffered logs > and solved my case where a configuration error detected in the > post_config hook did not show up in the respective rotated log.
Just to be sure, that we talk about the same thing. You are talking of the buffered logging that happens when BufferedLogs is set to on, correct? I think in this case the buffered log data will never make it to the rotated logfiles and here is why I think so: plog and pconf pools are both childs of the process->pool which is destroyed by destroy_and_exit_process. As the plog pool is created *after* the pconf pool it will be destroyed *before* pconf pool. The flushing of the buffers (flush_all_logs) is registered with a child pool of pconf, whereas the killing of the log rotater processes via apr_pool_note_subprocess is registered with the plog pool or a child of it. So the log rotater processes are already gone when the buffers get flushed. Boom. Regards Rüdiger
