Rainer Jung wrote:
>> 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.
That isn't what I was saying. In many cases win32 does not remove the
various service registry (or memory-persistent) details of a previously
existing service until after reboot. I wasn't really addressing any
running services. Another example of Win32 bogosity is the necessity
to reboot for a service to pick up global envvar changes.
> 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.
Very interesting, I will try to create a repro case.
> It doesn't matter whether I use "|" or the new "||". It doesn't matter
> whether I use rotatelogs in ErrorLog or CustomLog or both.
Note that || and |$ have not yet been backported.
> 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 for the tremendously detailed description :) Will work from this.