LXD - Failed to start the daemon

mrk · October 29, 2021, 7:25pm

Hi, I am following this Install Charmed Ceph | Ubuntu documentation for deploying a ceph cluster and having some issues to deploy LXD.

I am having an lxd version : 4.19 which is installing on Ubuntu 20.04.

lxd --verbose --debug output:

EROR[10-29|18:46:19] Failed to start the daemon err=“LXD is already running”
INFO[10-29|18:46:19] Starting shutdown sequence signal=interrupt
WARN[10-29|18:46:19] Instance type not operational type=virtual-machine driver=qemu err=“KVM support is missing”
INFO[10-29|18:46:19] Not unmounting temporary filesystems (instances are still running)
INFO[10-29|18:46:19] Daemon stopped
Error: LXD is already running

systemctl -a | grep snap.*lxd output:

lxd11611×866 111 KB

I tried running sudo systemctl reload snap.daemon.lxd to restart LXD demon. but that does’nt help to restart lxd instances.

Any help for this?
Please let me how to resolve this problem.
Thank you.

mrk · November 9, 2021, 2:37pm

Any possible solutions on this issue??

stgraber · November 9, 2021, 2:50pm

What happens when you run lxc info?
And what does journal -u snap.lxd.daemon -n 50 show you?

tomp · November 9, 2021, 2:53pm

Can you show output of sudo ps aux | grep lxd, I wonder if there is a stuck LXD process, possibly related to

github.com/lxc/lxd

Cluster: Fix self-removal of non-leader member from cluster

lxc:master ← tomponline:tp-cluster-remove-member

opened 12:13AM - 05 Nov 21 UTC

tomponline

+110 -26

Fixes #9464 Continues on the work by @masnax in https://github.com/lxc/lxd/pu…ll/9472, but using a slightly different approach that doesn't depend on detecting self-removal using remote request address (which proved to be unreliable in the test environment based on how Linux selected the source address to use). Instead I've changed it to use a lock so that the initial request takes the lock before forward the request to the leader, that way when the leader subsequently requests the local LXD process be replaced/stopped, we don't action that until after the original request has completed.

mrk · November 10, 2021, 4:21pm

Here is the result of lxc info

mrk · November 10, 2021, 4:26pm

Output of sudo ps aux | grep lxd : result

mrk · November 10, 2021, 4:31pm

Thank you @stgraber and @tomp for the response. Much appreciated

tomp · November 10, 2021, 5:26pm

Can you kill process 2015948?

mrk · November 10, 2021, 5:57pm

Yupp, I killed the process 2015948

tomp · November 10, 2021, 5:57pm

Still getting the error?

tomp · November 10, 2021, 5:59pm

I dont know if this is normal or not, but you seem to have 2 LXD snap revision mounts.

mrk · November 10, 2021, 6:00pm

Yes, still have the same error.

mrk · November 10, 2021, 6:03pm

Sir, I don’t know what i missed…I am a complete beginner… how do i remove one of the LXD snap revision mount. dose that work for me?

tomp · November 10, 2021, 6:07pm

I’m not sure about snap packages, @stgraber do those mounts look problematic to you?

stgraber · November 10, 2021, 6:36pm

I’m confused here, the output above for lxc info is all normal looking.
It’s normal for there to be two mounts, snapd keeps the previous revision around.

Unless I missed something, LXD is perfectly functional here, since it’s running, there’s no point in trying to start the daemon a second time by running lxd --verbose --debug.

It looks to me like this system is working perfectly normally and that lxc info shows a healthy LXD and I’d expect lxc list to similarly show a list of instances or none if none have been created so far.