Error in lxd to setup a node in cluster on Ubuntu 20.04

Trying to setup a lxd cluster on Ubuntu 20.04 and getting an error on the node:

root@ubuntu-s-1vcpu-1gb-sgp1-01:~# lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: yes
What name should be used to identify this node in the cluster? [default=ubuntu-s-1vcpu-1gb-sgp1-01]: ubuntu-s-1vcpu-1gb-sgp1-02
What IP address or DNS name should be used to reach this node? [default=167.99.79.123]: 10.88.8.6
Invalid input: Can't bind address "10.88.8.6:8443": listen tcp 10.88.8.6:8443: bind: address already in use

When I run lxd init first time it already failed so thought by restarting lxd init, it will work. But it seems lxd init start the daemon automatically and bind this address. Is there a way to fix this?

Tried stopping the daemon using:

 snap stop lxd

Also tried

systemctl stop snap.lxd.daemon

None worked and it always give a bind address error.

Ok, so first thing would be to check if the error is right.
Try snap stop lxd, then show:

  • netstat -lnp
  • ps fauxww

That should let us check whether that port is indeed in use somehow and whether there’s any leftover LXD processes that could explain it being used.

I used ss instead of netstat and then after running snap stop lxd it stopped the process. But then when I run lxd init it automatically starts it.

ss -tulnp | grep 8443

tcp   LISTEN 0 4096  10.88.8.6:8443  0.0.0.0:*  users:(("lxd",pid=3681,fd=20))
ls -l /proc/3681/exe
lrwxrwxrwx 1 root root 0 Aug 19 13:59 /proc/3681/exe -> /snap/lxd/16894/bin/lxd
snap stop lxd

ss -tulnp | grep 8443
lxd init

After running lxd init, it again shows the same error as above. The only fix I found which works is:

snap remove lxd
snap install lxd
lxd init

This is weird… Can you show lxc config show and maybe try unsetting those keys before running lxd init?

I’ve seen this too, if the lxd init fails part-way through then it will leave a lxd process listening on that port.

I’ve found I have to clear the config in lxc config edit before running lxd init.

Something I was intending to look at as part of the cluster join clean up we discussed.

Oh, right, we’ve added logic to see if a given address/port is available during init, but this doesn’t consider a pre-existing value.

So we should probably have the test check the current value too.