Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm at my wits end on this one; I have tried for hours to get this to work, but I'm stumped. Hope one of you can help. :-)

I'm trying to get dhcp3-server to work on Ubuntu. It's installed, and setup correctly to run in rc2,3,4,5.d runlevels. On boot, its init.d script does get run, and in syslog, I get the following:

Oct 18 20:40:37 jez-ubuntu dhcpd: Internet Systems Consortium DHCP Server V3.1.1
Oct 18 20:40:37 jez-ubuntu dhcpd: Copyright 2004-2008 Internet Systems Consortium.
Oct 18 20:40:37 jez-ubuntu dhcpd: All rights reserved.
Oct 18 20:40:37 jez-ubuntu dhcpd: For info, please visit
Oct 18 20:40:37 jez-ubuntu dhcpd: Wrote 2 leases to leases file.
Oct 18 20:40:37 jez-ubuntu dhcpd:
Oct 18 20:40:37 jez-ubuntu dhcpd: No subnet declaration for eth1 (
Oct 18 20:40:37 jez-ubuntu dhcpd: ** Ignoring requests on eth1.  If this is not what
Oct 18 20:40:37 jez-ubuntu dhcpd:    you want, please write a subnet declaration
Oct 18 20:40:37 jez-ubuntu dhcpd:    in your dhcpd.conf file for the network segment
Oct 18 20:40:37 jez-ubuntu dhcpd:    to which interface eth1 is attached. **
Oct 18 20:40:37 jez-ubuntu dhcpd:
Oct 18 20:40:37 jez-ubuntu dhcpd:
Oct 18 20:40:37 jez-ubuntu dhcpd: Not configured to listen on any interfaces!
Oct 18 20:40:39 jez-ubuntu NetworkManager: <info>  (eth0): device state change: 1 -> 2
Oct 18 20:40:39 jez-ubuntu NetworkManager: <info>  (eth0): bringing up device.
Oct 18 20:40:39 jez-ubuntu NetworkManager: <info>  (eth0): preparing device.

As you can see, dhcpd appears to be running before NetworkManager, which is what sets up my eth0 (internet) and eth1 (home network) interfaces. You'd think this had something to do with the rcX.d symlink names, and that dhcpd was named to start before NetworkManager. Not so. My dhcp3-server symlinks are named 'S99dhcp3-server' and the Network Manager symlinks are named 'S50NetworkManager', so it should be starting before the dhcp server. In addition, if I actually run (as root) from the commandline '/etc/init.d/dhcp3-server'... the server runs OK! It only fails at boot!

Why does it say it's not configured to listen on any interfaces? Is the network manager not bringing interfaces eth0 and eth1 up until after all my boot scripts have run? If this is the case, what use is it? Surely other scripts would need these interfaces to be available at boot time? Here's my /etc/dhcp3/dhcpd.conf file:

subnet netmask {
        option routers;
        option subnet-mask;
        option domain-name-servers;
        option ip-forwarding off;
        range dynamic-bootp;
        default-lease-time 21600;
        max-lease-time 43200;

and my /etc/default/dhcp3-server file:

# Defaults for dhcp initscript
# sourced by /etc/init.d/dhcp
# installed at /etc/default/dhcp3-server by the maintainer scripts

# This is a POSIX shell fragment

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#       Separate multiple interfaces with spaces, e.g. "eth0 eth1".

As far as I can tell, these are all correct. Any ideas?

share|improve this question

you can modify your /etc/network/interfaces like this:

iface eth1 inet static
  up service dhcp3-server restart

so dhcp3-server will be (re)started after network interface (eth1) has been really up.

share|improve this answer
up vote 2 down vote accepted

OK, I think i've fixed this issue. And it IS a bug in Linux's network manager.

See, the network manager runs as part of the boot process (that'd be the 'S50NetworkManager' symlink) and brings up your ethernet interfaces. However, it does it asynchronously. This means that the network manager returns immediately, implying to the scripts after it, "OK - network's been set up." Actually, it hasn't, and the network manager is sitting there in the background getting on with setting up the network. Meanwhile, the boot scripts after it are running with the assumption that the network interfaces will be available, which is a race condition, depending on whether the network manager has gotten round to setting them up yet.

This is a horrible situation and a bug I'm amazed hasn't been fixed. One way of getting round it is to ditch the network manager and instead set up your interfaces by editing /etc/network/interfaces. Rather than do that work, though, I tried the ugly hack suggested in this bug report:

I added a 5 second delay ('sleep 5') into the beginning of the start function in dhcp3-server's init.d script, this giving the network manager ample time to get the network interfaces set up (although of course there is still no guarantee) - and it worked. Now, dhcpd succeeds on startup.

As detailed in bugs #486372 and #447442 on, this is either a bug with network manager (it should block until its wired network interfaces are available), or with dhcpd (it should be updated to wait for network interfaces to become available, rather than just crashing out). It is definitely a bug of sorts, though.

share|improve this answer
Is this the Desktop version of Ubuntu? – Kyle Smith Oct 18 '09 at 22:30
Oh yuck .. that five second sleep is really racy. Good on you for finding a fix though. – Tim Post Oct 19 '09 at 0:21
Kyle: yes it is. tinkertim: yes it is. – Jez Oct 20 '09 at 8:39

I was having this issue for a different reason, I think.

I was trying to use DHCP to configure the interface the server would listen on. AKA my LAN was connected to the eth0 port of the server, and I was trying to get DHCP to configure eth0. Doesn't work, apparently; DHCP listening interfaces have to be configured statically (/etc/network/interfaces).

Correct me if I'm wrong. I didn't think one should have to statically configure a DHCP listening device.

share|improve this answer

I had a similar problem, but in my case the network interface (eth0) was never up - it had failed to initialise properly. This was happening intermittently however, approx 20% of the time. Putting in a delay, or restarting the dhcp server as suggested in other answers did not solve my problem.

In my case the solution was to restart both the network services and then the dhcp server via something like the following script (fragments only, not runnable start to end)...

# Check if the networking is running ...
# look for "" within this command's output

# If the networking is not running, then restart the network interfaces via this command:
sudo service networking restart

# Check if the DHCP service is running ...
# look for "dhcpd" within this command's output
ps -C dhcpd

# If the DHCP service is not running, then restart the DHCP service via this command:
sudo service isc-dhcp-server restart
share|improve this answer

I just ran into this issue on Ubuntu, and I fixed it a little differently. I am using the isc-dhcp-server service but it was attempting to start before the required interface was up, crashing, and then exhausting the respawn limit. I made a small edit to the start on line in the upstart config file in /etc/init:

start on runlevel [2345] and net-device-up IFACE=eth0

This way the service will not attempt to start until the required interface is up.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.