LXD daemon on 6/stable no longer starting

Hello, I noticed that my lxd snap tracking 6/stable on my machine has a more recent version than the 6/stable on the store:

» snap info lxd
name:      lxd
[...]
services:
  lxd.activate:    oneshot, disabled, inactive
  lxd.daemon:      simple, enabled, inactive
  lxd.user-daemon: simple, enabled, inactive
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     6/stable
refresh-date: yesterday at 10:09 CET
channels:
  5.21/stable:      5.21.4-8caf727 2026-02-26 (37923) 123MB -
  [...]
  latest/stable:    6.6-0e82f2b    2026-02-11 (37560) 119MB -
  [...]
  6/stable:         6.6-0e82f2b    2026-02-09 (37560) 119MB -
  6/candidate:      6.7-395c809    2026-03-03 (38212) 120MB -
  6/beta:           ↑
  6/edge:           git-772ec7d    2026-03-04 (38274) 120MB -
  5.0/stable:       5.0.6-ea8012a  2026-02-26 (37982)  96MB -
  [...]
installed:          6.7-1f11451               (38142) 120MB -

Was the 6/stable channel “reverted” recently?

I am asking since my lxd.daemon is no longer running:

» sudo snap logs -f lxd.daemon
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Scheduled restart job, restart counter is at 4.
2026-03-04T14:24:05+01:00 systemd[1]: Started snap.lxd.daemon.service - Service for snap application lxd.daemon.
2026-03-04T14:24:05+01:00 lxd.daemon[416918]: INFO: the gpu-2404 interface is connected. Running with gpu-2404 wrapper.
2026-03-04T14:24:05+01:00 lxd.daemon[416918]: /snap/lxd/38142/bin/gpu-2404-custom-wrapper: 8: exec: /snap/lxd/38142/gpu-2404/bin/gpu-2404-provider-wrapper: not found
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Main process exited, code=exited, status=127/n/a
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Failed with result 'exit-code'.
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Scheduled restart job, restart counter is at 5.
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Start request repeated too quickly.
2026-03-04T14:24:05+01:00 systemd[1]: snap.lxd.daemon.service: Failed with result 'exit-code'.
2026-03-04T14:24:05+01:00 systemd[1]: Failed to start snap.lxd.daemon.service - Service for snap application lxd.daemon.

Did something break recently or am I missing something?

Thank you.

No most likely you’re affected by this old snapd bug:

Do you have the gpu-2404 interface connected?

» snap connections lxd                                                  130 ↵
Interface          Plug                  Slot                Notes
content            lxd:ceph-conf         -                   -
content[gpu-2404]  lxd:gpu-2404          mesa-2404:gpu-2404  -
content            lxd:ovn-certificates  -                   -
content            lxd:ovn-chassis       -                   -
content            lxd:qemu-external     -                   -
lxd                multipass:lxd         lxd:lxd             -
lxd-support        lxd:lxd-support       :lxd-support        -
network            lxd:network           :network            -
network-bind       lxd:network-bind      :network-bind       -
system-observe     lxd:system-observe    :system-observe     -

Yes it looks connected.

» snap info mesa-2404                                                   130 ↵
name:      mesa-2404
summary:   Mesa libraries for core24 snaps
publisher: Canonical✓
store-url: https://snapcraft.io/mesa-2404
contact:   https://github.com/canonical/mesa-2404
license:   MIT
description: |
  A content snap containing the mesa libraries and drivers for `base: core24` snaps.

  It supports a broad range of hardware through the Mesa stack as well as Nvidia
  drivers installed from your distribution through the native SnapD support.

  To make use of this snap in your application, allowing for GPU acceleration on
  a broader set of hardware without including the drivers in your snap, refer to the
  documentation below:

  https://mir-server.io/docs/the-gpu-2404-snap-interface

  _Note: On some, typically desktop, systems SnapD supports loading Nvidia drivers installed on the
  host. mesa-2404 is compatible with this._
services:
  mesa-2404.component-monitor: simple, disabled, inactive
snap-id:      HyhSEBPv3vHsW6uOHkQR384NgI7S6zpj
tracking:     latest/stable
refresh-date: 14 days ago, at 11:44 CET
channels:
  latest/stable:    25.0.7-snap211 2025-11-05 (1165) 414MB -
  latest/candidate: 25.2.8-snap237 2026-02-13 (1431) 421MB -
  latest/beta:      25.2.8-snap251 2026-02-28 (1516) 421MB -
  latest/edge:      25.2.8-snap251 2026-02-28 (1512) 421MB -
installed:          25.0.7-snap211            (1165) 414MB -

