Red Hat Bugzilla – Bug 447442
NetworkManager and dhcpd do not play nice together
Last modified: 2010-07-16 13:41:23 EDT
Description of problem:
If I boot the system with NetworkManager setting up my static IP,
then the dhcpd daemon won't start correctly - it says:
May 19 17:49:27 zooty dhcpd: Not configured to listen on any interfaces!
No doubt because the network isn't up at the time dhcpd starts. (In fact,
I see NetworkManager startup messages in the log immediately *after*
the dhcpd failure message).
Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.9.3.svn3675.fc9.x86_64 (this is a new build
I'm trying out that isn't yet in the repos).
Probably every time, but I haven't tried it a lot yet.
Steps to Reproduce:
1. enable both dhcpd and NetworkManager and see dhcpd fail at boot time
2. manually start dhcpd later, and see it start OK.
dhcpd should start only after NetworkManager sets up the interface.
Just rebooted with network instead of NetworkManager in charge, and verified
that dhcpd starts up at boot time with no problems.
NM starts the network interfaces in the background, and dhcpd isn't smart enough
to wait around for the interfaces it cares about.
to /etc/sysconfig/network to make the NM initscript wait 10 seconds before
continuing. You can also set LINKDELAY or NETWORKDELAY (both in seconds) in the
same file to delay startup further.
Nonsense. This can't possibly be NOTABUG. The stock dhcpd from the fedora
repos doesn't work with the NetworkManager. There is a bug somewhere :-).
Maybe it is a dhcpd bug and not a NetworkManager bug, but you guys are
the ones trying to foist NetworkManager off as an improvement, and all the other
packages that use the network should still function correctly for
NetworkManager to actually be considered an improvement. In the long
run you'll regret trying to pretend all these problems aren't bugs
when NetworkManager shows up in RHEL and paying customers wonder why their
comp centers no longer function :-).
No, it's not really a bug. Quite a few people don't need networking to block
startup, and some people do. We've made a decision that for the moment, the
people that need networking to block startup need to modify that file and
explicitly have networking block startup. Some people needed to do this even
before NM was the default.
Any comments Bill?
Also, NM won't be made the default on upgrades where it wasn't turned on before.
If you didn't have NM chkconfig-ed on, it should not be on now. If it got
turned on magically in an upgrade then that's a bug.
You'll need to customize the dhcpd.conf file for your network anyway, and at the
same time you'll need to make networking block until network is up.
The only things I can think of are hacks where packages that require networking
to block before startup tell chkconfig about it, and when you chkconfig a
service on, maybe it drops a file in /etc/block-network.d which causes the
'network' and 'NetworkManager' startup scripts to automatically block. But
that's a huge hack.
The bottom line is that the services that require network to be up before they
start need to be smarter about it.
NETWORKWAIT is the workaround for services that require synchronous network
That being said, why can't DHCP bind to the device? It certainly already
*exists*, even if the address is not configured yet.
DHCP isn't interested in a device, it is interested in finding interfaces
on particular subnets (the ones mentioned in the DHCP config), so without
the interfaces being configured first dhcpd can't start.
The real question is, if there is indeed a mechanism for services to use
to wait on the network, why isn't the dhcp rpm setup to go ahead and
use that mechanism? It can't possibly work without the network being
Well, the solution is for dhcp to wait *itself* for the interface to become
available. Having it attempt to frob the system configuration to make NM startup
synchronous isn't really practical (or sane).
But couldn't that be accomplished with the packaging of the dhcp rpm? I thought
with the new "upstart" stuff, everything was event driven and init scripts could
run as soon as possible, but no sooner. Shouldn't the dhcp package be able to
tell the upstart system "Hey, don't run my init script till the network is up"?
We are not using upstart natively for most things yet. Note that the LSB
definition of 'network' is 'can bind to a network socket' - as that's more or
less always available, that's not particularly useful for dhcpd, as NM in its
current state fulfills that.
For a workaround (still required for Fedora 13), see