The description above is a side effect of the apparent behaviour of `snap restart lxd`.
Example:
On a fresh ubuntu:22.04 VM:
```
systemctl | grep snap.lxd
snap-lxd-25112.mount loaded active mounted Mount unit for lxd, revision 25112
snap.lxd.daemon.unix.socket loaded active listening Socket unix for snap application lxd.daemon
snap.lxd.user-daemon.unix.socket loaded active listening Socket unix for snap application lxd.user-daemon
```
Note that the sockets are in a listening state for lxd.daemon and lxd.user-daemon.
Then if we do `snap stop lxd` followed by `snap start lxd` we can see the systemd units are restored to the same state as before (listening).
```
root@v1:~# snap stop lxd
Stopped.
root@v1:~# systemctl | grep snap.lxd
snap-lxd-25112.mount loaded active mounted Mount unit for lxd, revision 25112
```
```
root@v1:~# systemctl | grep snap.lxd
snap-lxd-25112.mount loaded active mounted Mount unit for lxd, revision 25112
root@v1:~# snap start lxd
Started.
root@v1:~# systemctl | grep snap.lxd
snap-lxd-25112.mount loaded active mounted Mount unit for lxd, revision 25112
snap.lxd.daemon.unix.socket loaded active listening Socket unix for snap application lxd.daemon
snap.lxd.user-daemon.unix.socket loaded active listening Socket unix for snap application lxd.user-daemon
```
But if we now do `snap restart lxd` (which to my mind should be equivalent of doing `snap stop lxd` and then`snap start lxd`) we end up with something quite different:
```
root@v1:~# snap restart lxd
Restarted.
root@v1:~# systemctl | grep snap.lxd
snap-lxd-25112.mount loaded active mounted Mount unit for lxd, revision 25112
var-snap-lxd-common-ns-mntns.mount loaded active mounted /var/snap/lxd/common/ns/mntns
var-snap-lxd-common-ns-shmounts.mount loaded active mounted /var/snap/lxd/common/ns/shmounts
var-snap-lxd-common-ns.mount loaded active mounted /var/snap/lxd/common/ns
snap.lxd.daemon.service loaded active running Service for snap application lxd.daemon
snap.lxd.user-daemon.service loaded active running Service for snap application lxd.user-daemon
snap.lxd.workaround.service loaded active exited /bin/true
snap.lxd.daemon.unix.socket loaded active running Socket unix for snap application lxd.daemon
snap.lxd.user-daemon.unix.socket loaded active running Socket unix for snap application lxd.user-daemon
```
We can see that now the inactive units have been started:
```
snap.lxd.daemon.service loaded active running Service for snap application lxd.daemon
snap.lxd.user-daemon.service loaded active running Service for snap application lxd.user-daemon
```
This has a negative effect with LXD because the snap.lxd.user-daemon.service is designed to create LXD managed networks and configure profiles for the user requesting the service on first request to the listening socket.
But no genuine request has actually arrived, only the `snap restart lxd` request, which has started the `snap.lxd.user-daemon.service` service incorrectly (it wasn't previously running) and caused the LXD default profile to be reconfigured and a managed network be created.
The description above is a side effect of the apparent behaviour of `snap restart lxd`.
Example:
On a fresh ubuntu:22.04 VM:
``` lxd-25112. mount loaded active mounted Mount unit for lxd, revision 25112 lxd.daemon. unix.socket loaded active listening Socket unix for snap application lxd.daemon lxd.user- daemon. unix.socket loaded active listening Socket unix for snap application lxd.user-daemon
systemctl | grep snap.lxd
snap-
snap.
snap.
```
Note that the sockets are in a listening state for lxd.daemon and lxd.user-daemon.
Then if we do `snap stop lxd` followed by `snap start lxd` we can see the systemd units are restored to the same state as before (listening).
``` lxd-25112. mount loaded active mounted Mount unit for lxd, revision 25112
root@v1:~# snap stop lxd
Stopped.
root@v1:~# systemctl | grep snap.lxd
snap-
```
``` lxd-25112. mount loaded active mounted Mount unit for lxd, revision 25112 lxd-25112. mount loaded active mounted Mount unit for lxd, revision 25112 lxd.daemon. unix.socket loaded active listening Socket unix for snap application lxd.daemon lxd.user- daemon. unix.socket loaded active listening Socket unix for snap application lxd.user-daemon
root@v1:~# systemctl | grep snap.lxd
snap-
root@v1:~# snap start lxd
Started.
root@v1:~# systemctl | grep snap.lxd
snap-
snap.
snap.
```
But if we now do `snap restart lxd` (which to my mind should be equivalent of doing `snap stop lxd` and then`snap start lxd`) we end up with something quite different:
``` lxd-25112. mount loaded active mounted Mount unit for lxd, revision 25112 lxd-common- ns-mntns. mount loaded active mounted /var/snap/ lxd/common/ ns/mntns lxd-common- ns-shmounts. mount loaded active mounted /var/snap/ lxd/common/ ns/shmounts lxd-common- ns.mount loaded active mounted /var/snap/ lxd/common/ ns lxd.daemon. service loaded active running Service for snap application lxd.daemon lxd.user- daemon. service loaded active running Service for snap application lxd.user-daemon lxd.workaround. service loaded active exited /bin/true lxd.daemon. unix.socket loaded active running Socket unix for snap application lxd.daemon lxd.user- daemon. unix.socket loaded active running Socket unix for snap application lxd.user-daemon
root@v1:~# snap restart lxd
Restarted.
root@v1:~# systemctl | grep snap.lxd
snap-
var-snap-
var-snap-
var-snap-
snap.
snap.
snap.
snap.
snap.
```
We can see that now the inactive units have been started:
``` lxd.daemon. service loaded active running Service for snap application lxd.daemon lxd.user- daemon. service loaded active running Service for snap application lxd.user-daemon
snap.
snap.
```
This has a negative effect with LXD because the snap.lxd. user-daemon. service is designed to create LXD managed networks and configure profiles for the user requesting the service on first request to the listening socket.
But no genuine request has actually arrived, only the `snap restart lxd` request, which has started the `snap.lxd. user-daemon. service` service incorrectly (it wasn't previously running) and caused the LXD default profile to be reconfigured and a managed network be created.