lxdbr0 is recreated after "snap restart --reload lxd" even when it was deleted and there are no instances

[kertor]

Please confirm

• I have searched existing issues to check if an issue already exists for the bug I encountered.

Distribution

Ubuntu

Distribution version

22

Output of "snap list --all lxd core20 core22 core24 snapd"

snap list --all lxd core20 core22 core24 snapd
Name    Version        Rev    Tracking       Publisher   Notes
core20  20260105       2717   latest/stable  canonical✓  base,disabled
core20  20260211       2769   latest/stable  canonical✓  base
core24  20260211       1499   latest/stable  canonical✓  base
lxd     5.0.6-e49d9f4  38469  latest/stable  canonical✓  disabled,held
lxd     6.7-12e2019    38450  latest/stable  canonical✓  held
snapd   2.73           25935  latest/stable  canonical✓  snapd,disabled
snapd   2.74.1         26382  latest/stable  canonical✓  snapd

Output of "lxc info" or system info if it fails

Environment:
  LXD: 6.7 (snap)
  OS: Ubuntu 22.04
  Kernel: 6.8
  Storage: zfs
  Clustered: false

Issue description

We are seeing unexpected recreation of lxdbr0 after reloading the LXD snap daemon.

This appears related to an already reported behavior where LXD recreates lxdbr0 and may reattach the default profile to it on restart: #11906

Environment:

• LXD installed from snap
• Reproduced on multiple hosts
• Also reproducible on a host with no instances at all

What we observed:

• lxdbr0 can be removed successfully with lxc network delete lxdbr0
• after removal, the interface disappears from both ip a and lxc network list
• a full host reboot does not recreate lxdbr0
• however, snap restart --reload lxd recreates lxdbr0 immediately
• this also happens on a host with no instances, which suggests the bridge recreation is triggered by daemon reload itself rather than by instance/network usage

Expected behavior:

• if lxdbr0 was explicitly deleted, it should stay deleted unless it is explicitly recreated by the user

Actual behavior:

• snap restart --reload lxd automatically recreates lxdbr0

Steps to reproduce

1. Start with a host running LXD from snap.
2. Make sure lxdbr0 exists:

ip a | grep lxdbr0
lxc network list

3. If the default profile contains a NIC attached to lxdbr0, remove it:

lxc profile device remove default eth0

4. Delete the managed bridge:

lxc network delete lxdbr0

5. Verify that lxdbr0 is gone:

ip a | grep lxdbr0
lxc network list

6. Reboot the host and verify again that lxdbr0 is still absent.

7. Reload the LXD snap daemon:

snap restart --reload lxd

8. Check interfaces and LXD networks again:

ip a | grep lxdbr0
lxc network list

9. Observe that lxdbr0 is recreated automatically.

Information to attach

• Any relevant kernel output (dmesg)
• Instance log (lxc info NAME --show-log)
• Instance configuration (lxc config show NAME --expanded)
• Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)
• Output of the client with --debug
• Output of the daemon with --debug (or use lxc monitor while reproducing the issue)

[tomponline]

Does it only happen when doing snap restart --reload as opposed to systemctl reload snap.lxd.daemon?

If so this is likely a snapd bug see https://bugs.launchpad.net/snapd/+bug/2028141

[kertor]

@tomponline Hello! Thank you for your quick response.

I tested both commands separately.
Result:

• snap restart --reload lxd recreates lxdbr0
• systemctl reload snap.lxd.daemon does not recreate lxdbr0

[tomponline]

Thanks, would you mind posting on that snapd issue mentioning your current experience (I too linked to this issue from there yesterday).

[simondeziel]

If so this is likely a snapd bug see https://bugs.launchpad.net/snapd/+bug/2028141

This one ^ was about snap restart lxd which I confirmed to be fixed.

The snapd folks suggested to open a new one for the --reload case: https://bugs.launchpad.net/snapd/+bug/2147568