Try disconnecting it and see if it starts.

LXD snap is expecting the wrapper script to be provided by the connected snap

Disconnected and reconnected and while the issue is solved now it’s complaining about a file already being present:

» sudo snap run lxd.daemon
INFO: the gpu-2404 interface is connected. Running with gpu-2404 wrapper.
=> Preparing the system (38142)
==> Loading snap configuration
==> Setting up mntns symlink (mnt:[4026533942])
==> Setting up kmod wrapper
==> Preparing /boot
==> Preparing a clean copy of /run
==> Preparing /run/bin
==> Preparing a clean copy of /etc
==> Preparing a clean copy of /usr/share/misc
==> Setting up ceph configuration
==> Setting up LVM configuration
==> Setting up OVN configuration
==> Rotating logs
==> Setting up ZFS (2.3)
==> Escaping the systemd cgroups
====> Detected cgroup V2
==> Escaping the systemd process resource limits
==> Enabling LXD UI
==> Exposing LXD documentation
mkdir: cannot create directory ‘/var/snap/lxd/common/var/lib/lxcfs’: File exists

@gbeuzeboc for this last mkdir error, would you mind running the daemon.start script with set -x?

$ sudo -i
# snap stop lxd
# cp /snap/lxd/current/commands/daemon.start .
# sed -i '2 i set -x' daemon.start
# mount -o ro,bind daemon.start /snap/lxd/current/commands/daemon.start
# snap start lxd

Starting failed so I used `run` to see more logs:

root~# snap start lxd
error: cannot perform the following tasks:
- Run service command "start" for services ["activate" "daemon" "user-daemon"] of snap "lxd" (systemctl command [start snap.lxd.activate.service] failed with exit status 1: stderr:
Job for snap.lxd.activate.service failed because the control process exited with error code.
See "systemctl status snap.lxd.activate.service" and "journalctl -xeu snap.lxd.activate.service" for details.)

root~# journctl ....
Mar 04 16:00:28 framework-13 systemd[1]: Starting snap.lxd.activate.service - Service for snap application lxd.activate...
░░ Subject: A start job for unit snap.lxd.activate.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit snap.lxd.activate.service has begun execution.
░░
░░ The job identifier is 25768.
Mar 04 16:00:28 framework-13 lxd.activate[518631]: => Starting LXD activation
Mar 04 16:00:28 framework-13 lxd.activate[518631]: ==> Loading snap configuration
Mar 04 16:00:28 framework-13 lxd.activate[518631]: ==> Checking for socket activation support
Mar 04 16:00:28 framework-13 lxd.activate[518631]: ==> Setting LXD socket ownership
Mar 04 16:00:28 framework-13 lxd.activate[518631]: ==> Setting LXD user socket ownership
Mar 04 16:00:28 framework-13 lxd.activate[518631]: ==> Checking if LXD needs to be activated
Mar 04 16:00:30 framework-13 lxd.activate[518676]: Error: Get "http://unix.socket/": read unix @->/var/snap/lxd/common/lxd/unix.socket: read: connection reset>
Mar 04 16:00:30 framework-13 lxd.activate[518631]: ====> Activation check failed, forcing activation
Mar 04 16:00:30 framework-13 systemctl[519451]: Job for snap.lxd.daemon.service failed because the control process exited with error code.
Mar 04 16:00:30 framework-13 systemctl[519451]: See "systemctl status snap.lxd.daemon.service" and "journalctl -xeu snap.lxd.daemon.service" for details.
Mar 04 16:00:30 framework-13 systemd[1]: snap.lxd.activate.service: Main process exited, code=exited, status=1/FAILURE


root@framework-13:~# journalctl -xeu snap.lxd.daemon.service
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + rm /var/lib/snapd/hostfs/run/sysctl.d/zz-lxd.conf.631Ocy
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + return 0
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ -d /snap/lxd/current/share/lxd-ui/ ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + echo ==> Enabling LXD UI
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: ==> Enabling LXD UI
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + export LXD_UI=/snap/lxd/current/share/lxd-ui/
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + echo ==> Exposing LXD documentation
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: ==> Exposing LXD documentation
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + export LXD_DOCUMENTATION=/snap/lxd/current/share/lxd-documentation
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + mkdir -p /var/snap/lxd/common/lxc
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ -d /sys/kernel/security/apparmor ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + grep -qF -- -Ubuntu /proc/version
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + true
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ false = true ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ -d /var/snap/lxd/38142/microovn/chassis/switch ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ -d /var/snap/microovn/ ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + ln -s /var/lib/snapd/hostfs/run/openvswitch /run/openvswitch
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + [ -e /var/snap/lxd/common/var/lib/lxcfs/cgroup ]
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + umount -l /var/snap/lxd/common/var/lib/lxcfs
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + true
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + fusermount -u /var/snap/lxd/common/var/lib/lxcfs
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + true
Mar 04 16:00:30 framework-13 lxd.daemon[519299]: + mkdir -p /var/snap/lxd/common/var/lib/lxcfs
Mar 04 16:00:30 framework-13 lxd.daemon[519448]: mkdir: cannot create directory ‘/var/snap/lxd/common/var/lib/lxcfs’: File exists
Mar 04 16:00:30 framework-13 systemd[1]: snap.lxd.daemon.service: Main process exited, code=exited, status=1/FAILURE


