Bug 565921 - dhcpd does not start at boot on a system with NetworkManager
Summary: dhcpd does not start at boot on a system with NetworkManager
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-02-16 17:46 UTC by Jay Fenlason
Modified: 2019-02-04 13:41 UTC (History)
3 users (show)

Fixed In Version: dhcp-4.2.0-6.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-30 13:20:45 UTC
Type: ---

Attachments (Terms of Use)
boot.log (2.50 KB, text/plain)
2010-02-26 20:08 UTC, Jay Fenlason
no flags Details
ifcfg-eth0 (252 bytes, text/plain)
2010-02-26 20:10 UTC, Jay Fenlason
no flags Details
ifcfg-Auto_eth2 (203 bytes, text/plain)
2010-02-26 20:11 UTC, Jay Fenlason
no flags Details
full output of chkconfig (3.13 KB, text/plain)
2010-02-26 20:13 UTC, Jay Fenlason
no flags Details
NetworkManager dispatcher script (first try) (528 bytes, text/plain)
2010-07-01 18:02 UTC, Jiri Popelka
no flags Details
NM dispatcher script (596 bytes, text/plain)
2010-07-30 13:19 UTC, Jiri Popelka
no flags Details

Description Jay Fenlason 2010-02-16 17:46:18 UTC
Description of problem:
I have a server with two interfaces: eth0 and eth1.  Both are configured by NetworkManager.  Eth0 is a dhcp client of the DSL modem.  Eth1 has a fixed ip address.  I run dhcpd on eth1 to serve addresses to the other machines on that network.  When the system boots, dhcpd fails to start because NetworkManager has not finished configuring eth1 when init tries to start dhcpd.  I eventually worked around the problem by adding (sleep 5 ; /usr/sbin/dhcpd eth1&) to /etc/rc.local

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.configure NetworkManager to 
Actual results:
dhcpd starts at boot and immediately exits because it did not find its network interface.

Expected results:
dhcpd starts at boot and serves addresses as configured.

Additional info:
I couldn't decide whether this is a dhcpd bug, a NetworkManager bug, or an init bug.  I just want my computer to boot correctly.

Comment 1 Jiri Popelka 2010-02-18 11:25:21 UTC
For me it works, but I don't have DSL modem to test with.
Can you:
- attach your /var/log/boot.log
- show me your /etc/sysconfig/network-scripts/ifcfg-eth1
- what does:  chkconfig --list | grep -E 'etwork|dhcpd'

Comment 2 Jay Fenlason 2010-02-26 20:08:56 UTC
Created attachment 396653 [details]

As you can see, dhcpd does not start, so I start it by hand in /etc/rc.local

Comment 3 Jay Fenlason 2010-02-26 20:10:31 UTC
Created attachment 396654 [details]

Configuration file for eth0, the interface that dhcpd runs on.

Comment 4 Jay Fenlason 2010-02-26 20:11:58 UTC
Created attachment 396655 [details]

I have no idea why NetworkManager calls this one Auto_eth2.

Comment 5 Jay Fenlason 2010-02-26 20:13:31 UTC
Created attachment 396656 [details]
full output of chkconfig

Here's the full output of chkconfig.

Comment 6 Jiri Popelka 2010-03-02 15:07:08 UTC
(In reply to comment #0)
> Description of problem:
> I have a server with two interfaces: eth0 and eth1.  Both are configured by
> NetworkManager.  Eth0 is a dhcp client of the DSL modem.  Eth1 has a fixed ip
> address.  I run dhcpd on eth1 to serve addresses to the other machines on that
> network.

I'm little bit confused. It's not consistent what you are saying.
In description you say that dhcpd runs on eth1.
In comment #3 you say it runs on eth0.
In description you say that eth0 is a dhcp client, but in ifcfg-eth0 I see that it has fixed address and BOOTPROTO=none.
And there's actually no eth1, but Auto_eth2 (I also don't know why is there the 'Auto').

Can you show me what 'ip addr show' does ?

Comment 7 Jay Fenlason 2010-03-02 16:33:17 UTC
I wrote the initial bug report from memory without access to the machine in question, and I'm afraid I got some of the details wrong.  dhcpd runs on the interface, which goes to the local network.  192.168.1.* goes to the DSL router.  I probably switched it to a fixed address in the hopes that NetworkMangler would start up faster and allow dhcpd to start.  Dhcpd fails to start regardless of whether that interface is BOOTPROTO=dhcp or BOOTPROTO=none.

I can't get the ip addr show output until tomorrow--I only have intermittent access to the machine in question.

Comment 8 Andrew Davis 2010-06-29 22:06:13 UTC
From what I can tell, this is the same issue that has been reported in #447442 and #486372.  This problem is also still present in Fedora 13.

The problem from what I can tell is that the DHCP package does not include a script to be placed into /etc/NetworkManager/dispatcher.d/ to reload dhcpd on an interface "up" event.  If you look in this directory, you will see other similar services do this.

It seems a few network services still don't do this to play nicely with Networkmanager, but has been improving (for example, named now works).  I have a workaround script that I place in /etc/NetworkManager/dispatcher.d/ to reload such services on a network "up" event.  Here is an extract;

if [ "$2" = "up" ]; then
        /sbin/service dhcpd restart || :

So in summary, I believe the bug is due to the relevant dispatcher.d script not being present in the DHCP package.

Comment 9 Jiri Popelka 2010-07-01 18:02:42 UTC
Created attachment 428514 [details]
NetworkManager dispatcher script (first try)

Thanks Andrew,

I found also bug #447036.

From Dan Williams’ blog:
"The typical solution to this on Fedora is to set NETWORKWAIT=yes in /etc/sysconfig/network, which causes NM’s initscript to block for 30 seconds or until a network connection is brought up (whichever is first).  Or better, drop a dispatcher script into /etc/NetworkManager/dispatcher.d"
( http://blogs.gnome.org/dcbw/2010/04/07/networkmanager-on-server-type-machines-or-why-our-initscripts-suck/ )

If you (like me) wonder why NETWORKWAIT is not documented
in /usr/share/doc/initscripts-<version>/sysconfig.txt
see bug #595386.

But adding a NM dispatcher script looks like better solution.
Here's my first try. It's not tested yet.
I'll be away couple days now so I'll test it later.

Comment 10 Andrew Davis 2010-07-01 22:59:22 UTC
I think you will find this script does not quite capture the issue, as DHCPD may have already been started before interfaces are brought up by Networkmanager (this is indeed the case for me).  Under this condition, dhcpd will not be able to bind to interfaces and therefore not work on such interfaces following the pending network events.  I understand therefore that dhcpd daemon would need "service dhcpd restart" rather than "service dhcpd start" as your script contains.

This change would mean any "up" event on the network would reload dhcpd, where it could therefore bind to the newly available interfaces.  This would include the interfaces finally being brought up by networkmanager, and also any configuration changes to the network interfaces by the user.

Comment 11 Jiri Popelka 2010-07-30 13:19:41 UTC
Created attachment 435548 [details]
NM dispatcher script

Thanks Andrew,

attached NM dispatcher script is shipped with dhcp-4.2.0-2.fc14

Workaround solution on Fedora-12 and Fedora-13 is to set NETWORKWAIT=yes in

Comment 12 Fedora Update System 2010-08-20 10:39:16 UTC
dhcp-4.2.0-2.fc14 has been submitted as an update for Fedora 14.

Comment 13 Fedora Update System 2010-10-05 13:19:18 UTC
dhcp-4.2.0-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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