You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Petr Hracek <ph...@gmail.com> on 2009/08/01 11:30:27 UTC
Re: Catching graceful restart in apache2 module
As you mentioned:
>The request pool is no good, because that's cleaned up at the end of the
>request. The connection pool is also no good, because that gets cleaned
>up after the connection dies. You're probably after the pool you're
>given during the post_config hook, which gets destroyed on server
>shutdown (graceful or otherwise).
It means that in post_config can be handled the server has been shutdown
with either restart or graceful command for specific pool?
If I understand right then if pool is opened then it would not end because
of apache2 has been restarted with option graceful, right?
Is it behaviour the same when the server is going down in shel with the
gracefull command?
Is there any example how to implement in the post_config handler?
Best regards
Petr
2009/7/31 Graham Leggett <mi...@sharp.fm>
> Petr Hracek wrote:
>
> > Thank for the answer.
> >
> > Could you please explain in details how to do "register save-sessions as
> > a pool cleanup".
>
> You call a function that looks like this to register your cleanup:
>
> apr_pool_cleanup_register(pool, (void *) foo, foo_cleanup,
> foo_cleanup);
>
> The function foo_cleanup() is a function you write yourself, that does
> whatever you want the cleanup to do:
>
> static apr_status_t foo_cleanup(void *dummy) {
> foo_t *foo = (foo_t *)dummy;
>
> ... do stuff using foo ...
>
> return APR_SUCCESS;
> }
>
> The variable foo is a void pointer that points to whatever you want your
> cleanup to operate on, such as a pointer to your session config, or
> whatever you want.
>
> The cleanup gets run when the pool is deleted, ie when someone calls
> apr_pool_destroy() on that pool.
>
> What you need to do at this point is decide which pool you attach your
> cleanup to.
>
> The request pool is no good, because that's cleaned up at the end of the
> request. The connection pool is also no good, because that gets cleaned
> up after the connection dies. You're probably after the pool you're
> given during the post_config hook, which gets destroyed on server
> shutdown (graceful or otherwise).
>
> Regards,
> Graham
> --
>
Re: Catching graceful restart in apache2 module
Posted by Petr Hracek <ph...@gmail.com>.
That's true. I have some changes and this function returns always.
In my post_config handler function I have following code:
if(!ap_graceful_stop_signalled())
{
ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0,
base_server, "!!! Graceful has not been called therefor kill all sessions
!!!");
udsc_usmw_killsessions(base_server);
}
Unfortunatelly it does not work.
Best regards
Petr
2009/8/4 Graham Dumpleton <gr...@gmail.com>
> 2009/8/4 Graham Dumpleton <gr...@gmail.com>:
> > 2009/8/4 Ruediger Pluem <rp...@apache.org>:
> >>
> >>
> >> On 08/04/2009 09:02 AM, Graham Dumpleton wrote:
> >>> 2009/8/4 Petr Hracek <ph...@gmail.com>:
> >>>> I have found in following link: (
> http://wiki.apache.org/httpd/ModuleLife)
> >>>>
> >>>> Race conditions during graceful restart
> >>>>
> >>>> During a graceful restart, old children are still serving old requests
> while
> >>>> new children are serving new requests. If the same lock must be used
> by old
> >>>> and new children, then the lock name must be the same and cannot be
> >>>> generated with tmpnam() or similar functions in the post_config hook.
> >>>>
> >>>> Which lock is means there. I have already found the in the post_config
> I
> >>>> have cleanuped procedure, but in the post_config is already mentioned
> >>>> function for killing all session.
> >>>> Is there any way how to detect if the restart of apache has been done
> as
> >>>> gracefull or as hard restart?
> >>>
> >>> /**
> >>> * predicate indicating if a graceful stop has been requested ...
> >>> * used by the connection loop
> >>> * @return 1 if a graceful stop has been requested, 0 otherwise
> >>> * @deffunc int ap_graceful_stop_signalled(*void)
> >>> */
> >>> AP_DECLARE(int) ap_graceful_stop_signalled(void);
> >>
> >> Is this also true for graceful restarts?
> >> The comment only talks about graceful stops.
> >
> > Hmmm, I presumed that the server child process wouldn't know the
> > difference and that 'stop' here meant 'stop' of an individual process
> > and not the server as a whole. I guess a bit of digging through code
> > is necessary to verify what actually happens.
> >
> > I could also possibly be wrong in assuming they were wanting to know
> > about detecting in a server child process and not Apache parent
> > process. I haven't exactly been following the discussion in detail.
>
> In prefork that function returns false all the time anyway. :-(
>
> Graham
>
Re: Catching graceful restart in apache2 module
Posted by Graham Dumpleton <gr...@gmail.com>.
2009/8/4 Graham Dumpleton <gr...@gmail.com>:
> 2009/8/4 Ruediger Pluem <rp...@apache.org>:
>>
>>
>> On 08/04/2009 09:02 AM, Graham Dumpleton wrote:
>>> 2009/8/4 Petr Hracek <ph...@gmail.com>:
>>>> I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
>>>>
>>>> Race conditions during graceful restart
>>>>
>>>> During a graceful restart, old children are still serving old requests while
>>>> new children are serving new requests. If the same lock must be used by old
>>>> and new children, then the lock name must be the same and cannot be
>>>> generated with tmpnam() or similar functions in the post_config hook.
>>>>
>>>> Which lock is means there. I have already found the in the post_config I
>>>> have cleanuped procedure, but in the post_config is already mentioned
>>>> function for killing all session.
>>>> Is there any way how to detect if the restart of apache has been done as
>>>> gracefull or as hard restart?
>>>
>>> /**
>>> * predicate indicating if a graceful stop has been requested ...
>>> * used by the connection loop
>>> * @return 1 if a graceful stop has been requested, 0 otherwise
>>> * @deffunc int ap_graceful_stop_signalled(*void)
>>> */
>>> AP_DECLARE(int) ap_graceful_stop_signalled(void);
>>
>> Is this also true for graceful restarts?
>> The comment only talks about graceful stops.
>
> Hmmm, I presumed that the server child process wouldn't know the
> difference and that 'stop' here meant 'stop' of an individual process
> and not the server as a whole. I guess a bit of digging through code
> is necessary to verify what actually happens.
>
> I could also possibly be wrong in assuming they were wanting to know
> about detecting in a server child process and not Apache parent
> process. I haven't exactly been following the discussion in detail.
In prefork that function returns false all the time anyway. :-(
Graham
Re: Catching graceful restart in apache2 module
Posted by Graham Dumpleton <gr...@gmail.com>.
2009/8/4 Ruediger Pluem <rp...@apache.org>:
>
>
> On 08/04/2009 09:02 AM, Graham Dumpleton wrote:
>> 2009/8/4 Petr Hracek <ph...@gmail.com>:
>>> I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
>>>
>>> Race conditions during graceful restart
>>>
>>> During a graceful restart, old children are still serving old requests while
>>> new children are serving new requests. If the same lock must be used by old
>>> and new children, then the lock name must be the same and cannot be
>>> generated with tmpnam() or similar functions in the post_config hook.
>>>
>>> Which lock is means there. I have already found the in the post_config I
>>> have cleanuped procedure, but in the post_config is already mentioned
>>> function for killing all session.
>>> Is there any way how to detect if the restart of apache has been done as
>>> gracefull or as hard restart?
>>
>> /**
>> * predicate indicating if a graceful stop has been requested ...
>> * used by the connection loop
>> * @return 1 if a graceful stop has been requested, 0 otherwise
>> * @deffunc int ap_graceful_stop_signalled(*void)
>> */
>> AP_DECLARE(int) ap_graceful_stop_signalled(void);
>
> Is this also true for graceful restarts?
> The comment only talks about graceful stops.
Hmmm, I presumed that the server child process wouldn't know the
difference and that 'stop' here meant 'stop' of an individual process
and not the server as a whole. I guess a bit of digging through code
is necessary to verify what actually happens.
I could also possibly be wrong in assuming they were wanting to know
about detecting in a server child process and not Apache parent
process. I haven't exactly been following the discussion in detail.
Graham
Re: Catching graceful restart in apache2 module
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/04/2009 09:02 AM, Graham Dumpleton wrote:
> 2009/8/4 Petr Hracek <ph...@gmail.com>:
>> I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
>>
>> Race conditions during graceful restart
>>
>> During a graceful restart, old children are still serving old requests while
>> new children are serving new requests. If the same lock must be used by old
>> and new children, then the lock name must be the same and cannot be
>> generated with tmpnam() or similar functions in the post_config hook.
>>
>> Which lock is means there. I have already found the in the post_config I
>> have cleanuped procedure, but in the post_config is already mentioned
>> function for killing all session.
>> Is there any way how to detect if the restart of apache has been done as
>> gracefull or as hard restart?
>
> /**
> * predicate indicating if a graceful stop has been requested ...
> * used by the connection loop
> * @return 1 if a graceful stop has been requested, 0 otherwise
> * @deffunc int ap_graceful_stop_signalled(*void)
> */
> AP_DECLARE(int) ap_graceful_stop_signalled(void);
Is this also true for graceful restarts?
The comment only talks about graceful stops.
Regards
Rüdiger
Re: Catching graceful restart in apache2 module
Posted by Graham Dumpleton <gr...@gmail.com>.
2009/8/4 Petr Hracek <ph...@gmail.com>:
> I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
>
> Race conditions during graceful restart
>
> During a graceful restart, old children are still serving old requests while
> new children are serving new requests. If the same lock must be used by old
> and new children, then the lock name must be the same and cannot be
> generated with tmpnam() or similar functions in the post_config hook.
>
> Which lock is means there. I have already found the in the post_config I
> have cleanuped procedure, but in the post_config is already mentioned
> function for killing all session.
> Is there any way how to detect if the restart of apache has been done as
> gracefull or as hard restart?
/**
* predicate indicating if a graceful stop has been requested ...
* used by the connection loop
* @return 1 if a graceful stop has been requested, 0 otherwise
* @deffunc int ap_graceful_stop_signalled(*void)
*/
AP_DECLARE(int) ap_graceful_stop_signalled(void);
If you haven't already seen it, see:
http://www.fmc-modeling.org/category/projects/apache/amp/4_3Multitasking_server.html
and everything else in that document.
Graham
> best regards
> Petr Hracek
>
> 2009/8/1 Petr Hracek <ph...@gmail.com>
>>
>> As you mentioned:
>> >The request pool is no good, because that's cleaned up at the end of the
>> >request. The connection pool is also no good, because that gets cleaned
>> >up after the connection dies. You're probably after the pool you're
>> >given during the post_config hook, which gets destroyed on server
>> >shutdown (graceful or otherwise).
>>
>> It means that in post_config can be handled the server has been shutdown
>> with either restart or graceful command for specific pool?
>> If I understand right then if pool is opened then it would not end because
>> of apache2 has been restarted with option graceful, right?
>> Is it behaviour the same when the server is going down in shel with the
>> gracefull command?
>> Is there any example how to implement in the post_config handler?
>>
>> Best regards
>> Petr
>>
>> 2009/7/31 Graham Leggett <mi...@sharp.fm>
>>>
>>> Petr Hracek wrote:
>>>
>>> > Thank for the answer.
>>> >
>>> > Could you please explain in details how to do "register save-sessions
>>> > as
>>> > a pool cleanup".
>>>
>>> You call a function that looks like this to register your cleanup:
>>>
>>> apr_pool_cleanup_register(pool, (void *) foo, foo_cleanup,
>>> foo_cleanup);
>>>
>>> The function foo_cleanup() is a function you write yourself, that does
>>> whatever you want the cleanup to do:
>>>
>>> static apr_status_t foo_cleanup(void *dummy) {
>>> foo_t *foo = (foo_t *)dummy;
>>>
>>> ... do stuff using foo ...
>>>
>>> return APR_SUCCESS;
>>> }
>>>
>>> The variable foo is a void pointer that points to whatever you want your
>>> cleanup to operate on, such as a pointer to your session config, or
>>> whatever you want.
>>>
>>> The cleanup gets run when the pool is deleted, ie when someone calls
>>> apr_pool_destroy() on that pool.
>>>
>>> What you need to do at this point is decide which pool you attach your
>>> cleanup to.
>>>
>>> The request pool is no good, because that's cleaned up at the end of the
>>> request. The connection pool is also no good, because that gets cleaned
>>> up after the connection dies. You're probably after the pool you're
>>> given during the post_config hook, which gets destroyed on server
>>> shutdown (graceful or otherwise).
>>>
>>> Regards,
>>> Graham
>>> --
>>
>
>
Re: Catching graceful restart in apache2 module
Posted by Petr Hracek <ph...@gmail.com>.
I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
Race conditions during graceful restart
During a graceful restart, old children are still serving old requests while
new children are serving new requests. If the same lock must be used by old
and new children, then the lock name must be the same and cannot be
generated with tmpnam() or similar functions in the post_config hook.
Which lock is means there. I have already found the in the post_config I
have cleanuped procedure, but in the post_config is already mentioned
function for killing all session.
Is there any way how to detect if the restart of apache has been done as
gracefull or as hard restart?
best regards
Petr Hracek
2009/8/1 Petr Hracek <ph...@gmail.com>
> As you mentioned:
> >The request pool is no good, because that's cleaned up at the end of the
> >request. The connection pool is also no good, because that gets cleaned
> >up after the connection dies. You're probably after the pool you're
> >given during the post_config hook, which gets destroyed on server
> >shutdown (graceful or otherwise).
>
> It means that in post_config can be handled the server has been shutdown
> with either restart or graceful command for specific pool?
> If I understand right then if pool is opened then it would not end because
> of apache2 has been restarted with option graceful, right?
> Is it behaviour the same when the server is going down in shel with the
> gracefull command?
> Is there any example how to implement in the post_config handler?
>
> Best regards
> Petr
>
> 2009/7/31 Graham Leggett <mi...@sharp.fm>
>
> Petr Hracek wrote:
>>
>> > Thank for the answer.
>> >
>> > Could you please explain in details how to do "register save-sessions as
>> > a pool cleanup".
>>
>> You call a function that looks like this to register your cleanup:
>>
>> apr_pool_cleanup_register(pool, (void *) foo, foo_cleanup,
>> foo_cleanup);
>>
>> The function foo_cleanup() is a function you write yourself, that does
>> whatever you want the cleanup to do:
>>
>> static apr_status_t foo_cleanup(void *dummy) {
>> foo_t *foo = (foo_t *)dummy;
>>
>> ... do stuff using foo ...
>>
>> return APR_SUCCESS;
>> }
>>
>> The variable foo is a void pointer that points to whatever you want your
>> cleanup to operate on, such as a pointer to your session config, or
>> whatever you want.
>>
>> The cleanup gets run when the pool is deleted, ie when someone calls
>> apr_pool_destroy() on that pool.
>>
>> What you need to do at this point is decide which pool you attach your
>> cleanup to.
>>
>> The request pool is no good, because that's cleaned up at the end of the
>> request. The connection pool is also no good, because that gets cleaned
>> up after the connection dies. You're probably after the pool you're
>> given during the post_config hook, which gets destroyed on server
>> shutdown (graceful or otherwise).
>>
>> Regards,
>> Graham
>> --
>>
>
>