Bug 46139 - Apache Restart option is not working
Summary: Apache Restart option is not working
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.2.10
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2008-11-02 22:33 UTC by Paul Iu
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Iu 2008-11-02 22:33:34 UTC
Fresh Apache 2.2.10 installed on Windows XP machine with default config files, httpd.exe service can be started and working without problem, default page "It works!" can display. However, restarted Apache by selecting "Restart" from Windows Start Menu (-k restart) or click Restart in Apache Service Monitor, Apache Server no longer replying request to the client bowser. To make the Apache work again, "Stop" & "Start" procedures is needed.

I tried on a Windows 2003 Server with Dual Xeon CPU also has same problem.

This error log is right after click Restart, seems ok but client bowser receive no respond from Apache and waiting forever.....

[Mon Nov 03 14:26:39 2008] [notice] Apache/2.2.10 (Win32) configured -- resuming normal operations
[Mon Nov 03 14:26:39 2008] [notice] Server built: Oct 10 2008 12:39:04
[Mon Nov 03 14:26:39 2008] [notice] Parent: Created child process 7108
httpd.exe: Could not reliably determine the server's fully qualified domain name, using 192.168.1.102 for ServerName
httpd.exe: Could not reliably determine the server's fully qualified domain name, using 192.168.1.102 for ServerName
[Mon Nov 03 14:26:39 2008] [notice] Child 7108: Child process is running
[Mon Nov 03 14:26:40 2008] [notice] Child 7108: Acquired the start mutex.
[Mon Nov 03 14:26:40 2008] [notice] Child 7108: Starting 64 worker threads.
[Mon Nov 03 14:26:40 2008] [notice] Child 7108: Starting thread to listen on port 80.
Comment 1 Rainer Jung 2009-04-19 11:35:37 UTC
I can reproduce the problem.

I tried with 2.2.8 and 2.2.11 (ASF build) and also with my own 2.2.11 build. ProcessExplorer shows, that directly after the start, the parent owns the listen, but the child owns the TCP connection for any new request. After restart, the parent owns request connections. The requests are not answered.
Comment 2 Rainer Jung 2009-04-19 12:00:06 UTC
I tried additionally with

- 2.2.3 nod SSL ASF build
- 2.0.63 SSL ASF build
- 2.0.53 no SSL ASF build

All of them show the above described problem.

Version 1.3.41 does restart correctly.
Comment 3 Rainer Jung 2009-04-19 13:31:55 UTC
Things get more confusing now:

I have two systems running Windows XP Professional Version 2002 SP 3. The problem does occur on one of them, but not on the other one.

The systems are not identical, like one is German (the broken one), and one English. The broken one most likely has more up-to-date MS patches and uses DHCP, the working one is more static and runs as a VMware guest.
Comment 4 William A. Rowe Jr. 2009-04-19 16:18:40 UTC
The information we need to reproduce this is the network stack of the problem
systems.  E.g. settings, Network Connections, particular connection -> Properties

We are looking for any 'suspect' components, particularly non-MS elements.

We are also looking for the use of EnableSendfile and DisableWin32AcceptEx.

Finally, it will be very interesting to look at the WinNT MPM in 2.3 trunk.
I'll likely post a backport of this for the 2.2.11 release to compare notes.
Comment 5 Rainer Jung 2009-04-27 01:39:40 UTC
Win32DisableAcceptEx fixes the problem on my test system. Disabling Sendfile and MMap don't fix it.

I also played a bit with various interfaces and disabling drivers. I used a normal LAN interface and disabled all drivers except for TCP/IP and also disabled the Windows firewall. Even when configuring httpd Listen fixed on the system address, the problem was reproducible. Then I disabled all interfaces and used Listen to listen on localhost only. Still I got the problem. Disabling AcceptEx fixed it in all those cases.

When disabling all interfaces and using localhost, the windows routing table says they are usoing the "MS TCP loopback interface". I didn't find a good way to retrieve configuration or network stack details for this interface.

There is a lot of additional network related software installed on the system like VPN software, a VMware player, wireshark etc. So it could well be, that parts of that influences the accept behaviour, even when I try to disable as much of it as I'm able to.
Comment 6 Rainer Jung 2009-04-27 04:12:41 UTC
Actually AcceptEx() returns with 997 (IO_PENDING) after the initial start as well as after restart. Then the WaitForSingleObject() loop after AcceptEx() loops with the 1 second timeout until the new connection is accepted and then passed along to the thread doing the get_connection after start. After restart the WaitForSingleObject() loop does only return with the timeout all the time although from the point of view of the client and also of netstat, the connection is accepted.

As noted before, netstat and ProcessExplorer indicate, that the accepted connection is related to the parent process, not to the child.
Comment 7 William A. Rowe Jr. 2009-08-06 20:00:37 UTC
It would be good to compare this broken tcp/ip stack with the behavior of httpd
trunk, which is significantly refactored already.
Comment 8 William A. Rowe Jr. 2018-11-07 21:09:42 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.