You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/07/31 06:17:15 UTC
Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
rpluem@apache.org 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.
> static void destroy_and_exit_process(process_rec *process,
> int process_exit_value)
...
> + apr_sleep(TASK_SWITCH_SLEEP);
Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
Posted by Mladen Turk <mt...@apache.org>.
Plüm, Rüdiger, VF-Group wrote:
>
>
> 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.
Looks to me like an excellent usage for apr_pool_pre_cleanup_register :)
With pre_cleanup register on process->pool, the order of pools
creation would be irrelevant in that case.
Regards
--
^(TM)
Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: "Plüm, Rüdiger, VF-Group"
> Gesendet: Donnerstag, 31. Juli 2008 08:15
> An: dev@httpd.apache.org
> 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: dev@httpd.apache.org
> > Cc: cvs@httpd.apache.org
> > Betreff: Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
> >
> > rpluem@apache.org 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
Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Donnerstag, 31. Juli 2008 06:17
> An: dev@httpd.apache.org
> Cc: cvs@httpd.apache.org
> Betreff: Re: svn commit: r681204 - /httpd/httpd/trunk/server/main.c
>
> rpluem@apache.org 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.
Regards
Rüdiger