stgraber
commented
6 years ago Not sure what's going on with resolved interacting with dnsmasq but that probably ought to be reported against resolved in Ubuntu.
The other problem is LXD failing to start when the IP address it's supposed to bind isn't available. That's obviously a deal breaker for a LXD daemon that's configured with clustering enabled as without being able to bind and connect to that address, it can't access its database and so would just crash.
I'm going to close this issue as there's nothing actionable for LXD itself, but you could take some of the following actions:
- File a bug against systemd in Ubuntu about that resolution delay when interacting with dnsmasq. It looks like it's likely DNSSEC related and the symptoms match some I've heard of before on some public WiFi environments.
- File a bug against snapd for starting network-enabled snaps before networkd/netplan say the network is ready.
- Don't enable LXD cluster unless you're actually using it. Clustering can be enabled later if you need it and when it's enabled, it absolutely needs the address to be reachable or it won't be able to access the database.
killua-eu
Here the promissed report for @freeekanayaka as discussed in https://github.com/lxc/lxd/issues/4548.
Required information
Issue description
LXD snap fails to start due to networkd (?) problems. restarts itself after a 10 minutes timeout into a working state.
Steps to reproduce
lxc launch ubuntu:18.04 c1etc.Information to attach
here i waited a bit for snap/lxd to catch up. the networkctl status stopped at this:
after waiting 10 minutes (getting the timeout), we continue with
now i get
yaay. this is on a fresh machine (18.04 server install) with just lxd installed as snap. Now if I dare to want to
ping c1.lxd(as I asked in https://github.com/lxc/lxd/issues/4625), I go forlooks fine, but the ping actually waits cca. 3 seconds and then starts to ping. so there seems to be a lag in hostname resolution. this lag comes also with pinging google. you don't see it in the ping time. here some more logs:
and here from the reboot (including the reboot) for lxd snap
here also the full dmesg
example container info
no other logs seem to have anything interesting, but attaching anyway
[edit] Additional fun fact
ability to ping containers disappears after reboot:
looking at the netplan
gives no reason why this fails, but it still does
now the fun part, regenrating and applying netplan does the trick
again with the 3 seconds lag on before
PING c2.lxd (240.102.0.119) 56(84) bytes of data.appears. Can't find anything relevant in any log.