Bug 771009 (dhcp_network-online) - Dhcp's NetworkManager dispatcher script causes dhcpd to fail to start on a bridge interface
Summary: Dhcp's NetworkManager dispatcher script causes dhcpd to fail to start on a br...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: dhcp_network-online
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 19
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: network-online.target
TreeView+ depends on / blocked
 
Reported: 2011-12-31 03:16 UTC by Michal Růžička
Modified: 2017-11-06 20:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-20 09:57:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Růžička 2011-12-31 03:16:17 UTC
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.

Comment 1 Michal Růžička 2011-12-31 03:31:48 UTC
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

Comment 2 Jiri Popelka 2013-01-10 16:20:43 UTC
This seems to have no solution until NM supports bridges.

Comment 3 Fedora End Of Life 2013-04-03 19:26:06 UTC
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

Comment 4 Sklav 2014-09-21 05:49:26 UTC
Btw this issue is present on RHEL7/centos 7 and reproducible under identical conditions.

Comment 5 Sklav 2014-10-19 03:45:39 UTC
for RHEL7 i have created bug report 1145832

Comment 6 Jiri Popelka 2014-10-20 09:57:18 UTC
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.

Comment 7 Pavel Šimerda (pavlix) 2014-11-14 13:50:04 UTC
Node: There have also been related changes in systemd affecting the ordering and dependencies of the *generated* network.service.

Comment 8 Pavel Šimerda (pavlix) 2014-11-14 13:52:26 UTC
Adding to the tracker to indicate that dhcpd has been fixed.


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