Comment 1 for bug 2028141

Revision history for this message
Thomas Parrott (tomparrott) wrote : Re: Unexpected Creation of lxdbr0 and profile modification on `snap restart lxd`

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.