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). How reproducible: 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. Actual results: see above Expected results: dhcpd should start only after NetworkManager sets up the interface. Additional info:
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. Try adding: NETWORKWAIT=true 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 startup, yes. 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 initialized first.
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 https://bugzilla.redhat.com/show_bug.cgi?id=565921#c8