Apache Fails to Restart; Address in use; cannot bind to port 80

4 posts / 0 new
Last post
#1 Tue, 10/02/2012 - 21:19

Apache Fails to Restart; Address in use; cannot bind to port 80

Recently I have made changes to the directives for some sites. When I hit "apply changes" nothing happened. so I tried to stop and restart apache and Apache fails to come up.


98)Address already in use: make_sock: could not bind to address [::]:80 no listening sockets available, shutting down.

Be a "newbie" I paniced and call ServePath (where our machine is hosted) support to reboot the server.

The second time it happened I decided to so the same thing, but told them to do a "graceful" reboot... when they did, this time Apache still failed with the same error. So, now I decide to calm down, and past the error into google and find on Slashdot a solution: run netstat -tulpn | grep :80 --> get the process number (it was a tcp connection still in use by apache) --> then kill that PID, now I can go back to VirtualMin/WebMin and start apache and it comes up OK..

My question is: what am I doing to make this happen? Possibly not waiting long enough for the "Apply" go finish? is "Apply" running a complete httpd graceful stop and start? Or does apply simply write the new settings to httpd.conf and then we should stop and start Apache? I don't think so, in fact that seems to be what is causing this to happen... I'm pushing too many buttons too fast or something....

Any clues? I need to see if I can not keep making this happen and I am pretty sure it is "user dumb action" that is the problem.

Tue, 10/02/2012 - 23:59


I don't think you're doing anything wrong, though that is a little unusual.

We occasionally see cases where one of the Apache processes gets "stuck", and doesn't want to stop.

You could probably just run "killall httpd", or maybe "killall -9 httpd", to get rid of it. Or possibly wait just a little longer, though if you're seeing that, it won't always stop (I'm assuming you're running CentOS -- that's the only distro I've seen that occur on).

So why does that happen?

Well, that's a fine question, and I lack a good answer :-)

It could be several things... it may be caused by an Apache module. So if you're using any Apache modules you don't need, you could always try disabling some of them.

It also wouldn't hurt to remove any PHP modules you aren't using.

Those would be two good places to start.


Wed, 10/03/2012 - 15:17

Aloha, Eric:

OK, I won't whip myself any longer :-)... Yes this is CentOS6.2 I will add:

"You could probably just run "killall httpd", or maybe "killall -9 httpd", to get rid of it. "

to my tool box. At least I know now I don't have to call support and restart the machine, but can do this immediately myself.


Tue, 10/16/2012 - 19:32

Hi !

I'm facing the same issue on my newly (re)installed Debian Server.

I'm renting a VPS, they provide Debian 5. I have updated it to Debian 6, then installed Virtualmin/Webmin and the reinstalled my VirtualServers ... When I was using Debian 5 and Virtualmin/Webmin I didn't have that problem.

Now, almost each time I "Stop Apache" (not a simple Apply), one of the process stay alive and prevent Apache from restarting.

What I noticed in the process list:

  • I have a first main "root" apache process

5 S root 15855 1 0 80 0 - 61606 poll_s 19:45 ? 00:00:00 /usr/sbin/apache2 -k start

  • I have a first sub apache process owned by www-data

5 S www-data 15857 15855 0 80 0 - 50663 poll_s 19:45 ? 00:00:00 /usr/sbin/apache2 -k start

  • And all other Apache processes owned by "root"

1 S root 15883 15855 0 80 0 - 64397 semtim 19:45 ? 00:00:00 /usr/sbin/apache2 -k start 1 S root 15960 15855 0 80 0 - 64397 epoll_ 19:48 ? 00:00:00 /usr/sbin/apache2 -k start 1 S root 15975 15855 0 80 0 - 64397 semtim 19:48 ? 00:00:00 /usr/sbin/apache2 -k start 1 S root 15977 15855 0 80 0 - 64397 semtim 19:48 ? 00:00:00 /usr/sbin/apache2 -k start

It's always the process owned by www-data, that stay alive when I stop Apache from Webmin panel (that become an orphan process).

I'm also facing an other problem with this new install, that might be related to the previous one : [emerg] [client xxx.xxx.xxx.xxx] (22)Invalid argument: mod_fcgid: can't lock process table in pid 23890, referer: ... It seems to be a fcgi bug, but I didn't have that problem before either.

Topic locked