On Dec 12, 2014, at 6:32 AM, Steven Tardy <sjt5atra at gmail.com> wrote: > On Thu, Dec 11, 2014 at 12:35 PM, Warren Young <wyml at etr-usa.com> wrote: > >> We noticed this problem when web browsers would refuse to connect to the >> server. *Then* we discovered the netstat oddity, and *then* we found that >> changing the Listen line in httpd.conf fixed it. > > was the fix the config change or restarting of the service? I'm going to need to see this happen on the next server build to test for such details. The only reason I restarted it is because that’s the only way to be certain the configuration changes take effect. Theoretically, “service reload” is supposed to be equivalent to “service restart”, but too many times I’ve run into services that don’t reload *everything*. I got out of the habit of using “reload” years ago. As a result of your question, I realized that systemd might open up yet another new possibility for confusion in CentOS 7. What if the service is down from the start? In CentOS 6 and earlier, “restart” on a downed service typically gets you an error, since the init script usually implements this in terms of “stop-then-start”, and the “stop” step fails. CentOS 7 is a new ballgame, though, because systemd can just figure out what you meant, and silently start it. I tested this, and my guess was correct: this is exactly systemd does. Grrr. I’ve already ruled that out as the problem in this particular case with the netstat test. I wouldn’t have seen the IPv6 port 80 listener if it was down from the start. Nevertheless, it’s a good thing to keep in mind going forward. > did netstat show client connections to port 80 in other > states(FIN_WAIT/etc)? Since the problem servers never completed one single connection until I modified the Listen line, I don’t see how any WAIT states could occur, much less still be in the process of timing out. > high load apache websites can often run out of connections These are freshly-built boxes on a quiet private LAN, being tested with single connections by a single user. They are not running out of resources.