Container runtime environment#
Incus attempts to present a consistent environment to all containers it runs.
The exact environment will differ slightly based on kernel features and user configuration, but otherwise, it is identical for all containers.
Incus assumes that any image it uses to create a new container comes with at least the following root-level directories:
Incus containers have a minimal and ephemeral
/dev based on a
tmpfs file system.
Since this is a
tmpfs and not a
devtmpfs file system, device nodes appear only if manually created.
The following standard set of device nodes is set up automatically:
In addition to the standard set of devices, the following devices are also set up for convenience:
Incus containers may have any number of network devices attached to them.
The naming for those (unless overridden by the user) is
X is an incrementing number.
Incus sets up a socket at
/dev/incus/sock that the root user in the container can use to communicate with Incus on the host.
See Communication between instance and host for the API documentation.
The following mounts are set up by default:
cgroupfs) (only on kernels that lack cgroup namespace support)
If they are present on the host, the following paths will also automatically be mounted:
The reason for passing all of those paths is that legacy init systems require them to be mounted, or be mountable, inside the container.
The majority of those paths will not be writable (or even readable) from inside an unprivileged container. In privileged containers, they will be blocked by the AppArmor policy.
If LXCFS is present on the host, it is automatically 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 might also be set up by LXCFS.
Incus 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.
Incus’ 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 three are closed prior to PID1 being spawned.