1

I have a CentOS server with isc dhcpd and apache 2 webserver running. A couple of minutes ago I have tried to restart apache:

/etc/init.d/httpd restart

Restart has failed with:

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

Apache was complaining that the 80 port has been already taken. I've executed

netstat -ntap

to see who is listening on 80 port. And it was dhcpd. Since before restart apache and dhcpd were running simultaneously I guess what has happened was that just after apache was off, dhcp has noticed that 80 port is free and started listening it. Does anybody know in what cases dhcpd would do it and why? I've tried to reproduce that a couple of times but with no luck.

user9517
  • 114,104
  • 20
  • 206
  • 289
facha
  • 1,298
  • 2
  • 16
  • 26
  • It has happened again. As many people have doubted if it really was dhcp listening the 80 port, I've uploaded the image of netstat output http://postimage.org/image/wzfb49fo/ – facha Jul 08 '11 at 07:35

4 Answers4

4

DHCP protocol uses 67 and 68 port numbers. dhcpd cannot out of the blue start listening on
port 80 'because it is free'. And one more thing, using t option in netstat you lists only TCP protocol. How come you see dhcp server which is using UDP protocol ? You have probably misread netstat output.

Casual Coder
  • 1,216
  • 1
  • 11
  • 12
  • I've used t option in netstat to see who was listening on apache's tcp port 80. And no, I didn't misread it. It really was dhcpd. The way I made apache run again was stopping dhcpd, starting apache and then starting dhcpd again. – facha Oct 14 '10 at 12:52
1

I've tried to reproduce that a couple of times but with no luck.

That's because after apache exits the socket may still remain open lingering in the background until associated buffers are drained of data. The time between killing and starting the apache process may be lower than the time needed to drain the buffers on the listening socket and a new process will not be able to bind to the listening address getting a new socket until the old one is really closed. About the dhcpd part, you surely misread the netstat output if we're talking about a normal centos installation and normal people using it.

user237419
  • 1,663
  • 8
  • 8
1

While I agree completely with you that this is impossible, it does it all the time for me.

[root@host ~]# service httpd stop
Stopping httpd:                                            [  OK  ]
[root@host ~]# service httpd start
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]

and then:

[root@host ~]# netstat -anp | grep :80
tcp        0      0 :::80                       :::*                        LISTEN      21276/dhcpd         

Yep, tcp port 80 is being camped on by dhcpd. so anyway now we reset to original state:

[root@host ~]# service dhcpd stop
Shutting down dhcpd:                                       [  OK  ]
[root@host ~]# service httpd start
Starting httpd:                                            [  OK  ]
[root@host ~]# service dhcpd start
Starting dhcpd:                                            [  OK  ]
[root@host ~]# netstat -anp | grep :80
tcp        0      0 :::80                       :::*                        LISTEN      27577/httpd         

Attempts immediately after this work properly, but I can reproduce this every time as long as the server has been running for a while.

  • next time run sudo netstat -tpln and it'll show you the process that is holding the port. I got one upvote that says it's not dhcp. – kashani Mar 22 '11 at 05:23
1

I believe that I found the cause of this issue. We utilize a PHP application which maintains the DHCP hosts config file and a change in this file will cause PHP to execute code to restart the DHCP service. When this code is executed, it spawns a process to restart the DHCP process. This spawned process inherits the Apache ports which are "queued". Once the Apache process is stopped, the DHCP process now owns port 80. You can fix this issue by either disabling ipv6 entirely on the server or re-configuring Apache to only utilize ipv4.

John
  • 11
  • 1