Bug 1310469

Summary: dnsmasq starts before udev renames network interfaces
Product: Red Hat Enterprise Linux 7 Reporter: marcelofr <roccas>
Component: dnsmasqAssignee: Pavel Šimerda (pavlix) <psimerda>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.2CC: psimerda, roccas, thozza
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-27 21:53:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description marcelofr 2016-02-21 22:59:52 UTC
Description of problem:
I installed and upgraded centos 7.2.1511. I renamed ethernet interface via udev and configured dnsmasq as dns and dhcp server. During boot, dnsmasq is started before network is fully up, so, no dhcp interface is found.

Version-Release number of selected component (if applicable):
dnsmasq-2.66-14.el7_1.x86_64

How reproducible:
5 baer metal installation, all failed.

Steps to Reproduce:
1. Install centos 7, with dnsmasq
2. Created /etc/udev/rules.d/80-net-names-slot.rules:

ACTION!="add", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"
IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_PATH}=="enp5s0", NAME="lan0"
NAME=="", ENV{ID_NET_NAME_PATH}=="enp1s0", NAME="inet0"
NAME=="", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="gob0"
NAME=="", ENV{ID_NET_NAME_PATH}=="enp4s0", NAME="adsl0"
NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
LABEL="net_name_slot_end"

3. Configured dnsmasq as dhcp server on lan0 ethernet:
dhcp-range=192.168.5.100,192.168.5.200,12h

Actual results:
Ethernet udev ends after systemd starts dnsmasq

Additional info:
This patch solves error:

--- /usr/lib/systemd/system/dnsmasq.service     2015-08-05 21:23:53.000000000 -0300
+++ /etc/systemd/system/multi-user.target.wants/dnsmasq.service 2016-02-19 13:40:32.740190243 -0300
@@ -1,6 +1,6 @@
 [Unit]
 Description=DNS caching server.
-After=network.target
+After=network-online.target
 
 [Service]
 ExecStart=/usr/sbin/dnsmasq -k

Comment 2 Pavel Šimerda (pavlix) 2016-03-24 15:42:26 UTC
It is pretty clear what's meant by this change request. I generally don't like the idea of running DNS and DHCP servers too late during the boot process. We'll have to consider this carefully in context of dnsmasq and check whether it would be better to make this change, offer a change in configuration or find another solution.

Comment 3 Lukáš Nykrýn 2016-06-21 06:45:16 UTC
Udev rename the devices as soon as their appear, so it does not make sense to add dependency on network-online.target, since that is generally more about waiting for dhcp,... In ideal case dnsmasq should be able to cope with the fact that not all devices could be present in the moment when it is started.

As a workaround you maybe could add some drop-in for dnsmasq unit-file that will add requires and after for the important devices.

Comment 6 Pavel Šimerda (pavlix) 2016-07-12 13:14:31 UTC
So dnsmasq is expected to work without waiting for udev or network management tools. Therefore this change should not be necessary. This could be a configuration issue or, if it doesn't work in default configuration, a bug in dnsmasq packages.

Comment 7 Pavel Šimerda (pavlix) 2016-07-12 13:17:34 UTC
You might want to provide details on your configuration and logs.

Comment 10 Tomáš Hozza 2016-11-27 21:53:39 UTC
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

As this bug has been in NEEDINFO for an extended period of time we are going
to close this bug due to inactivity. If you would like to pursue this
matter feel free to reopen this bug and attach the needed information.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical
defects.

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux.

Comment 11 Red Hat Bugzilla 2023-09-14 03:18:18 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days