| 2023-07-19 09:44:05 |
Gabriel Mougard |
description |
Description:
An unintended behavior in the `snap restart lxd` command has been observed, resulting in the undesired creation of an `lxdbr0` interface and a modification to the default profile. This issue arises even when a different existing bridge is specified during `lxd init`. The precise steps to reproduce the problem are as follows:
1. Install LXD using `snap install lxd`.
2. Run `lxd init` and specify an existing bridge (i.e., `lxdbr1`) instead of creating a new one.
3. Confirm there is no `lxdbr0` using `lxc network list` and check that the default profile is configured as intended using `lxc profile show default`.
4. Restart LXD using `snap restart lxd`.
5.Run `lxc network list` and `lxc profile show default` again. At this point, a `lxdbr0` interface exists, and the default profile has been altered to use it.
It is important to note that this issue is not triggered when using the alternative commands `snap stop lxd` followed by `snap start lxd`, nor when using `sudo systemctl reload snap.lxd.daemon`. It appears to be specific to `snap restart lxd`, suggesting a potential bug within the `snap restart` command itself.
As mentioned in the original gh discussion thread, the problem seems related to the `snap restart` command starting sub-units, like the `lxd-user` process, even if they weren't previously running. The undesired side-effect of this behavior is an API request being sent to LXD upon `snap restart lxd` which creates the `lxdbr0` network, even if this is not desired or requested by the user.
A current workaround for this issue is to have an interface named `lxdbr0` present, either by leaving the unwanted one that LXD creates, or by naming an unmanaged interface as `lxdbr0`. Without this, the `snap restart lxd` command will create `lxdbr0` and change the default profile.
---
Here is the link to the github thread of the original issue : https://github.com/canonical/lxd/issues/11906
Thanks |
An unintended behavior in the `snap restart lxd` command has been observed, resulting in the undesired creation of an `lxdbr0` interface and a modification to the default profile. This issue arises even when a different existing bridge is specified during `lxd init`. The precise steps to reproduce the problem are as follows:
1. Install LXD using `snap install lxd`.
2. Run `lxd init` and specify an existing bridge (i.e., `lxdbr1`) instead of creating a new one.
3. Confirm there is no `lxdbr0` using `lxc network list` and check that the default profile is configured as intended using `lxc profile show default`.
4. Restart LXD using `snap restart lxd`.
5.Run `lxc network list` and `lxc profile show default` again. At this point, a `lxdbr0` interface exists, and the default profile has been altered to use it.
It is important to note that this issue is not triggered when using the alternative commands `snap stop lxd` followed by `snap start lxd`, nor when using `sudo systemctl reload snap.lxd.daemon`. It appears to be specific to `snap restart lxd`, suggesting a potential bug within the `snap restart` command itself.
As mentioned in the original gh discussion thread, the problem seems related to the `snap restart` command starting sub-units, like the `lxd-user` process, even if they weren't previously running. The undesired side-effect of this behavior is an API request being sent to LXD upon `snap restart lxd` which creates the `lxdbr0` network, even if this is not desired or requested by the user.
A current workaround for this issue is to have an interface named `lxdbr0` present, either by leaving the unwanted one that LXD creates, or by naming an unmanaged interface as `lxdbr0`. Without this, the `snap restart lxd` command will create `lxdbr0` and change the default profile.
---
Here is the link to the github thread of the original issue : https://github.com/canonical/lxd/issues/11906
Thanks |
|
