Bug 447442 - NetworkManager and dhcpd do not play nice together
NetworkManager and dhcpd do not play nice together
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-19 18:01 EDT by Tom Horsley
Modified: 2010-07-16 13:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 20:40:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2008-05-19 18:01:42 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:
Comment 1 Tom Horsley 2008-05-19 18:08:45 EDT
Just rebooted with network instead of NetworkManager in charge, and verified
that dhcpd starts up at boot time with no problems.
Comment 2 Dan Williams 2008-05-19 18:41:39 EDT
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.
Comment 3 Tom Horsley 2008-05-19 20:21:59 EDT
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 :-).
Comment 4 Dan Williams 2008-05-19 20:39:33 EDT
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?
Comment 5 Dan Williams 2008-05-19 20:49:19 EDT
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.
Comment 6 Bill Nottingham 2008-05-20 10:50:08 EDT
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.
Comment 7 Tom Horsley 2008-05-20 17:33:51 EDT
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.
Comment 8 Bill Nottingham 2008-05-21 15:04:34 EDT
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).
Comment 9 Tom Horsley 2008-05-21 18:23:22 EDT
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"?
Comment 10 Bill Nottingham 2008-05-22 11:51:45 EDT
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.
Comment 11 Edward J. Huff 2010-07-16 13:41:23 EDT
For a workaround (still required for Fedora 13), see

https://bugzilla.redhat.com/show_bug.cgi?id=565921#c8

Note You need to log in before you can comment on or make changes to this bug.