Graceful restarts can be really slow in 2.0 with prefork... the parent is making a dummy connection on the pod MaxClients times, rather than a connection for as many children as it has had; is that really necessary?
We've had problems in this area in the past (not necessarily in prefork) due to not being able to aim the dummy connections at specific old generation server instances. Then we start the new generation before the old generation is completely down, and the old generation processes hang around indefinately. If we can insure that won't happen, then go for it.
This is an area where I think signals are valuable because they target specific processes. Yes, we've been avoiding signals in 2.0. But IMO that was mostly a workaround for linuxthread problems. That's not an issue for prefork, and it shouldn't be an issue for the new Linux pthread library either.
Other approaches could work too, like:
1. send ap_max_daemons_limit dummy connections. 2. scan the scoreboard. Are all the children gone? Great, on to step 5. 3. send one dummy connection 4. sleep a little, then back to step 2. 5. start up the new generation
With the current design, you shouldn't see more than one connection time out. A minute or more sounds like breakage, or possibly funky sysctl settings for TCP.
Greg
