Greg Ames <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > +/* XXX unfortunate issue: > > + * with apachectl restart (not graceful), previous generation dies > > + * abruptly with no chance to clean up scoreboard entries; when new > > + * generation is started, processes can loop forever in start_threads() > > + * waiting for scoreboard entries for threads of prior generation to > > + * get cleaned up... > > yikes! > > Did that break when the scoreboard moved to the process pool? Looks like > ap_cleanup_scoreboard won't run any more.
no, it is unrelated... it was occurring before yesterday's commits, probably for a long time (I ran into the annoying series of SIGTERM+SIGTERM+SIGTERM+SIGKILL messages when testing some of my changes and went back and then verified that it happened on cvs head) but some knowledge of how the scoreboard used to work shows that the comment shouldn't be right Here is the actual sequence of events that I did: start (wait) graceful (wait) restart (wait) stop This wasn't a once or twice thing. Always after this sequence I saw the annoying messages when I did apachectl stop. Sometimes (40%?) I saw a few such messages also when I did apachectl restart. This was on multiple OSs as well. I only noticed the problem (new children with no place to go) when I did the "restart." But a restart clobbers (well, *did*) the scoreboard so how can a newly-started child be waiting forever for the scoreboard slots in this scenario? While the problem really exists (children that never find any slots), I don't honestly know the cause and intend to remove most of the comment so that it doesn't lead anybody down the wrong path. Also, I think I'll put in a debug message every 180 iterations (3 minutes) if the child process hasn't made any progress taking over more slots. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