root~# snap run lxd
WARNING[2026-03-04T16:00:34+01:00]  - Couldn't find the CGroup hugetlb controller, hugepage limits will be ignored
ERROR  [2026-03-04T16:00:34+01:00] Unable to run feature checks during QEMU initialization: Unable to locate a VM UEFI firmware
WARNING[2026-03-04T16:00:34+01:00] Instance type not operational                 driver=qemu err="QEMU failed to run feature checks" type=virtual-machine
ERROR  [2026-03-04T16:00:34+01:00] Failed starting daemon                        err="Failed to start dqlite server: couldn't lock the raft directory"
Error: Failed to start dqlite server: couldn't lock the raft directory

I’m not sure you can use that style of invocation.

Can you try

sudo snap restart lxd

Do you think manually removing `/var/snap/lxd/common/var/lib/lxcfs` is safe?

Do you have running containers?

I wonder if an existing container is holding on to it?

Is there lxcfs process still running?

I am pretty sure I had containers & VM running. But I cannot check since I cannot use the socket.

I see no lxcfs process running on my host (no lxd nor lxc process running either).

I would say its safe to delete then. As LXD would normally create it on start up anyway:

removed the file but then, lxd.daemon was not starting (not even generating a single log) when calling sudo snap start lxd.daemon.
I ran

INFO: the gpu-2404 interface is connected. Running with gpu-2404 wrapper.
=> Preparing the system (38142)
==> Loading snap configuration
==> Setting up mntns symlink (mnt:[4026532786])
==> Setting up mount propagation on /var/snap/lxd/common/lxd/storage-pools
==> Setting up mount propagation on /var/snap/lxd/common/lxd/devices
==> Setting up persistent shmounts path
====> Making LXD shmounts use the persistent path
====> Making LXCFS use the persistent path
==> Setting up kmod wrapper
==> Preparing /boot
==> Preparing a clean copy of /run
==> Preparing /run/bin
==> Preparing a clean copy of /etc
==> Preparing a clean copy of /usr/share/misc
==> Setting up ceph configuration
==> Setting up LVM configuration
==> Setting up OVN configuration
==> Rotating logs
==> Setting up ZFS (2.3)
==> Escaping the systemd cgroups
====> Detected cgroup V2
==> Escaping the systemd process resource limits
==> Increasing the number of inotify user instances
==> Increasing the number of inotify user watches
==> Increasing the number of keys for a nonroot user
==> Increasing the number of bytes for a nonroot user
==> Disabling Apparmor unprivileged userns mediation
kernel.apparmor_restrict_unprivileged_userns = 0
==> Enabling LXD UI
==> Exposing LXD documentation
=> Starting LXCFS
Starting LXCFS at lxcfs
Ignoring invalid max threads value 4294967295 > max (100000).
Using runtime path /run
Running lxcfslib_init to reload liblxcfs
mount namespace: 7
hierarchies:
0: fd: 8: cpuset,cpu,io,memory,hugetlb,pids,rdma,misc,dmem
Kernel supports pidfds
Kernel supports swap accounting
api_extensions:

-cgroups
-sys_cpu_online
-proc_cpuinfo
-proc_diskstats
-proc_loadavg
-proc_meminfo
-proc_stat
-proc_swaps
-proc_uptime
-proc_slabinfo
-shared_pidns
-cpuview_daemon
-loadavg_daemon
-pidfds=> Starting LXDRunning destructor lxcfs_exitKilled=> LXD failed to start

And then the lxd.daemon was somehow running.

Everything works fine now.

I ran

I couldn’t see what command you ran, just the log output.

Sorry (struggled with the formating) I ran `sudo snap run lxd.daemon`.

1 Like

Perhaps it had been restarting so much that systemd stopped restarting the unit on failure.