LXD tries to not activate/start on boot but juju's machine service seems to trigger it for no apparent reason.
1) create a brand new machine (MAAS controlled VM in my case):
ubuntu@cloud-ctrl01:~$ juju add-machine
created machine 210
2) check if lxd is active:
ubuntu@cloud-ctrl01:~$ juju ssh 210
...
ubuntu@cloud-vm01:~$ systemctl is-active snap.lxd.daemon.service
active
3) stop lxd and juju's machine service:
ubuntu@cloud-vm01:~$ sudo systemctl stop snap.lxd.daemon.service jujud-machine-210.service
Warning: Stopping snap.lxd.daemon.service, but it can still be activated by:
snap.lxd.daemon.unix.socket
4) confirm lxd is inactive:
ubuntu@cloud-vm01:~$ systemctl is-active snap.lxd.daemon.service
inactive
5) start juju's machine service:
ubuntu@cloud-vm01:~$ sudo systemctl start jujud-machine-210.service
ubuntu@cloud-vm01:~$ sleep 10
6) confirm lxd was activated (for no apparent reason):
ubuntu@cloud-vm01:~$ systemctl is-active snap.lxd.daemon.service
active
Additional information:
ubuntu@cloud-vm01:~$ /var/lib/juju/tools/machine-210/jujud version
2.9.5-ubuntu-amd64
ubuntu@cloud-vm01:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
ubuntu@cloud-ctrl01:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
test overlord maas/default 2.9.5 unsupported 16:27:57Z
Machine State DNS Inst id Series AZ Message
210 started 2001:470:b0f8:1016:0:1:0:3 cloud-vm01 focal default Deployed
ubuntu@cloud-ctrl01:~$ snap info juju
name: juju
summary: A model-driven operator lifecycle manager
publisher: Canonical✓
store-url: https://snapcraft.io/juju
contact: https://canonical.com/
license: unset
description: |
Kubernetes operators capture application domain knowledge into reusable code that drives the
operations of the application. Juju offers model-driven operators, and extends the idea of
operators beyond Kubernetes to traditional machine environments, for multi cloud and hybrid cloud
application management.
**What is an operator lifecycle manager?**
Kubernetes operators are containers with operations code, that drive your applications on K8s.
Juju is an operator lifecycle manager that manages the installation, integration and configuration
of operators on the cluster. Juju also extends the idea of operators to traditional application
management on Linux and Windows servers, or cloud instances.
**Model-driven operations and integration**
Organise your operators into models, which group together applications that can be tightly
integrated on the same substrate and operated by the same team. Capture resource allocation,
storage, networking and integration information in the model to simplify ongoing operations.
**Better day-2 operations**
Each operator code package, called a charm, declares methods for actions like back, restore, or
security audit. Calling these methods provides remote administration of the application with no
low-level access required.
**Learn more**
- https://juju.is/
- https://juju.is/mission
- https://charmhub.io/about
- https://discourse.charmhub.io/
- https://github.com/juju/juju
commands:
- juju
services:
juju.fetch-oci: oneshot, disabled, inactive
snap-id: e2CPHpB1fUxcKtCyJTsm5t3hN9axJ0yj
tracking: latest/stable
refresh-date: 7 days ago, at 12:07 UTC
channels:
latest/stable: 2.9.5 2021-06-23 (16559) 99MB classic
latest/candidate: 2.9.7 2021-06-30 (16676) 103MB classic
latest/beta: ↑
latest/edge: 3.0-beta1-4e02504 2021-06-30 (16684) 90MB classic
2.9/stable: 2.9.5 2021-06-23 (16559) 99MB classic
2.9/candidate: 2.9.7 2021-06-30 (16676) 103MB classic
2.9/beta: ↑
2.9/edge: 2.9.8-ed5723d 2021-06-30 (16688) 103MB classic
2.8/stable: 2.8.11 2021-06-10 (16475) 74MB classic
2.8/candidate: ↑
2.8/beta: ↑
2.8/edge: 2.8.12-c973d15 2021-06-25 (16640) 74MB classic
2.7/stable: 2.7.8 2020-07-22 (13563) 77MB classic
2.7/candidate: ↑
2.7/beta: ↑
2.7/edge: 2.7.9+2.7-46f947e 2020-07-22 (13578) 82MB classic
2.6/stable: 2.6.10 2019-10-30 (9484) 69MB classic
2.6/candidate: ↑
2.6/beta: ↑
2.6/edge: 2.6.11+2.6-b96e122 2020-01-22 (10408) 75MB classic
2.5/stable: 2.5.8 2019-06-27 (8361) 67MB classic
2.5/candidate: ↑
2.5/beta: ↑
2.5/edge: 2.5.9+2.5-36af233 2019-07-24 (8546) 73MB classic
2.4/stable: 2.4.7 2019-05-23 (6012) 58MB classic
2.4/candidate: ↑
2.4/beta: ↑
2.4/edge: ↑
2.3/stable: 2.3.9 2018-09-19 (5267) 55MB classic
2.3/candidate: ↑
2.3/beta: ↑
2.3/edge: 2.3.10+2.3-41313d1 2019-03-25 (7080) 55MB classic
installed: 2.9.5 (16559) 99MB classic
ubuntu@cloud-ctrl01:~$ juju version
2.9.5-ubuntu-amd64
ubuntu@cloud-ctrl01:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
The juju machine agent sets up a worker goroutine ready to provision any required LXD containers on the host. The initialisation of this worker is what triggers the LXD service to start since Juju sets up a LXD client at that time.
I can't see a reason why this initialisation should not be done lazily when the first LXD container is to be provisioned.