https://bz.apache.org/bugzilla/show_bug.cgi?id=65313
--- Comment #4 from Yann Ylavic <[email protected]> --- Created attachment 37997 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37997&action=edit Enf of reload notice before stopping children Can you please apply this patch on top of r1892587 and show the main error_log with MPM event? I can't reproduce what you observe in my testing, which consists in continuously running ab (apache bench) and operating periodic graceful restarts (every 20 seconds). I also add an artificial sleep delay in httpd to simulate a loading that takes 10 seconds, like this: Index: server/mpm/event/event.c =================================================================== --- server/mpm/event/event.c (revision 1892671) +++ server/mpm/event/event.c (working copy) @@ -3406,6 +3406,11 @@ static int event_run(apr_pool_t * _pconf, apr_pool apr_pool_create(&retained->gen_pool, ap_pglobal); } else { + ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf, + "Building new generation %i for 10 more seconds", + retained->mpm->my_generation + 1); + apr_sleep(apr_time_from_sec(10)); + if (retained->mpm->was_graceful) { /* wake up the children...time to die. But we'll have more soon */ for (i = 0; i < num_buckets; i++) { -- My observation is that during the reload (+ delay) the server keeps responding as usual. So I'm wondering if it isn't one of your modules that does time consuming work in each child initialization phase (child_init hooks), in which case there is little httpd can do to make it process connections faster. Let's see what the logs say about the delays between: 1. AH00493: SIGUSR1 received. Doing graceful restart 2. AH99999: Gracefully stopping old generation <n-1> 3. AH00489: Apache/... -- resuming normal operations (generation <n>) 4. AH00000: Child <pid> initialization done (generation <n>) (+ other AH00000s for all the children created for generation <n>) If the "hold for 20+s" is not between 1. and 2. then the children are too long to set up (and r1892587 won't help). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
