Description of problem: I have a bridge interface configured and I want to run DHCP server on that interface (and just that interface). But the dhcpd server fails to start during boot with the following error message: No subnet declaration for br0 (no IPv4 addresses). It turns out that dhcpd is started before the configuration of the bridge interface is finished and hence the error message. The core problem is in the NetworkManager dispatcher script contained in the dhcp pacakge: /etc/NetworkManager/dispatcher.d/12-dhcpd The sequence of events leading up to the problem is probably as follows: 1. NetworkManager is started 2. NetworkManager activates an interface unrelated to the bridge 3. the /etc/NetworkManager/dispatcher.d/12-dhcpd dispatcher script is executed 4. the dispatcher scripts decides to restart dhcpd in response to the interface activation event 5. dhcpd is started before network initialization is finished - particularly before the legacy network.service (/etc/rc.d/init.d/network) had a chance to initialize the bridge interface the dhcpd is configured to listen on 6. dhcpd fails with the error message mentioned above Version-Release number of selected component (if applicable): dhcp-4.2.1-11.P1.fc15.i686 How reproducible: always Steps to Reproduce: 1. have a system with at least one interface managed by NetworkManager 2. create a bridge configuration by editing ifcfg-* files as appropriate; configure a static IP for the bridge interface, mark it for activation at boot time 3. create a dhcpd configuration including a subnet declaration for the subnet connected through the bridge interface configured in the previous step 4. make the bridge interface the only interface dhcpd is supposed to listen on by putting the bridge interface name to DHCPDARGS in /etc/sysconfig/dhcpd (e.g. something like: DHCPDARGS="br0") 5. systemctl enable dhcpd.service network.service NetworkManager.service 6. reboot the system Actual results: the dhcpd fails to start during boot; an error message similar to the following one can be found in the logs: No subnet declaration for br0 (no IPv4 addresses). ** Ignoring requests on br0. ... Expected results: the dhcpd starts normally Additional info: The /etc/NetworkManager/dispatcher.d/12-dhcpd dispatcher scripts should only restart the dhcpd if an interface that dhcpd is supposed to listen on is activated. Unfortunately in the scenario described above it fails to do so and restarts dhcpd in response to an activation of an interface that dhcpd is not supposed to listen on. The problem being in the way how the dispatcher script builds the list of interfaces the dhcpd is supposed to listen on: It first queries the interfaces currently present on the system by executing: ls /sys/class/net and then it deems those arguments from DHCPDARGS in /etc/sysconfig/dhcpd which match any of the interfaces present on the system to be the interfaces that dhcpd is supposed to listen on. This approach fails in the scenario described above as the bridge interface is not yet created when the `ls /sys/class/net` is executed and thus it is not recognized as an interface the dhcpd is supposed to listen on. And since there is no other interface configured for the dhcpd to listen on the dispatcher script wrongly concludes that the dhcpd is supposed to listen on all interfaces and thus restarts it in response to any interface activation event. This then causes the dhcpd to be started before the interface it is actually supposed to listen on is configured and eventually results in the failure mentioned above.
I was able to work around the problem by forcing the network.service to finish before the NetworkManager.service is started by adding: After=network.service to /lib/systemd/system/NetworkManager.service
This seems to have no solution until NM supports bridges.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Btw this issue is present on RHEL7/centos 7 and reproducible under identical conditions.
for RHEL7 i have created bug report 1145832
Sklav reported (bug #1145832, comment #4) that http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?h=f20&id=fa8876306577f2b1f595a94180a3207f4c2af8bb fixes the problem (on RHEL7). I'm closing this ticket as the above mentioned change has already been pushed to F20/F21. Feel free to open if you still see the issue.
Node: There have also been related changes in systemd affecting the ordering and dependencies of the *generated* network.service.
Adding to the tracker to indicate that dhcpd has been fixed.