|I have an Apache 2 server running on an openSUSE VM. I configured it to use OpenSSL over 443 and it has been serving pages well up until recently.|
I restarted the VM because of VMWare networking problems recently ( hopefully will link to another page about that later ) and now I can't get Apache to start up because of an error:
sudo /etc/init.d/apachectl start
(98)Address already in use: make_sock: could not bind to address [::]:443
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
Unable to open logs
It looks like something else is using port 443, so Apache cannot create a socket, so it fails. And surely enough, I ran netsat -nap with the following results.
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nam
tcp 0 0 :::443 :::* LISTEN -
tcp 125 0 y.y.y.y:443 x.x.x.x:1637 CLOSE_WAIT -
tcp 64 0 y.y.y.y:443 x.x.x.x:1638 CLOSE_WAIT -
tcp 64 0 y.y.y.y:443 x.x.x.x:1639 CLOSE_WAIT -
Here, y.y.y.y is my VM's address and x.x.x.x is my Host machine's ip address.
So here's what I guess happened. I assumed Apache would have started by itself on startup ( still have to get that to work ). So I tried to connect to the server on the VM from a browser on my Host machine before the server was started. Strangely, even though no service was running listening on port 443, I connected anyway. Meanwhile, the error I got above happened after I killed the connection from my host machine side. I didn't kill the browser and netstat still shows the connection is in this "CLOSE_WAIT" state. An explanation at http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html seems to say that "CLOSE_WAIT" is the fault of the application which can't quite handle a remote host sending a final FIN when closing a TCP connection. But in this case, what's the application? Unfortunately, netstat isn't telling me what process is behind this 443 socket, so I'm clueless here.
Of course closing the browser on my Host machine didn't solve the problem. Neither restarting the /etc/init.d/xinetd nor /etc/init.d/network services helped close that CLOSE_WAIT, either.
After waiting some time ( not on purpose ), those CLOSE_WAIT's disappeared, but Apache still won't start up for the same reason indicated.
What was wrong
This is embarrassing, but an instance of Apache was actually running, but whenever I checked if it was using ps -A | grep httpd, I didn't see the default 5 httpd processes running, but only one and I internally assumed this was not httpd, but the process checking ps -A | grep httpd itself.