Bug 47586 - httpd -k start doesn't start service when rotatelogs is used
Summary: httpd -k start doesn't start service when rotatelogs is used
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mpm_winnt (show other bugs)
Version: 2.2.11
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate, PatchAvailable
Depends on:
Reported: 2009-07-27 06:16 UTC by Rainer Jung
Modified: 2018-11-07 21:09 UTC (History)
0 users

Patch to move "-k start" for mpm_winnt form post config to pre config (1.03 KB, patch)
2009-07-27 06:16 UTC, Rainer Jung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Jung 2009-07-27 06:16:49 UTC
Created attachment 24041 [details]
Patch to move "-k start" for mpm_winnt form post config to pre config

Observed on Windows XP SP 3.

Configuration: Default plus rotatelogs.

Service can be started and works using the service manager or ApacheMonitor. But when started via commandline "httpd -k start" the service doesn't start. The event log shows:

  (OS 10048)Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse
  oder Anschluss) nur jeweils einmal verwendet werden.  : make_sock: could not
  bind to address

  no listening sockets available, shutting down

  Unable to open logs

This doesn't happen on another test system with Windows 2K3 SP 2 using the same binaries and configuration.

Problem analysis shows:

"httpd -k start" starts the service in post config. Before it opens, it starts the listening sockets and also starts rotatelogs itself. Then, shortly before starting the service it closes the sockets it has opened.

If one looks at netstat between closing the sockets and the starting of the service, it still shows the socket listening (so the service can't successfully start). This only happens if rotatelogs is configured, so it seems the rotatelogs child process somehow inherits the socket and inhibits the close call from the parent to actualy succeed. The call to apr_socket_close() does return with APR_SUCCESS though. SysInternals ProcessExplorer and "netstat -ano" both show the httpd commandline process as having the socket in LISTEN even after it has called apr_socket_close().

There is a lot of additional network related software on the test system (VMWare, VPN clients etc.), but I think the attached patch is nevertheless valid in general. It moves the "-k start" handling from post config to pre config, so that no listeners are opened and no loggers spawned in the commandline process.

See also 


and the followup messages.
Comment 1 Rainer Jung 2009-07-27 06:39:26 UTC
I tested on another Windows XP SP3 system and could not reproduce there. That system is more bare bones. So the issue depends on the exact patch plus additional software installation status.

The root cause of the problem could be related to BZ 46139. But we can solve this service start issue here with the attached patch, whereas a solution for 46139 seems to be more difficult (without using DisableWin32AcceptEx).

To avoid confusion: DisableWin32AcceptEx does not help for this issue here.
Comment 2 Rainer Jung 2009-07-27 06:41:52 UTC
The problem is also not directly related to rotatelogs itself, only to the use of a piped logger.

If I replace rotatelogs by some dummy program, the same problem occurs.

It is also independent of using the piped logger directly or via cmd.exe ("||" or "|").
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:59 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.