From time to time I’ll be in some container shell and will issue an lxc command, usually “lxc list”, intended for the host OS.
Instead of receiving an error message stating something like : “LXD is not installed. You can install via: sudo snap install lxd” the container instead just immediately installs LXD.
The same thing happens if I mistakenly run “lxc --version” or “lxd --version” inside a container that does not have LXD.
root@lxd-metrics:~# lxc list
Installing LXD snap, please be patient.
Every time that I’ve done this I did not actually want to install LXD in the container. I was just in the wrong spot when I issued the command.
Shouldn’t these commands in this scenario simply report to the user that LXD is not installed along with how to install it? Rather than immediately installing without the user specifically requesting for that action to be taken?
Currently this is intended. Running any lx[cd] command on an Ubuntu system (I can’t recall the exact version this was introduced in) that does not have LXD installed calls /usr/sbin/lx[cd] and triggers lxd-installer, which installs the latest LTS LXD snap and starts snap.lxd.daemon. Removing /usr/sbin/lx[cd] before running any lx[cd] command would result in the behavior you described, but this would not be recommended.
I think this is not necessary per se, just a design choice. Probably to avoid having LXD pre installed on Ubuntu but keeping the UX simple and efficient as if it was.
On a Noble+ image, the snapd deb is installed but there are 0 snaps installed. The snapd deb is the one providing the snap command. Upon snap install’ing the first snap, this will trigger the automatic installation of the snapd snap.
root@c2:~# dpkg -l | grep snapd
ii snapd 2.63+24.04 amd64 Daemon and tooling that enable snap packages
root@c2:~# snap list
No snaps are installed yet. Try 'snap install hello-world'.
root@c2:~# dpkg -S $(command -v snap)
snapd: /usr/bin/snap
root@z-testing:~# snap list
No snaps are installed yet. Try 'snap install hello-world'.
Even after updating via:
apt -y update && apt -y upgrade
snap list still shows:
root@z-testing:~# snap list
No snaps are installed yet. Try 'snap install hello-world'.
Then (“accidental”) lxc list:
root@z-testing:~# lxc list
Installing LXD snap, please be patient.
If this is your first time running LXD on this machine, you should also run: lxd init
To start your first container, try: lxc launch ubuntu:24.04
Or for a virtual machine: lxc launch ubuntu:24.04 --vm
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
root@z-testing:~#
And then snap list again:
root@z-testing:~# snap list
Name Version Rev Tracking Publisher Notes
core22 20240419 1439 latest/stable canonical✓ base
lxd 5.21.2-34459c8 29568 5.21/stable/… canonical✓ -
snapd 2.63 21759 latest/stable canonical✓ snapd
snapd does seem to be installed by default, at least in u24.04 containers.
So as a test, right after a fresh u24 install, in that new container I ran:
apt autoremove --purge snapd
apt-mark hold snapd
Then after that:
root@snap-test:~# lxc list
Installing LXD snap, please be patient.
Traceback (most recent call last):
File “”, line 1, in
ConnectionResetError: [Errno 104] Connection reset by peer
/usr/sbin/lxc: 18: exec: /snap/bin/lxc: not found
root@snap-test:~#
That doesn’t seem to be an ideal solution, but I suppose good enough to prevent lxc installing in containers when I never intended to install it. But no good if I needed snap for something else in that container.
Not really sure any of this really matters. I guess what annoys me in a way about it is that I already have LXD installed in the host OS. Then when I accidentally do “lxc list” in containers, over time, I end up with a bunch of containers also running lxd. So, basically, nested lxd, or lxd with a bunch of containers also unnecessarily running lxd.
@john2k if all you want to do is prevent an accidental lxc XYZ trigger an on-demand installation of LXD inside a container, you can more simply apt-get autoremove -y --purge lxd-installer or chmod -x /usr/sbin/lxc /usr/sbin/lxd in the container.
That’s only for the time being before I can get the lxd-installer package fixed to prompt before installation, of course.