Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
We have NFS shares configured.
Last week we configured dnsmasq for some usecase of DNS resolution.
Yesterday we rebooted the serve automatically during patch maintenance.
NFS could not be mounted due to "Temporary failure in name resolution".
After debugging the case we found that the netfs init script has a start priority of 25
while the dnsmasq has a priority of 49.
This is not working correctly in my opinion!
I would expect dnsmasq to be started far more earlier, probably near to network around 10.
Dnsmasq should have a lower startup number in order to be ready right after network. This is important since with installation/configuration of dnsmasq the /etc/resolv.conf ist configured to 127.0.0.1. So other services which depend on DNS can work correctly.
Our business service was completly down because of NFS dependency!
Version-Release number of selected component (if applicable):
dnsmasq-2.48-18.el6_9.x86_64
How reproducible:
Steps to Reproduce:
1. Install dnsmasq and NFS server
2. Reboot or change the to runlevel 3
3.
Actual results:
Dnsmasq starts up late due to lower priority order
Expected results:
Dnsmasq should start up higher priority order.
Additional info:
dnsmasq does not have any configuration of /etc/resolv.conf itself. It does not change system resolver. That is the reason why it does not have lower priority already. In the contrary, it reads /etc/resolv.conf itself, uses it to define forwarders. If /etc/resolv.conf should not be used, server options has to be used in configuration instead. You can always change priority of any service on your system if you have reason for it.
Ok, I admit I could not find any reason, why dnsmasq has such priority. It was changed about ten years ago from 99 to 49, the reason was very similar to your issue. Check bug #494094 for details. It seems this was not enough. I could not find any evidence how was chosen original value in the first place.
I has to be between priority of network and netfs service on startup. That is between 10 and 25 on start. syslog service has priority 12.
named service has priority 13, unbound 14. It might be forwarding to the DNS service on local port, it should have higher priority than them. I doubt it makes any sense to run dhcp relay proxy on one host with local dhcp server. Dnsmasq can use dbus, which has priority 22. So good value for new priority might be 23. It is higher than others DNS providers, but still low enough for any service using DNS.
chkconfig: - 23 86
dbus-1 is provided by service messagebus. Shutdown priority is set higher to shut down before messagebus, which does not follow usual 100-start priority value.
Comment 7RHEL Program Management
2019-06-04 13:55:49 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.