table of contents
- stretch 232-25+deb9u11
- testing 241-5
- stretch-backports 241-3~bpo9+1
- unstable 241-5
- experimental 242-2
SYSTEMD-NSPAWN(1) | systemd-nspawn | SYSTEMD-NSPAWN(1) |
NAME¶
systemd-nspawn - Spawn a namespace container for debugging, testing and buildingSYNOPSIS¶
systemd-nspawn [OPTIONS...] [COMMAND [ARGS...]]
systemd-nspawn --boot [OPTIONS...] [ARGS...]
DESCRIPTION¶
systemd-nspawn may be used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot(1), but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.systemd-nspawn may be invoked on any directory tree containing an operating system tree, using the --directory= command line option. By using the --machine= option an OS tree is automatically searched for in a couple of locations, most importantly in /var/lib/machines, the suggested directory to place container images installed on the system.
In contrast to chroot(1) systemd-nspawn may be used to boot full Linux-based operating systems in a container.
systemd-nspawn limits access to various kernel interfaces in the container to read-only, such as /sys, /proc/sys or /sys/fs/selinux. The host's network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.
Use a tool like dnf(8), debootstrap(8), or pacman(8) to set up an OS directory tree suitable as file system hierarchy for systemd-nspawn containers. See the Examples section below for details on suitable invocation of these commands.
As a safety check systemd-nspawn will verify the existence of /usr/lib/os-release or /etc/os-release in the container tree before starting the container (see os-release(5)). It might be necessary to add this file to the container tree manually if the OS of the container is too old to contain this file out-of-the-box.
systemd-nspawn may be invoked directly from the interactive command line or run as system service in the background. In this mode each container instance runs as its own service instance; a default template unit file systemd-nspawn@.service is provided to make this easy, taking the container name as instance identifier. Note that different default options apply when systemd-nspawn is invoked by the template unit file than interactively on the command line. Most importantly the template unit file makes use of the --boot which is not the default in case systemd-nspawn is invoked from the interactive command line. Further differences with the defaults are documented along with the various supported options below.
The machinectl(1) tool may be used to execute a number of operations on containers. In particular it provides easy-to-use commands to run containers as system services using the systemd-nspawn@.service template unit file.
Along with each container a settings file with the .nspawn suffix may exist, containing additional settings to apply when running the container. See systemd.nspawn(5) for details. Settings files override the default options used by the systemd-nspawn@.service template unit file, making it usually unnecessary to alter this template file directly.
Note that systemd-nspawn will mount file systems private to the container to /dev, /run and similar. These will not be visible outside of the container, and their contents will be lost when the container exits.
Note that running two systemd-nspawn containers from the same directory tree will not make processes in them see each other. The PID namespace separation of the two containers is complete and the containers will share very few runtime objects except for the underlying file system. Use machinectl(1)'s login or shell commands to request an additional login session in a running container.
systemd-nspawn implements the Container Interface[1] specification.
While running, containers invoked with systemd-nspawn are registered with the systemd-machined(8) service that keeps track of running containers, and provides programming interfaces to interact with them.
OPTIONS¶
If option -b is specified, the arguments are used as arguments for the init binary. Otherwise, COMMAND specifies the program to launch in the container, and the remaining arguments are used as arguments for this program. If --boot is not used and no arguments are specified, a shell is launched in the container.The following options are understood:
-D, --directory=
If neither --directory=, nor --image= is specified the directory is determined by searching for a directory named the same as the machine name specified with --machine=. See machinectl(1) section "Files and Directories" for the precise search path.
If neither --directory=, --image=, nor --machine= are specified, the current directory will be used. May not be specified together with --image=.
--template=
Note that this switch leaves host name, machine ID and all other settings that could identify the instance unmodified.
-x, --ephemeral
Note that this switch leaves host name, machine ID and all other settings that could identify the instance unmodified.
-i, --image=
On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to /efi (or /boot as fallback) in case a directory by this name exists and is empty.
Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified together with --directory=, --template=.
-a, --as-pid2
-b, --boot
The following table explains the different modes of invocation and relationship to --as-pid2 (see above):
Table 1. Invocation Mode
Switch | Explanation |
Neither --as-pid2 nor --boot specified | The passed parameters are interpreted as the command line, which is executed as PID 1 in the container. |
--as-pid2 specified | The passed parameters are interpreted as the command line, which is executed as PID 2 in the container. A stub init process is run as PID 1. |
--boot specified | An init binary as automatically searched and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process. |
Note that
--boot is the default mode of operation if the systemd-nspawn@.service
template unit file is used.
--chdir=
-u, --user=
-M, --machine=
--uuid=
--slice=
--property=
--private-users=
It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16 bit encode the container UID/GID used. This is in fact the behavior enforced by the --private-users=pick option.
When user namespaces are used, the GID range assigned to each container is always chosen identical to the UID range.
In most cases, using --private-users=pick is the recommended option as it enhances container security massively and operates fully automatically in most cases.
Note that the picked UID/GID range is not written to /etc/passwd or /etc/group. In fact, the allocation of the range is not stored persistently anywhere, except in the file ownership of the files and directories of the container.
--private-users-chown
This option is implied if --private-users=pick is used. This option has no effect if user namespacing is not used.
-U
Note that -U is the default if the systemd-nspawn@.service template unit file is used.
Note: it is possible to undo the effect of --private-users-chown (or -U) on the file system by redoing the operation with the first UID of 0:
systemd-nspawn ... --private-users=0 --private-users-chown
--private-network
--network-interface=
--network-macvlan=
--network-ipvlan=
-n, --network-veth
Note that systemd-networkd.service(8) includes by default a network file /lib/systemd/network/80-container-ve.network matching the host-side interfaces created this way, which contains settings to enable automatic address provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external network interfaces. It also contains /lib/systemd/network/80-container-host0.network matching the container-side interface created this way, containing settings to enable client side address assignment via DHCP. In case systemd-networkd is running on both the host and inside the container, automatic IP communication from the container to the host is thus available, with further connectivity to the external network.
Note that --network-veth is the default if the systemd-nspawn@.service template unit file is used.
--network-veth-extra=
--network-bridge=
--network-zone=
This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form valid network interface names when prefixed with "vz-"), and it is sufficient to pass the same name to the --network-zones= switch of the various concurrently running containers to join them in one zone.
Note that systemd-networkd.service(8) includes by default a network file /lib/systemd/network/80-container-vz.network matching the bridge interfaces created this way, which contains settings to enable automatic address provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external network interfaces. Using --network-zone= is hence in most cases fully automatic and sufficient to connect multiple local containers in a joined broadcast domain to the host, with further connectivity to the external network.
-p, --port=
-Z, --selinux-context=
-L, --selinux-apifs-context=
--capability=
--drop-capability=
--kill-signal=
--link-journal=
Note that --link-journal=try-guest is the default if the systemd-nspawn@.service template unit file is used.
-j
--read-only
--bind=, --bind-ro=
--tmpfs=
--overlay=, --overlay-ro=
Backslash escapes are interpreted in the paths, so "\:" may be used to embed colons in the paths.
If three or more paths are specified, then the last specified path is the destination mount point in the container, all paths specified before refer to directory trees on the host and are combined in the specified order into one overlay file system. The left-most path is hence the lowest directory tree, the second-to-last path the highest directory tree in the stacking order. If --overlay-ro= is used instead of --overlay=, a read-only overlay file system is created. If a writable overlay file system is created, all changes made to it are written to the highest directory tree in the stacking order, i.e. the second-to-last specified.
If only two paths are specified, then the second specified path is used both as the top-level directory tree in the stacking order as seen from the host, as well as the mount point for the overlay file system in the container. At least two paths have to be specified.
For details about overlay file systems, see overlayfs.txt[3]. Note that the semantics of overlay file systems are substantially different from normal file systems, in particular regarding reported device and inode information. Device and inode information may change for a file while it is being written to, and processes might see out-of-date versions of files at times. Note that this switch automatically derives the "workdir=" mount option for the overlay file system from the top-level directory tree, making it a sibling of it. It is hence essential that the top-level directory tree is not a mount point itself (since the working directory must be on the same file system as the top-most directory tree). Also note that the "lowerdir=" mount option receives the paths to stack in the opposite order of this switch.
-E NAME=VALUE, --setenv=NAME=VALUE
--register=
--keep-unit
--personality=
-q, --quiet
--volatile, --volatile=MODE
Note that setting this to yes or state will only work correctly with operating systems in the container that can boot up with only /usr mounted, and are able to populate /var automatically, as needed.
--settings=MODE
If enabled (the default), a settings file named after the machine (as specified with the --machine= setting, or derived from the directory or image file name) with the suffix .nspawn is searched in /etc/systemd/nspawn/ and /run/systemd/nspawn/. If it is found there, its settings are read and used. If it is not found there, it is subsequently searched in the same directory as the image file or in the immediate parent of the root directory of the container. In this case, if the file is found, its settings will be also read and used, but potentially unsafe settings are ignored. Note that in both these cases, settings on the command line take precedence over the corresponding settings from loaded .nspawn files, if both are specified. Unsafe settings are considered all settings that elevate the container's privileges or grant access to additional resources such as files or directories of the host. For details about the format and contents of .nspawn files, consult systemd.nspawn(5).
If this option is set to override, the file is searched, read and used the same way, however, the order of precedence is reversed: settings read from the .nspawn file will take precedence over the corresponding command line options, if both are specified.
If this option is set to trusted, the file is searched, read and used the same way, but regardless of being found in /etc/systemd/nspawn/, /run/systemd/nspawn/ or next to the image file or container root directory, all settings will take effect, however, command line arguments still take precedence over corresponding settings.
If disabled, no .nspawn file is read and no settings except the ones on the command line are in effect.
--notify-ready=
-h, --help
--version
EXAMPLES¶
Example 1. Download a Fedora image and start a shell in it# machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-1.2.x86_64.raw.xz # systemd-nspawn -M Fedora-Cloud-Base-24-1.2.x86_64.raw
This downloads an image using machinectl(1) and opens a shell in it.
Example 2. Build and boot a minimal Fedora distribution in a container
# dnf -y --releasever=23 --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal # systemd-nspawn -bD /srv/mycontainer
This installs a minimal Fedora distribution into the directory /srv/mycontainer/ and then boots an OS in a namespace container in it.
Example 3. Spawn a shell in a container of a minimal Debian unstable distribution
# debootstrap --arch=amd64 unstable ~/debian-tree/ # systemd-nspawn -D ~/debian-tree/
This installs a minimal Debian unstable distribution into the directory ~/debian-tree/ and then spawns a shell in a namespace container in it.
Example 4. Boot a minimal Arch Linux distribution in a container
# pacstrap -c -d ~/arch-tree/ base # systemd-nspawn -bD ~/arch-tree/
This installs a minimal Arch Linux distribution into the directory ~/arch-tree/ and then boots an OS in a namespace container in it.
Example 5. Boot into an ephemeral "btrfs" snapshot of the host system
# systemd-nspawn -D / -xb
This runs a copy of the host system in a "btrfs" snapshot which is removed immediately when the container exits. All file system changes made during runtime will be lost on shutdown, hence.
Example 6. Run a container with SELinux sandbox security contexts
# chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh
EXIT STATUS¶
The exit code of the program executed in the container is returned.SEE ALSO¶
systemd(1), systemd.nspawn(5), chroot(1), dnf(8), debootstrap(8), pacman(8), systemd.slice(5), machinectl(1), btrfs(8)NOTES¶
- 1.
- Container Interface
- 2.
- Discoverable Partitions Specification
- 3.
- overlayfs.txt
systemd 232 |