[SOLVED] Networkmanager with dnsmasq fails to resolve

harmathy · 2022-10-25 12:09:36

Hi,

I have Networkmanager set up to use dnsmasq /etc/NetworkManager/conf.d/dns.conf:

[main]
# Use dnsmasq for caching and network specific DNS
dns=dnsmasq

And I use it to resolve names of virtual machines with the domain kvm.corp (libvirt has its own instance of dnsmasq running on 192.168.122.1) /etc/NetworkManager/dnsmasq.d/kvm.conf:

no-negcache
server=/kvm.corp/192.168.122.1

This worked well for a long time. But recently it stopped working. All other name resolution from Networkmanager connection (e.g. wireguard) work perfectly fine.

Interestingly, the name resolution works, if I reload the Networkmanager config with:

# nmcli general reload

I can reproduce the behavior with another dnsmasq instance listening on 127.0.2.1:

# dnsmasq --no-resolv --keep-in-foreground --no-hosts --listen-address=127.0.2.1 --bind-interfaces --address=/my-box.local.lan/127.0.0.2

It just resolves my-box.local.lan to 127.0.0.2:

$ dig @127.0.2.1 my-box.local.lan

; <<>> DiG 9.18.8 <<>> @127.0.2.1 my-box.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29195
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;my-box.local.lan.        IN    A

;; ANSWER SECTION:
my-box.local.lan.    0    IN    A    127.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.2.1#53(127.0.2.1) (UDP)
;; WHEN: Tue Oct 25 13:57:10 CEST 2022
;; MSG SIZE  rcvd: 61

Now, if I add another config file /etc/NetworkManager/dnsmasq.d/local.conf:

server=/local.lan/127.0.2.1

and restart Networkmanager, the name resolution doesn't work:

$ dig my-box.local.lan

; <<>> DiG 9.18.8 <<>> my-box.local.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18640
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;my-box.local.lan.        IN    A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Oct 25 13:59:24 CEST 2022
;; MSG SIZE  rcvd: 45

But after reloading the config:

# nmcli general reload

it does work:

$ dig my-box.local.lan

; <<>> DiG 9.18.8 <<>> my-box.local.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13179
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;my-box.local.lan.        IN    A

;; ANSWER SECTION:
my-box.local.lan.    0    IN    A    127.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Oct 25 13:59:56 CEST 2022
;; MSG SIZE  rcvd: 61

Anybody experiencing the same problem?

Last edited by harmathy (2022-10-28 17:58:20)

sgoericke · 2022-10-27 17:30:04

I can confirm the same issue, but didn't try nmcli yet, instead I restart NetworkManager until name resolution works again. My configuration looks almost the same:

$ cat /etc/NetworkManager/conf.d/99-localdns.conf 
[main]
dns=dnsmasq

$ cat /etc/NetworkManager/dnsmasq.d/00-libvirt_dnsmasq.conf 
server=/jio.test/192.168.122.1
server=/ansible.test/192.168.125.1

