2009/8/4 Petr Hracek <phrac...@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 <phrac...@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 <minf...@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 >>> -- >> > >
