Still not a complete solution to the puzzle, but some more findings below.
On 25.07.2009 20:55, William A. Rowe, Jr. wrote:
> Rainer Jung wrote:
>> On 25.07.2009 18:36, William A. Rowe, Jr. wrote:
>>> Rainer Jung wrote:
>>>> On 25.07.2009 16:05, Rainer Jung wrote:
>>>>> 5) Starting a service only works using the ApacheMonitor or the Windows
>>>>> Service Control. Using the commandline httpd.exe I can not start the
>>>>> service. The event log shows:
>>>>>
>>>>> [Sat Jul 25 15:11:03 2009] [notice] Disabled use of AcceptEx() WinSock2
>>>>> API
>>>>>
>>>>> (OS 10048)Normalerweise darf jede Socketadresse (Protokoll,
>>>>> Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden. :
>>>>> make_sock: could not bind to address 127.0.0.1:8000
>>>>>
>>>>> no listening sockets available, shutting down
>>>>>
>>>>> Unable to open logs
>>>>>
>>>>> So there's a warning about using IP address or port twice. I did check,
>>>>> that no other process uses the port and starting via ApacheMonitor with
>>>>> the same config is no problem. So I guess (wildly), that we have a bug
>>>>> when starting from the commandline, resulting in the parent and the
>>>>> child both trying to do the bind.
>>>> Additional logging shows: the commandline process sets up the listeners
>>>> for itself, and also the service when it tries to start.
>>> Interesting because I see no similar fault (using 2.2.13-dev and will
>>> retest with 2.2.12). How are you invoking httpd.exe? What additional
>>> modules had you loaded? (Perhaps one also creates listening sockets?)
>>> If you simplify your config to apache httpd shipped modules, is all
>>> well again?
>> httpd -k uninstall
>> httpd -k install
>> httpd -k start
>
> You -do- understand that the service control manager can be very poor
> at completing a service removal until the next reboot? There are lots
> of interesting delays to uninstalling. I presume you -k stop'ed first.
> It has bitten me more than once.
Yes, and since I'm a Unix guy, I do a lot of checking process table and
netstat even on Windows.
> Maybe your "shut down now" comment is a really brilliant idea :)
>
>> httpd -k install myserv
>> httpd -k start myserv
>
> I hope you mean -n in there ... Cut and paste would give me more
> confidence in helping you debug instead of chasing ghosts :)
Sorry, yes "-n myserv".
>> Default config except for the disabled acceptex and non-standard port
>> 8000. No 3rd-party modules.
>
> I disabled acceptex, as you had (standard port though) on a guess that
> it might be the difference. I never use the mode and deleted it already
> from trunk.
I tried without Win32DisableAcceptEx. No difference. I need
Win32DisableAcceptEx, because otherwise restarts do not work. There is
an open GZ about that, but that's a different story.
Now the new thing: as I reported before, I was testing rotatelogs, but
then when you asked about peculiarities I forgot to mention rotatelogs.
And yes: as soon as I throw out rotatelogs, the problem disappears. When
I add rotatelogs I can reproduce the problem.
It doesn't matter whether I use "|" or the new "||". It doesn't matter
whether I use rotatelogs in ErrorLog or CustomLog or both.
rotatelogs itself works fine (when starting as a commandline process, or
as a service via ApacheMonitor).
I added a sleep in winnt_post_config() in the part
if (!strcasecmp(signal_arg, "start")) {
...
}
directly after the closing of the listener sockets and before calling
mpm_service_start(ptemp, inst_argc, inst_argv).
If I include rotatelogs in the config, then the httpd commandline
process doing the start has one rotatelogs child at that point in time,
and ProcessExplorer tells me, that the httpd commandline process still
has the socket on LISTEN. netstat -ano shows the same result.
I checked the return code of apr_socket_close() which is done directly
before, but it is APR_SUCCESS. So slowly I'm running out of ideas, why
the socket doesn't get closed before starting the service.
As soon as I through rotatelogs out of the config, the socket gets
closed and thus the service can start.
I wonder, whether the socket gets inherited by rotatelogs and thus
closing it in the commandline httpd can not effectively close it. But
this is just a wild guess, and it doesn't go well with ProcessExplorer
and netstat both showing the LISTEN owned by httpd, not by rotatelogs.
Can you please try once with rotatelogs?
Thanks!
Regards,
Rainer