However, this seems not to be arch-specific, same issue I noticed on Fedora couple of weeks ago. Unfortunately I don't find much time to dig into this further, and since there's a "kind of workaround" (by restarting nm or, in your case, reloading it's config) I silently wait for an update where things will work smoothly again.

rene · 2022-10-27 17:53:02

Also confirming (on Manjaro); it also works to "sudo killall dnsmasq" (it restarts immediately) to get the manually configured servers functional.

If you look at the journalctl log it seems that servers added manually with e.g. as per above "server=" conf files are in fact purged again at the time that NetworkManager adds its DHCP-retrieved ones via DBus: try a "sudo killall -USR1 dnsmasq" to have dnsmasq spit its configured servers to the journalctl log. Originally you'll see only the DHCP ones; after that killall and automatic restart of dnsmasq you find them all.

NetworkManager's dnsmasq plugin seems not so much a plugin, in the sense that it's baked into /usr/bin/NetworkManager itself so it's a all a bit opaque -- but this seems a definite NetworkManager bug. Sort of dreading reporting it there and being in time-honoured Linux bugzilla-fashion told that it's all just obsolete anyway, and why am I not using systemd-resolved, and...

seth · 2022-10-27 20:49:56

Smells like https://gitlab.freedesktop.org/NetworkM … ssues/1095
Does downgrading dsnmasq "help"?

rene · 2022-10-27 23:48:23

seth wrote:

Smells like https://gitlab.freedesktop.org/NetworkM … ssues/1095

No, that's not going to be involved; my dnsmasq configuration is entirely minimal; there are no timeouts and NetworkManager doesn't kill dnsmasq. If it would it'd probably start working in fact, cf. my above post of manually killing it once...

However, given that I needed to do so anyway I created a Manjaro Cinnamon VirtualBox VM which at the time of writing starts out from the ISO with NetworkManager 1.38.4-1 and dnsmasq 2.86-2 whereas the current versions are 1.40.0-1 and 2.87-1 respectively. That combination worked (in the VM). Upgrading dnsmasq: still. Upgrading NM: still. Errm. Upgrading the entire VM to newest: still works. And still does not on the host system. Errm.

I.e., things fail in a fully upgraded Manjaro Xfce as per my above description -- the manual .conf servers are initially configured but then later purged, seemingly when NM adds its DHCP-retrieved servers via DBUs -- yet work in a on that same system running VM of fully upgraded Manjaro Cinnamon, all with the as far as seemingly relevant exact same software versions and with definitely the exact same configuration.

Easiest test of things is having e.g. /etc/NetworkManager/conf.d/dns-dnsmasq.conf

[main]
dns=dnsmasq

together with e.g. /etc/NetworkManager/conf.d/dnsmasq.d/opennic.conf

server=/dyn/195.10.195.195

Make sure to "systemctl restart NetworkManager.service".

OpenNIC comprises an alternative DNS with additional TLDs such as .dyn; this is the context in which I myself ran into the issue: I have (had) a few .dyn domains registered which stopped working when I moved a system over from Linux Mint to Manjaro. In any case; .dyn is not a valid "normal" TLD so certainly e.g.

ping reg.dyn

will work if and only if the setup is working. It as said does not on my fully upgraded Manjaro Xfce host yet does on my fully upgraded Manjaro Cinnamon guest. Which seems to say this might just be some exceedingly annoying timing-dependent issue deep in a library...

I've in a practical sense dealt with the issue by closing the .dyn domains I had since I wasn't using them anyway and I won't care too deeply anymore but certainly there's a bug somewhere. If someone uses the above setup to test: note also that "journalctl -b" shows what servers dnsmasq is configuring during startup, and that "killall -USR1 dnsmasq" has it spit its currently active servers to said log. In a situation such as on my host and supposedly as for the two first responders in this thread, you'd see all servers initially configured, both the .conf one(s) and DHCP-retrieved ones, but would from an initial USR1 see only latter, and after killing dnsmasq outright once from a second USR1 see all again.

Weird goings on.

seth · 2022-10-28 07:01:49

Upgrading the entire VM to newest: still works.

Ie. the version test on the VM is irrelevant.
Given that the linked bug has dnsmasq startup ~s => > 60s, there's probably some IO wait involved. And as NM has a 10s timeout and eg. the default dbus timeout is 25s I'd just try to downgrade the host dnsmasq to 2.85 (last reported good version) to see whether that's relevant and then work on from there.

harmathy · 2022-10-28 07:22:17

seth wrote:

Smells like https://gitlab.freedesktop.org/NetworkM … ssues/1095
Does downgrading dsnmasq "help"?

Yes, downgrading dnsmasq to 2.86-2 seems to also solve the problem. However, since that bug report is about 2.86 and the configuration isn't that huge, I suppose this is a new issue.

sgoericke · 2022-10-28 08:11:41

I'm not sure yet but for me it looks like a kind of "race-condition" between instances of dnsmasq. Found a couple of minutes to analyze logs from just an hour where I had to restart NetworkManager a few times to get resolution for local test domain working. It seems that there's a kind of "first come, first served" between the dnsmasq processes started by libvirt and the others started by NetworkManager.

Not to conclude, more for further discussion, here's my interpretation of the journal on my machine (lines are in reverse order):

Part 1: after NM[81096] started it's "instance" of dnsmasq[81091], this dnsmasq is claiming to use libvirt-DNS for the configured local domains. However, after that claim, there's a entry from libvirt's instance of dnsmasq[1502], claiming to use only locally known addresses. After this attempt restarting NM, name resolution for domain jio.test didn't work.

Okt 28 08:56:59 archie dnsmasq[1502]: using only locally-known addresses for jio.test
Okt 28 08:56:59 archie dnsmasq[1502]: using nameserver 127.0.0.1#53
Okt 28 08:56:59 archie dnsmasq[1502]: reading /etc/resolv.conf
Okt 28 08:56:59 archie dnsmasq[81091]: cleared cache
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 3.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 2.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 1.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 0.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver fd00::9a9b:cbff:fe92:de8f#53(via br0)
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53 for domain 178.168.192.in-addr.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53 for domain fritz.box
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53(via br0)
Okt 28 08:56:59 archie dnsmasq[81091]: setting upstream servers from DBus
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.8316] policy: set 'bridge-br0' (br0) as default for IPv6 routing and DNS
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.8309] dhcp6 (br0): activation: beginning transaction (timeout in 45 seconds)
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7293] manager: NetworkManager state is now CONNECTED_GLOBAL
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7090] device (br0): Activation: successful, device activated.
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7086] manager: NetworkManager state is now CONNECTED_SITE
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7083] device (br0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7081] device (br0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie dnsmasq[81091]: cleared cache
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53 for domain 178.168.192.in-addr.arpa
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53 for domain fritz.box
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.178.1#53(via br0)
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.125.1#53 for domain ansible.test
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.122.1#53 for domain jio.test
Okt 28 08:56:59 archie dnsmasq[81091]: setting upstream servers from DBus
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7065] device (br0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie dnsmasq[81091]: cleared cache
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.125.1#53 for domain ansible.test
Okt 28 08:56:59 archie dnsmasq[81091]: using nameserver 192.168.122.1#53 for domain jio.test
Okt 28 08:56:59 archie dnsmasq[81091]: DBus support enabled: connected to system bus
Okt 28 08:56:59 archie dnsmasq[81091]: chown of PID file /var/run/NetworkManager/dnsmasq.pid failed: Operation not permitted
Okt 28 08:56:59 archie dnsmasq[81091]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Okt 28 08:56:59 archie dnsmasq[81091]: started, version 2.87 cachesize 400
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.7000] dnsmasq: starting /usr/bin/dnsmasq
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6859] device (vnet0): Activation: successful, device activated.
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6854] device (vnet0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6851] device (eno1): Activation: successful, device activated.
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6845] device (eno1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6840] device (virbr0): Activation: successful, device activated.
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6837] manager: NetworkManager state is now CONNECTED_LOCAL
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6834] device (virbr0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6831] device (vnet0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6830] device (eno1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:56:59 archie NetworkManager[81069]: <info>  [1666940219.6828] device (virbr0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
Okt 28 08:56:59 archie dnsmasq[1502]: using only locally-known addresses for jio.test
Okt 28 08:56:59 archie dnsmasq[1502]: using nameserver 127.0.0.1#53
Okt 28 08:56:59 archie dnsmasq[1502]: reading /etc/resolv.conf

Part 2: it's more or less the same thing, but this time the NM-started instance of dnsmasq[81161] is claiming nameserver usage (and cache clearance) *after* the dnsmsaq-instance from libvirt [1502]. After that restart of NM name resolution is working as expected:

Okt 28 08:57:09 archie systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Okt 28 08:57:08 archie NetworkManager[81136]: <info>  [1666940228.7244] manager: startup complete
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8621] manager: NetworkManager state is now CONNECTED_GLOBAL
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8477] device (br0): Activation: successful, device activated.
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8476] manager: NetworkManager state is now CONNECTED_SITE
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8473] device (br0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8472] device (br0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie dnsmasq[81161]: cleared cache
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 3.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 2.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 1.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8459] device (br0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53 for domain 0.0.6.c.f.3.3.1.a.0.1.8.2.0.a.2.ip6.arpa
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver fd00::9a9b:cbff:fe92:de8f#53(via br0)
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.178.1#53 for domain 178.168.192.in-addr.arpa
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.178.1#53 for domain fritz.box
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.178.1#53(via br0)
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.125.1#53 for domain ansible.test
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.122.1#53 for domain jio.test
Okt 28 08:57:02 archie dnsmasq[81161]: setting upstream servers from DBus
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8444] dhcp6 (br0): state changed new lease
Okt 28 08:57:02 archie dnsmasq[1502]: using only locally-known addresses for jio.test
Okt 28 08:57:02 archie dnsmasq[1502]: using nameserver 127.0.0.1#53
Okt 28 08:57:02 archie dnsmasq[1502]: reading /etc/resolv.conf
Okt 28 08:57:02 archie dnsmasq[81161]: cleared cache
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.125.1#53 for domain ansible.test
Okt 28 08:57:02 archie dnsmasq[81161]: using nameserver 192.168.122.1#53 for domain jio.test
Okt 28 08:57:02 archie dnsmasq[81161]: DBus support enabled: connected to system bus
Okt 28 08:57:02 archie dnsmasq[81161]: chown of PID file /var/run/NetworkManager/dnsmasq.pid failed: Operation not permitted
Okt 28 08:57:02 archie dnsmasq[81161]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Okt 28 08:57:02 archie dnsmasq[81161]: started, version 2.87 cachesize 400
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8300] policy: set 'bridge-br0' (br0) as default for IPv6 routing and DNS
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8297] dhcp6 (br0): activation: beginning transaction (timeout in 45 seconds)
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8240] dnsmasq: starting /usr/bin/dnsmasq
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8091] device (vnet0): Activation: successful, device activated.
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8088] device (vnet0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8086] device (eno1): Activation: successful, device activated.
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8082] device (eno1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8078] device (virbr0): Activation: successful, device activated.
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8076] manager: NetworkManager state is now CONNECTED_LOCAL
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8074] device (virbr0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8072] device (vnet0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8071] device (eno1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Okt 28 08:57:02 archie NetworkManager[81136]: <info>  [1666940222.8069] device (virbr0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
Okt 28 08:57:02 archie dnsmasq[1502]: using only locally-known addresses for jio.test
Okt 28 08:57:02 archie dnsmasq[1502]: using nameserver 127.0.0.1#53
Okt 28 08:57:02 archie dnsmasq[1502]: reading /etc/resolv.conf
Okt 28 08:57:02 archie dbus-daemon[1345]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
Okt 28 08:57:02 archie dbus-daemon[1345]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.223' (uid=0 pid=81136 comm="/usr/bin/NetworkManager --no-daemon")
Okt 28 08:57:02 archie dnsmasq[81091]: exiting on receipt of SIGTERM

Just to show that dnsmasq[1502] belongs to libvirt:

sgoericke ~ $ ps 1502
    PID TTY      STAT   TIME COMMAND
   1502 ?        S      0:00 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper

So, maybe it's just a kind of ordering problem?

rene · 2022-10-28 08:14:06

seth wrote:

Ie. the version test on the VM is irrelevant

Obviously not; it shows the version of dnsmasq to not be (by itself; see below) relevant. Also as mentioned, there's no long dnsmasq startup here; it's done in a second or so; the issue you linked is something different at least as to specifics.

And that said I tried downgrading to dnsmasq-2.86-2 anyway due to harmathy reporting success above -- and that does in fact here work also. So 2.86-2 and 2.87-1 work on the guest here, 2.86-2 on the host, 2.87-1 not on the host. Would still be expecting a timing issue, but then seemingly specifically in combination with 2.87-1. OP may supposedly want to file this as a bug against dnsmasq (possibly linking to the long-startup one as possibly related, but noting that long dnsmasq startup is not by itself the issue for him/us/me).

[EDIT] By the way, to sgoericke: if you also want to try, you can easily grab 2.86-2 from https://archive.archlinux.org/packages/ … kg.tar.zst

Last edited by rene (2022-10-28 08:18:53)

sgoericke · 2022-10-28 09:00:50

rene wrote:

[EDIT] By the way, to sgoericke: if you also want to try, you can easily grab 2.86-2 from https://archive.archlinux.org/packages/ … kg.tar.zst

Just downgraded (had the package still in cache) and made a quick check, version 2.86-2 seems to work as expected.

rene · 2022-10-28 09:13:54

I'll take it then as confirmed that our server= bug was introduced in 2.87 (and is unequal to the long startup one, which was/is a problem in 2.86) -- although it's not always present in 2.87 as per my success with it on my Manjaro Cinnamon VM.

harmathy: if you'd care to file a bug against dnsmasq-2.87 you can supposedly link to this thread; the opennic.conf thing I described in #5 is a convenient reproducer.

harmathy · 2022-10-28 17:31:22

I searched through the dnsmasq mailing list, and there is a thread, which is about the same issue: https://www.mail-archive.com/dnsmasq-di … 16457.html

The problem is already fixed and the patch is quite short:

diff --git a/src/domain-match.c b/src/domain-match.c
index f7db0fe..76a1109 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -683,7 +683,9 @@ int add_update_server(int flags,
 		  serv->next = NULL;
 		}
 	      break;
-	    }	
+	    }
+	  else
+	    up = &serv->next;
 	}
 
       if (serv)

