Container runtime environment#
LXD attempts to present a consistent environment to the container it runs.
The exact environment will differ slightly based on kernel features and user configuration but will otherwise be identical for all containers.
LXD spawns whatever is located at
/sbin/init as the initial process of the container (PID 1).
This binary should act as a proper init system, including handling re-parented processes.
LXD’s communication with PID1 in the container is limited to two signals:
SIGINTto trigger a reboot of the container
SIGRTMIN+3) to trigger a clean shutdown of the container
The initial environment of PID1 is blank except for
container=lxc which can
be used by the init system to detect the runtime.
All file descriptors above the default 3 are closed prior to PID1 being spawned.
LXD assumes that any image it uses to create a new container from will come with at least:
LXD containers have a minimal and ephemeral
/dev based on a
tmpfs file system.
Since this is a
tmpfs and not a
devtmpfs, device nodes will only appear if manually created.
The standard set of device nodes will be set up:
On top of the standard set of devices, the following are also set up for convenience:
The following mounts are set up by default under LXD:
cgroupfs) (only on kernels lacking cgroup namespace support)
The following paths will also be automatically mounted if present on the host:
The reason for passing all of those is legacy init systems which require those to be mounted or be mountable inside the container.
The majority of those will not be writable (or even readable) from inside an unprivileged container and will be blocked by our AppArmor policy inside privileged containers.
LXD containers may have any number of network devices attached to them.
The naming for those unless overridden by the user is
ethX where X is an incrementing number.
Container to host communication#
LXD sets up a socket at
/dev/lxd/sock which root in the container can use to communicate with LXD on the host.
The API is documented here.
If LXCFS is present on the host, it will automatically be set up for the container.
This normally results in a number of
/proc files being overridden through bind-mounts.
On older kernels a virtual version of
/sys/fs/cgroup may also be set up by LXCFS.