System is using wicked for network configuration. All network interfaces are configured for DHCP.
Occasionally, /etc/resolv.conf is not updated but instead just contains the boilerplate version.
2020-01-06T17:21:06.951534-05:00 demo nscd: 716 monitoring file /etc/resolv.conf (5)
2020-01-06T17:21:40.873617-05:00 demo dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched…
2020-01-06T17:21:40.878649-05:00 demo dns-resolver: You can find my version in /etc/resolv.conf.netconfig
If I copy over /etc/resolv.conf.netconfig to /etc/resolv.conf then name lookups work as expected.
After a few reboots the problem reappears. It appears that the modification-check done by dns-resolver has a bug in it. I have seen this phenomenon on two machines. Once on my laptop (wireless), and several times on a wired box. The box may not have been properly shut down, but I know my laptop was.
While it is just annoying on my laptop, it is more serious on the box as it is shipped to customers and unattended. If the box “doesn’t work” at the customer then they have to ship it back to us, and since I don’t know what is causing it I don’t have any other choice than just hope it doesn’t happen again.
I’ve tried to find any bug reports or solution but (a) I cannot figure out which component “dns-resolver” is, and (b) similar problems seem to be rare.
Does anyone know which component “dns-resolver” is so I can dig though bug reports and fixes?
Has anyone else seen this bug?
While that workaround is a possibility on my laptop it is not feasible on the unattended box because it is hundredths of kilometers away in closet at a customer who can’t and shouldn’t log into the box a fix it. There is no remote connection to the box until the internet connection is up and working including DNS.
Is not a bug.
Your log output is clear, resolv.conf is not updating because it detected the file has been altered so you have to stop doing whatever you’re doing to alter the file.
Read the comments embedded in /etc/resolv.config
Describes how and where to modify files as necessary for your setting to be persistent… particularly if you want to over-ride what DHCP provides.
And, the DHCP client should update automatically, but if you’re shipping a system, the network service may need to be restarted to pick up the new settings.
Unless you’re doing some temporary testing,
Never edit /etc/resolv.conf directly.
BTW - You should be aware that LEAP 15.0 is past EOL.
Upgrade.
This is part of syconfig-netconfig package (/etc/netconfig.d/dns-resolver). Note that implementation was changed in Leap 15.1, it now generates file in private directory and avoids keeping and checking md5sum completely. If you want to use netconfig at all you are expected to link /etc/resolv.conf to this private file.
Has anyone else seen this bug?
There was quote a lot of reports about similar problem with NetworkManager at one point. Common “solution” was to run “netconfig -f update”
As workaround you may try setting NETCONFIG_FORCE_REPLACE=“yes” in /etc/sysconfig/network/config if you are sure to never touch /etc/resolv.conf manually.
That is the key point. I haven’t touched resolv.conf and nothing else has. /etc/resolv.conf is the plain boiler-plate version with the usual “### /etc/resolv.conf file autogenerated by netconfig!” line and no “search” or nameserver" entries. So the file is what was originally generated by network-config. I haven’t touched it. Yet dns-resolver claims it has been changed so it must have some logic in that area that could be improved.
The only way I can restart the network service at a remote location when it happens is asking the customer to power-cycle the box, and I’m not even convinced that that always helps.
I am aware of that. It was shipped when 15.0 was the newest release and it took this long for the customer to actually test it.
Meanwhile, I have found that it is the script /etc/sysconfig/network/scripts/functions.netconfig that outputs that warning and I will see if I can find the bug in it.
Good luck.
Sounds like your situation is going to require some risk evaluation…
If you upgrade which itself might be tricky over long distance, your problem might be resolved on its own.
Arvidjaar’s observation is interesting but applies to 15.1. Maybe it’s worth looking at whether the 15.1 change somehow made it on to your 15.0, or maybe it doesn’t make a difference… Just do the related setting no matter what if you believe at worst it might be simply ineffective.
You can try to do a “force re-install” of the related package, but I’d have been more comfortable if you were able to do it with the latest package from a working update repository… That’s not likely now, although you could point to an archived repository (ask if you really want to do this). A successful re-installation of course returns settings to default to eliminate any residue from whatever has changed manually.
Or, just remembered…
Delete /etc/resolv.conf (or rename to something else) and reboot.
The file should be regenerated automatically which should address whatever is causing the file to appear “changed.”
> l /etc/resolv.conf
lrwxrwxrwx 1 root root 30 2. Jul 2019 /etc/resolv.conf -> /var/run/netconfig/resolv.conf
>
> rpm --query --whatprovides /etc/resolv.conf
file /etc/resolv.conf is not owned by any package
>
> cat /etc/resolv.conf
### /etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf
### autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
# NETCONFIG_DNS_STATIC_SEARCHLIST
# NETCONFIG_DNS_STATIC_SERVERS
# NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
# NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
### Call "netconfig update -f" to force adjusting of /etc/resolv.conf.
options inet6 edns0 single-request single-request-reopen
search fritz.box
nameserver 192.168.178.1
nameserver fd00::5e49:79ff:fedc:e1aa
>
As the file located in “/var/run/netconfig/”, autogenerated by “netconfig” says:
define the static DNS configuration using the following variables in the /etc/sysconfig/network/config file:
The files “config” and “dhcp” located in “/etc/sysconfig/network/” contain all the parameters needed to ensure that, netconfig does “the right thing” at boot time …
