Bug 1310469 - dnsmasq starts before udev renames network interfaces [NEEDINFO]
dnsmasq starts before udev renames network interfaces
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dnsmasq (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity low
: rc
: ---
Assigned To: Pavel Šimerda (pavlix)
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-21 17:59 EST by marcelofr
Modified: 2016-11-27 16:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-27 16:53:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
psimerda: needinfo? (roccas)


Attachments (Terms of Use)

  None (edit)
Description marcelofr 2016-02-21 17:59:52 EST
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 11:42:26 EDT
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 02:45:16 EDT
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 09:14:31 EDT
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 09:17:34 EDT
You might want to provide details on your configuration and logs.
Comment 10 Tomáš Hozza 2016-11-27 16:53:39 EST
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.

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