RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1310469 - dnsmasq starts before udev renames network interfaces
Summary: dnsmasq starts before udev renames network interfaces
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dnsmasq
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-21 22:59 UTC by marcelofr
Modified: 2023-09-14 03:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-27 21:53:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


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