At 03:13 PM 3/20/2002, you wrote: >Is anyone else seeing this? That makes perfect sense, although it 'failed to fail' for me when coding yesterday. In fact, early, it occured to me that this could occur - but I was so d*mned tired it then slipped my mind.
Consider; we don't close the listeners now [with the pool cleanup] because we moved them to the process pool. They are alert and listening. Now we try to grab the sockets in the server restart open_logs hook, and we don't set the socket as sharable [on Win32, specificially] until we successfully grab them for our exclusive use. [That was the old bug that we could share IIS or anyone elses' sockets due to Win32's lame security model.] Well that patch has come back to bite us [on win32.] I suspect that in the Win32 case, we don't comment out the first SO_REUSEADDR block, but test for (old_listeners) - and set the listeners reuse up front when this is a restart case. If we find (!old_listeners) - then postpone the SO_REUSEADDR flag until after our successful first socket-grab attempt. BTW - there is a not-so-subtle race condition here with a traditional server restart [the Service Control Applet's stop-start button.] The main server stops, but the child is still in it's death throughs. The new parent process can't grab the socket until the child -really- utters it's last whimpers and expires. So an ungraceful-restart, e.g. net stop apache2 && net start apache2 can fail today, and I don't have a trivial solution. Bill
