How can I refresh /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases?

LXD
1

When my laptop (Debian 11/testing) wakes up from suspend, I can’t resolve names of my running containers for a while.
If I send a request to dnsmasq directly, e.g.

dig @10.20.42.1 mx1.test

the name is not found.

The problem seems to be:

cat /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases

-> contains only:

duid 00:01:00:01:27:b7:06:de:f0:de:f1:8c:21:dd

If I wait for some minutes(?), and check again, then the leases file is filled again:

cat /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases

->

1615723760 00:16:3e:c8:f6:c0 10.20.42.208 mx1 ff:3e:c8:f6:c0:00:01:00:01:27:d5:ec:5c:00:16:3e:c8:f6:c0
duid 00:01:00:01:27:b7:06:de:f0:de:f1:8c:21:dd

And name resolution works again.

Unfortunately, it’s not easy to reproduce. In preparation of this post, I’ve suspended my laptop. And after wake up, the file still contains the lease.

I’d like to speed up that process, so how can I refresh /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases ?

Next time it happens, I’ll try

systemctl reload snap.lxd.daemon.service

or

lxc exec mx1 -- dhclient -sf /bin/true eth0

as a workaround.

Any hints towards a solution?

Ingo

2

Maybe bumping the lease expiry in your network’s configuration would help?
This is pretty much just handled through dnsmasq and since your containers don’t know the host system just resumed, they don’t know to issue DHCP requests again.

https://linuxcontainers.org/lxd/docs/master/networks#network-bridge

ipv4.dhcp.expiry defaults to 1h, try using 1d this may take care of your issue.

3

Most likely dnsmasq is waking up and noticing that the leases have expired and removing them, and then eventually the container’s own DHCP client notices it needs to refresh its lease and requests a new one.

As @stgraber suggested increasing the DHCP lease time should help avoid this (assuming you don’t suspend longer than the lease time set).