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: always Steps to Reproduce: 1.configure NetworkManager to 2. 3. 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.
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'
Created attachment 396653 [details] boot.log As you can see, dhcpd does not start, so I start it by hand in /etc/rc.local
Created attachment 396654 [details] ifcfg-eth0 Configuration file for eth0, the interface that dhcpd runs on.
Created attachment 396655 [details] ifcfg-Auto_eth2 I have no idea why NetworkManager calls this one Auto_eth2.
Created attachment 396656 [details] full output of chkconfig Here's the full output of chkconfig.
(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 192.168.2.254 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 ?
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 192.168.2.254 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.
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; #!/bin/sh if [ "$2" = "up" ]; then /sbin/service dhcpd restart || : fi So in summary, I believe the bug is due to the relevant dispatcher.d script not being present in the DHCP package.
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.
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.
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 /etc/sysconfig/network.
dhcp-4.2.0-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/dhcp-4.2.0-2.fc14
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.