NetworkConfiguration
openresolv 3.17.0-1 breaks netctl unit startup if resolv.conf has immutable attribute set.
System OS: Archlinux
Following updates to an Archlinux server on 6/28/25, the server would start the netctl network device enp5s0 just fine, but then mysteriously the network device would be taken down. This server has been running since 2015 and has never failed to bring up the network before. After searching through the journal the only errors found were:
Jun 29 00:44:54 valkyrie avahi-daemon[724]: Network interface enumeration completed.
Jun 29 00:44:54 valkyrie avahi-daemon[724]: Registering new address record for ::1 on lo.*.
Jun 29 00:44:54 valkyrie avahi-daemon[724]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jun 29 00:44:55 valkyrie systemd[1]: Finished IPv4 Packet Filtering Framework.
Jun 29 00:44:55 valkyrie systemd[1]: Reached target Preparation for Network.
Jun 29 00:44:55 valkyrie systemd[1]: Starting A basic static ethernet connection...
Jun 29 00:44:55 valkyrie network[779]: Starting network profile 'ethernet-statis-valkyrie'...
Jun 29 00:44:55 valkyrie kernel: RTL8211E Gigabit Ethernet r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
Jun 29 00:44:55 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Jun 29 00:44:55 valkyrie avahi-daemon[724]: Server startup complete. Host name is valkyrie.local. Local service cookie is 357913226.
Jun 29 00:44:56 valkyrie avahi-daemon[724]: Service "dcr4100n" (/services/dcr4100n.service) successfully established.
Jun 29 00:44:56 valkyrie avahi-daemon[724]: Service "LaserJet" (/services/LaserJet.service) successfully established.
Jun 29 00:44:57 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx
Jun 29 00:44:57 valkyrie systemd[1]: Started A basic static ethernet connection.
Jun 29 00:44:57 valkyrie systemd[1]: Reached target Network.
Jun 29 00:44:57 valkyrie systemd[1]: Reached target Network is Online.
Jun 29 00:44:57 valkyrie avahi-daemon[724]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.6.14.
Jun 29 00:44:57 valkyrie avahi-daemon[724]: New relevant interface enp5s0.IPv4 for mDNS.
Jun 29 00:44:57 valkyrie avahi-daemon[724]: Registering new address record for 192.168.6.14 on enp5s0.IPv4.
Jun 29 00:44:57 valkyrie systemd[1]: Started ClamAV virus database updater.
Jun 29 00:44:57 valkyrie systemd[1]: Starting IPv4 DHCP server...
Jun 29 00:44:57 valkyrie systemd[1]: Starting Dovecot IMAP/POP3 email server...
Jun 29 00:44:57 valkyrie systemd[1]: Starting Fail2Ban Service...
Jun 29 00:44:57 valkyrie systemd[1]: Started Apache Web Server.
Jun 29 00:44:57 valkyrie systemd[1]: Starting MariaDB 11.8.2 database server...
Jun 29 00:44:57 valkyrie systemd[1]: Started Internet domain name server.
Jun 29 00:44:57 valkyrie systemd[1]: Starting Network UPS Tools - power device driver controller...
Jun 29 00:44:57 valkyrie systemd[1]: Starting Postfix Mail Transport Agent...
Jun 29 00:44:57 valkyrie systemd[1]: Starting PostgreSQL database server...
Jun 29 00:44:58 valkyrie systemd[1]: Starting Samba SMB Daemon...
Jun 29 00:44:58 valkyrie systemd[1]: Started Spamassassin daemon.
Jun 29 00:44:58 valkyrie systemd[1]: Starting OpenSSH Daemon...
Jun 29 00:44:58 valkyrie systemd[1]: Starting Permit User Sessions...
Jun 29 00:44:58 valkyrie systemd[1]: Started Fail2Ban Service.
Jun 29 00:44:58 valkyrie systemd[1]: Finished Permit User Sessions.
Jun 29 00:44:58 valkyrie systemd[1]: Started Command Scheduler.
Jun 29 00:44:58 valkyrie systemd[1]: Starting Light Display Manager...
Jun 29 00:44:58 valkyrie network[847]: resolvconf: signature mismatch: /etc/resolv.conf
Jun 29 00:44:58 valkyrie network[847]: resolvconf: run `resolvconf -u` to update
<snip>
Jun 29 00:44:59 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Jun 29 00:44:59 valkyrie avahi-daemon[724]: Interface enp5s0.IPv4 no longer relevant for mDNS.
Jun 29 00:44:59 valkyrie systemd[1]: netctl@ethernet\x2dstatis\x2dvalkyrie.service: Main process exited, code=exited, status=1/FAILURE
Jun 29 00:44:59 valkyrie network[779]: Failed to bring the network up for profile 'ethernet-statis-valkyrie'
Jun 29 00:44:59 valkyrie avahi-daemon[724]: Leaving mDNS multicast group on interface enp5s0.IPv4 with address 192.168.6.14.
Jun 29 00:44:59 valkyrie systemd[1]: netctl@ethernet\x2dstatis\x2dvalkyrie.service: Failed with result 'exit-code'.
Jun 29 00:44:59 valkyrie avahi-daemon[724]: Withdrawing address record for 192.168.6.14 on enp5s0.
Relevant here are the entries:
Jun 29 00:44:58 valkyrie network[847]: resolvconf: signature mismatch: /etc/resolv.conf
Jun 29 00:44:58 valkyrie network[847]: resolvconf: run `resolvconf -u` to update
That has never occurred before and was causing the network interface (after being successfully brought up) to be taken down as the netctl unit is now considered FAILED if resolv.conf is immutable.
The resolv.conf file on my system has been immutable since December 10, 2022 because the rewritten resolv.conf continually broke name resolution on the network and wasn't accommodating secondary DNS servers causing zone transfers to fail. Extended attributes make /etc/resolv.conf immutable, e.g.
$ lsattr /etc/resolv.conf
----i---------e------- /etc/resolv.conf
This now causes openresolv to report a failure in the netctl unit activation where it never did before.
Expected Behavior
openresolv will not touch my /etc/resolv.conf if it is immutable and will not cause my netctl interface activation and setup of the static IP for the server to fail.
Workaround
Downgrading openresolv 3.17.0-1 => 3.16.5-1 restored perfect server operation. So there is a change in openresolv between version 3.16.5 and 3.17.0 that breaks network interface activation on systems where /etc/resolv.conf cannot be modified.
netctl profile and configuration
Trivial static IP setup, not sure if needed, but provided for completeness. (let me know if you need anything else)
$ cat /etc/systemd/system/netctl@ethernet\\x2dstatis\\x2dvalkyrie.service.d/profile.conf
[Unit]
Description=A basic static ethernet connection
BindsTo=sys-subsystem-net-devices-enp5s0.device
After=sys-subsystem-net-devices-enp5s0.device
$ cat /etc/netctl/ethernet-statis-valkyrie
Description='A basic static ethernet connection'
Interface=enp5s0
Connection=ethernet
IP=static
Address=('192.168.6.14/24')
Gateway='192.168.6.11'
DNS=('192.168.6.14')
I experienced the exact same issue trying to bring up my wireguard tunnel on Archlinux:
[jaap@Ultrabook-Jaap ~]$ sudo systemctl start wg-quick@work
[sudo] password for jaap:
Job for [email protected] failed because the control process exited with error code.
See "systemctl status [email protected]" and "journalctl -xeu [email protected]" for details.
[jaap@Ultrabook-Jaap ~]$ sudo systemctl status wg-quick@work
× [email protected] - WireGuard via wg-quick(8) for work
Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; preset: disabled)
Active: failed (Result: exit-code) since Sun 2025-06-29 17:16:42 CEST; 4s ago
Invocation: 9c5c5e22feae4ed68383071fff58bf18
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 2912 ExecStart=/usr/bin/wg-quick up work (code=exited, status=1/FAILURE)
Main PID: 2912 (code=exited, status=1/FAILURE)
Mem peak: 7.3M
CPU: 85ms
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2912]: [#] ip -4 address add 192.168.105.103/24 dev work
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2912]: [#] ip -6 address add fdf5:eb17:0666:105::103/64 dev work
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2912]: [#] ip link set mtu 1420 up dev work
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2948]: [#] resolvconf -a work -m 0 -x
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2974]: resolvconf: signature mismatch: /etc/resolv.conf
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2974]: resolvconf: run `resolvconf -u` to update
Jun 29 17:16:42 Ultrabook-Jaap wg-quick[2912]: [#] ip link delete dev work
Jun 29 17:16:42 Ultrabook-Jaap systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Jun 29 17:16:42 Ultrabook-Jaap systemd[1]: [email protected]: Failed with result 'exit-code'.
Jun 29 17:16:42 Ultrabook-Jaap systemd[1]: Failed to start WireGuard via wg-quick(8) for work.
Downgrading to openresolv 3.16.5 fixed the issue for me.
It seems like NetworkManager puts "#Generated by NetworkManger" as the first line in resolv.conf when it starts up, so when you start a Wireguard connection, resolvconf checks for '"Generated by resolvconf" as the signature, sees a mismatch, and chooses not to overwrite resolv.conf
@drankinatty If your resolv.conf is immutable, why are you setting DNS in your netctl config? Does removing that fix it for you?
Networkmanager need to be built with resolvconf support.
Does that mean this is a bug that needs fixing in the archlinux NetworkManager package? Because it's definitely a regression given the fact that downgrading openresolv fixes it.
I experienced the exact same issue trying to bring up my wireguard tunnel on Archlinux:
I confirm, I get the same error using wireguard and openresolv on my Archlinux machine with the latest 3.17.0-1 update, whereas before this update, I have never had an issue where it did not connect automatically and without error or fail.
I have the same issue with just networkmanager and wireguard/openconnect vpn on arch. I worked around it by creating a drop in config in /etc/NetworkManager/conf.d/ with the following:
[main]
rc-manager=resolvconf
This tells network manager explicitly to use resolvconf to manage /etc/resolv.conf. After that just delete the outdated file (the one with the "#Generated by NetworkManger" at the beginning) and disconnect and reconnect the networkmanager connection. It should generate a new resolv.conf, this time with "# Generated by resolvconf". VPNs now work as expected again.
see also: https://wiki.archlinux.org/title/NetworkManager#Use_openresolv
Networkmanager need to be built with resolvconf support.
Does that mean this is a bug that needs fixing in the archlinux NetworkManager package? Because it's definitely a regression given the fact that downgrading openresolv fixes it.
It's not viewed as a regression, but it is an intended change in behavior.
Basically this change solves two problems
- It was unclear who owned /etc/resolv.conf before - now openresolv will only update /etc/resolv.conf if it thinks it has the right to do so.
- Because of 1), you actually have an issue where NetworkManager would overwrite /etc/resolv.conf again when DHCP renewed and boom, your VPN DNS just disappears.
Now we have forced ownership and have coerced NetworkManager into using resolvconf, you have a more reliable DNS setup compared to before this change.
I have the same issue with just networkmanager and wireguard/openconnect vpn on arch. I worked around it by creating a drop in config in /etc/NetworkManager/conf.d/ with the following:
[main] rc-manager=resolvconfThis tells network manager explicitly to use resolvconf to manage /etc/resolv.conf. After that just delete the outdated file (the one with the "#Generated by NetworkManger" at the beginning) and disconnect and reconnect the networkmanager connection. It should generate a new resolv.conf, this time with "# Generated by resolvconf". VPNs now work as expected again.
see also: https://wiki.archlinux.org/title/NetworkManager#Use_openresolv
Excellent find, thanks! I'll leave this issue open for a while so people upgrading and see it and hopefully not make any new ones.
I have the same issue with just networkmanager and wireguard/openconnect vpn on arch. I worked around it by creating a drop in config in /etc/NetworkManager/conf.d/ with the following:
[main] rc-manager=resolvconf
For me, I tried the above, and it didn't work, but what did work was installing dhcpcd, and telling NetworkManager to use it https://wiki.archlinux.org/title/NetworkManager#DHCP_client
/etc/NetworkManager/conf.d/dhcp-client.conf
[main]
dhcp=dhcpcd
Thanks, @Dangonizer for pointing us in the right direction.
Sheepishly -- that's what the /etc/netctl/examples/static-IP file had in it, so I left it back in 2015 when I did the install :) I'll remove it, reboot and report back. Is there anyway openresolv can just check whether /etc/resolv.conf is not writable or has extended attributes set and just ignore it if it does? The biggest issue I've run into (and what prompted making /etc/resolv.conf immutable) is there was an absence in documentation discussing any of the caveats I ran into.
The server here provides mail and database backends for several companies, so it will be after 5:00 today before I can reinstall 3.17 and restart the network interface without any interruptions. If removing the DNS entry from the netctl interface file doesn't allow the unit to start, I can bring the interface up manually (ip set enp5s0 up) and restore the default route, but it leaves the netctl unit marked as FAILED, so I'd rather make the changes when I have a bit of time to downgrade again if needed without getting a bunch of phone calls on why the server keeps disappearing :)
Will report back.
Also Archlinux Bug - tracking this issue as upstream
Report of DNS Removal from netctl config
Roy, this is encouraging, I removed the DNS entry from /etc/netctl/ethernet-statis-valkyrie and updated to openresolv 3.17. I was then able to restart the network interface without it failing (slipped it in at lunch). I suspect the same will hold true on reboot. The error about signature mismatch on /etc/resolv.conf wasn't triggered. The journal entries for the restart sequence were:
Jun 30 13:38:08 valkyrie sudo[56522]: david : TTY=pts/3 ; PWD=/home/david ; USER=root ; COMMAND=/usr/bin/systemctl restart netctl@ethernet\\x2dstatis\\x2dvalkyrie.service
Jun 30 13:38:08 valkyrie sudo[56522]: pam_unix(sudo:session): session opened for user root(uid=0) by david(uid=1000)
Jun 30 13:38:08 valkyrie systemd[1]: Stopping A basic static ethernet connection...
Jun 30 13:38:08 valkyrie network[56530]: Stopping network profile 'ethernet-statis-valkyrie'...
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Withdrawing address record for 192.168.6.14 on enp5s0.
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Leaving mDNS multicast group on interface enp5s0.IPv4 with address 192.168.6.14.
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Interface enp5s0.IPv4 no longer relevant for mDNS.
Jun 30 13:38:08 valkyrie named[831]: no longer listening on 192.168.6.14#53
Jun 30 13:38:08 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Interface enp5s0.IPv6 no longer relevant for mDNS.
Jun 30 13:38:08 valkyrie dhcpd[871]: receive_packet failed on enp5s0: Network is down
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Leaving mDNS multicast group on interface enp5s0.IPv6 with address fe80::feaa:14ff:fe9e:3319.
Jun 30 13:38:08 valkyrie avahi-daemon[723]: Withdrawing address record for fe80::feaa:14ff:fe9e:3319 on enp5s0.
Jun 30 13:38:08 valkyrie network[56530]: Stopped network profile 'ethernet-statis-valkyrie'
Jun 30 13:38:08 valkyrie systemd[1]: netctl@ethernet\x2dstatis\x2dvalkyrie.service: Deactivated successfully.
Jun 30 13:38:08 valkyrie systemd[1]: Stopped A basic static ethernet connection.
Jun 30 13:38:08 valkyrie systemd[1]: Starting A basic static ethernet connection...
Jun 30 13:38:08 valkyrie network[56544]: Starting network profile 'ethernet-statis-valkyrie'...
Jun 30 13:38:08 valkyrie kernel: RTL8211E Gigabit Ethernet r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
Jun 30 13:38:08 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Jun 30 13:38:10 valkyrie kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx
Jun 30 13:38:11 valkyrie systemd[1]: Started A basic static ethernet connection.
Jun 30 13:38:11 valkyrie sudo[56522]: pam_unix(sudo:session): session closed for user root
Jun 30 13:38:11 valkyrie avahi-daemon[723]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.6.14.
Jun 30 13:38:11 valkyrie avahi-daemon[723]: New relevant interface enp5s0.IPv4 for mDNS.
Jun 30 13:38:11 valkyrie avahi-daemon[723]: Registering new address record for 192.168.6.14 on enp5s0.IPv4.
Jun 30 13:38:11 valkyrie named[831]: listening on IPv4 interface enp5s0, 192.168.6.14#53
Jun 30 13:38:11 valkyrie network[56544]: Started network profile 'ethernet-statis-valkyrie'
Jun 30 13:38:12 valkyrie avahi-daemon[723]: Joining mDNS multicast group on interface enp5s0.IPv6 with address fe80::feaa:14ff:fe9e:3319.
Jun 30 13:38:12 valkyrie avahi-daemon[723]: New relevant interface enp5s0.IPv6 for mDNS.
Jun 30 13:38:12 valkyrie avahi-daemon[723]: Registering new address record for fe80::feaa:14ff:fe9e:3319 on enp5s0.*.
Is there somewhere the effect of having the DNS entry in the netctl config on openresolv behavior is documented? When researching the failure originally, I didn't discover any? My search foo may just be off too. I wasn't even aware that openresolv was a thing until a suggestion was made on the arch-general mailing list.
Will removing the DNS entry prevent openresolv and the systemd resolver from attempting to modify /etc/resolv.conf? I would prefer being able to remove the immutable attribute, but I manage `/etc/resolv.conf`` for this server and do not want it modified. I've been down that road before and that's why the attribute was originally set.
Glad to see the restart went fine with 3.17 reinstalled. Will reboot tonight and report back if there are issues -- though given the restart succeeded, I don't expect any.
Reboot fine with DNS removed
As expected, since the restart succeeded after removing DNS from the netctl interface config, there was no trouble on reboot. Which is critical, since this box is remotely adminned. The unexpected changes that cause network failure are quite acute in this case.
Suggestions (partially educated guesses)
To avoid this issue completely, why not:
- check the signature on
/etc/resolv.conf. Only when the signature is a known signature, attempt modification of/etc/resolv.confand handle errors. Otherwise, treat the lack of a known signature as being the same as aDISABLED=truefor openresolv attempts to modify/etc/resolv.confregardless of netctl config contents; or - provide a way to disable openresolv completely similar to the suggestion of
DISABLED=true. That provides a tool for servers or boxes where dynamic modification of/etc/resolv.confisn't desired to ensure there are no modifications and it also avoids the side-effect of any config entry causing the network activation to be incorrectly reported as failed.
openresolv provides great features, but in some cases what it does isn't desirable. Here this server never moves from internet-cafe to internet-cafe and its environment never changes. It sets name resolution for the entire LAN. Dynamic changes to /etc/resolv.conf have caused no end of issues. The self-adminned /etc/resolv.conf is necessary here, and we just need to find a simple way for openresolv (and systemd) to respect that and not cause problems where none existed before. The removing the DNS entry did the trick here, but that's more one of the things the developers would know than something that would be apparent to those setting up the netctl interface config. It could be resolved with simple comment additions to the /etc/netctl/example files to make it apparent, e.g.
# If this DNS entry is included and resolvconf cannot modify /etc/resolv.conf,
# the netctl unit activation will fail. Comment out the entry if /etc/resolv.conf is
# self-administered.
DNS=('192.168.1.1')
I have not been through the source, so these were just ideas that popped into my head as I was thinking though these issues and I thought I would pass them along. Just consider them lay-person ideas. That said, I've often found the following good guidance:
"A new feature to one is a bug to another if it cannot be turned off."
Simply providing a documented way to disable attempts to modify /etc/resolv.conf solves all of issues I've had and would allow me to remove the immutable lock on /etc/resolv.conf. Thank you for all your help and your work on openresolv. Let me know if you need anything else, logs, configs, etc.. and I'm happy to provide them.
Is there somewhere the effect of having the DNS entry in the netctl config on openresolv behavior is documented? When researching the failure originally, I didn't discover any? My search foo may just be off too. I wasn't even aware that openresolv was a thing until a suggestion was made on the arch-general mailing list.
Documented? No. It's generally accepted that if you ask some thing to be modified and it fails it should fail. You had two things in play - resolvconf obeying netctl but failing silently (a bug) now fixed and failing noisily to reveal a bug in your config.
For example, should rm /etc/resolv.conf fail noisily when you have made it immutable?
Will removing the DNS entry prevent openresolv and the systemd resolver from attempting to modify
/etc/resolv.conf? I would prefer being able to remove the immutable attribute, but I manage `/etc/resolv.conf`` for this server and do not want it modified. I've been down that road before and that's why the attribute was originally set.
It will prevent netctl from attempting to modify it via whatever means. Beyond that I can't say.
1. check the signature on `/etc/resolv.conf`. Only when the signature is a **known signature**, attempt modification of `/etc/resolv.conf` and handle errors. Otherwise, treat the lack of a known signature as being the same as a `DISABLED=true` for openresolv attempts to modify `/etc/resolv.conf` regardless of netctl config contents; or
Commands should fail nosily when asked to do something they cannot, so no, sorry.
2. provide a way to disable openresolv completely similar to the suggestion of `DISABLED=true`. That provides a tool for servers or boxes where dynamic modification of `/etc/resolv.conf` isn't desired to ensure there are no modifications and it also avoids the side-effect of any config entry causing the network activation to be incorrectly reported as failed.
We already do :)
In /etc/resolvconf.conf you can disable openresolv entirely resolvconf=NO or just the libc subscriber libc=NO which is the part which updates /etc/resolv.conf
This is documented in the fine man page.
openresolv provides great features, but in some cases what it does isn't desirable. Here this server never moves from internet-cafe to internet-cafe and its environment never changes. It sets name resolution for the entire LAN. Dynamic changes to
/etc/resolv.confhave caused no end of issues. The self-adminned/etc/resolv.confis necessary here, and we just need to find a simple way for openresolv (and systemd) to respect that and not cause problems where none existed before. The removing the DNS entry did the trick here, but that's more one of the things the developers would know than something that would be apparent to those setting up the netctl interface config. It could be resolved with simple comment additions to the/etc/netctl/examplefiles to make it apparent, e.g.# If this DNS entry is included and resolvconf cannot modify /etc/resolv.conf, # the netctl unit activation will fail. Comment out the entry if /etc/resolv.conf is # self-administered. DNS=('192.168.1.1')I have not been through the source, so these were just ideas that popped into my head as I was thinking though these issues and I thought I would pass them along. Just consider them lay-person ideas. That said, I've often found the following good guidance:
"A new feature to one is a bug to another if it cannot be turned off."
Simply providing a documented way to disable attempts to modify
/etc/resolv.confsolves all of issues I've had and would allow me to remove the immutable lock on/etc/resolv.conf. Thank you for all your help and your work on openresolv. Let me know if you need anything else, logs, configs, etc.. and I'm happy to provide them.
These features already exist as I said above. Maybe suggest the example to netctl upstream?
But consider this - resolvconf (not just this implementation, but others too) is supposed to be the single source of truth for DNS configuration.
If you instruct netctl to use resolvconf and resolvconf cannot do it's job it should fail noisily. So you have some options - stop netctl from trying to set DNS or let resolvconf do it's job or disable resolvconf
Roy, thank you -- for both the work openresolv and for the education. resolvconf=NO is perfect (or libc=NO may be more appropriate - I need to do a bit more reading to figure out which). I am old-school (as in about to turn all this stuff over to the next generation old). For all my process management I've always preferred the Linux KISS philosophy of single text file for single process. When this server was built in 2015 there wasn't a mention of resolvconf or any other external resolver tools. Inevitably since then systemd and associated processes have proliferated much like weeds in a vacant lot until they impact just about every basic peripheral/process startup in some way. The pace of change has been swift.
I have a number of desktop boxes that make use of resolvconf/openresolv through whatever hooks are provided via dhcpcd, and they work fine receiving the information the server provides via dhcpd. The server handles dynamic update of the DNS zone files and zone transfers to the backup server. This works flawlessly if, and only if, /etc/resolv.conf doesn't change on the server. Through whatever growing pains the dynamic resolver went through in late 2022, getting a working resolv.conf because a dice-roll and the file was simply made immutable to ensure a stable configuration.
I'm sure things have improved since then, but that really brings into focus the question "for servers such as this where /etc/resolv.conf will not change, it is worth the risk to allow the file to be dynamically updated?" A fixed /etc/resolv.conf guarantees name resolution will come back up on reboot exactly as it was when the reboot was requested. Dynamic update of the file brings in a huge daisy-chain of dependencies and sourced shell scripts that a change to any one of the packages involved could result in the newly generated file leaving name resolution inoperable. resolvconf=NO and libc=NO are perfect solutions to cover that case. Still have more reading to do on whether disabling all "subscribers" has any other side-effect on the rest of what systemd does during startup, but as long as the /etc/hostname, /etc/hosts, and /etc/resolv.conf files are respected when all subscribers are disabled, then that seems like just what is needed in my case.
I see the logic in your assessment of the "partially educated guesses" provided, and this matter looks complete. Thank you again for your help and continued work on this package. Progress has been made.
You can close this bug if you are done with it, I just don't want to presume its done for all others who have commented here, so that is left to your discretion.
resolvconf=NO stops everything from running. No resolvconf commands have any effect, and as such there will be no errors (beyond invalid commands).
libc=NO just stops /etc/resolv.conf from being updated - everything else still works.
This means resolvconf -l will show the DNS it will try to configure and if you have configured a local resolver such as unbound, dnsmasq or even systemd-resolved then that will still be updated.
Hope this helps :)
My company uses a software that generates a wg-quick configuration with a DNS= line and I have no way to remove this, as the configuration file gets deleted as soon as the bridge fails to initialize. I had to downgrade to the previous version.
The suggested solution would actually make the VPN to change the DNS configuration, which I do not want.
@Exagone313 can you explain your problem a bit better?
If you set libc=NO then openresolv won't change /etc/resolv.conf
If you set resolvconf=NO then openresolv won't change anything.
Set those in /etc/resolvconf.conf
The suggested solution would actually make the VPN to change the DNS configuration, which I do not want.
What part of not changing DNS did I miss?