I tested the patch on the dnsmasq package and it solves this problem for me.

harmathy · 2022-10-28 17:56:15

I filed a bug report for the package: https://bugs.archlinux.org/task/76332

Who knows how long it will take until 2.88 gets released and the release lands in archlinux.

Last edited by harmathy (2022-10-29 13:05:18)

rene · 2022-10-28 20:10:57

Great investigating, thanks.

Sort of interesting; I left Arch 8 years ago due to constant "rolling" breakage of this same type and then experienced it immediately again on the very first day of returning (well, to Manjaro). Let us see...

sgoericke · 2022-10-28 20:43:19

Thanks also from my end for further investigation and creating the bug-ticket.

Arch Linux

#1 2022-10-25 12:09:36

[SOLVED] Networkmanager with dnsmasq fails to resolve

#2 2022-10-27 17:30:04

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#3 2022-10-27 17:53:02

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#4 2022-10-27 20:49:56

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#5 2022-10-27 23:48:23

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#6 2022-10-28 07:01:49

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#7 2022-10-28 07:22:17

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#8 2022-10-28 08:11:41

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#9 2022-10-28 08:14:06

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#10 2022-10-28 09:00:50

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#11 2022-10-28 09:13:54

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#12 2022-10-28 17:31:22

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#13 2022-10-28 17:56:15

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#14 2022-10-28 20:10:57

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

#15 2022-10-28 20:43:19

Re: [SOLVED] Networkmanager with dnsmasq fails to resolve

Board footer