crun(1)

๐ŸŒธ crun โ€” a fast and lightweight OCI runtime ๐ŸŒธ

okay so this is crun(1) from the General Commands Manual, and bestie, it's literally the whole vibe for running Linux containers in the OCI (Open Container Initiative) format. Let's get into it ๐Ÿ’…


โœจ NAME โœจ

crun โ€” a fast and lightweight OCI runtime. no notes, that's the whole pitch ๐Ÿซถ

๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

crun [global options] command [command options] [arguments...]

๐Ÿ’– DESCRIPTION ๐Ÿ’–

crun is a command line program for running Linux containers that follow the Open Container Initiative (OCI) format. that's it. that's the whole icon behavior โœจ

๐Ÿ‘‘ COMMANDS ๐Ÿ‘‘

  • create โ€” Create a container. the runtime detaches from the container process once the container environment is created, so heads up: you have to use start afterward to actually get it going, bestie. no skipping steps ๐Ÿ’…
  • delete โ€” Remove definition for a container.
  • exec โ€” Exec a command in a running container.
  • list โ€” List known containers.
  • mounts add โ€” Add mounts while the container is running. it needs two arguments: the container ID and a JSON file containing the mounts section of the OCI config file. each mount listed there gets added to the running container. โš ๏ธ this command is experimental and can be changed without notice, so don't get too attached ๐Ÿ˜ญ
  • mounts remove โ€” Remove mounts while the container is running. also two arguments: the container ID and a JSON file with the mounts section of the OCI config file. only the destination attribute for each mount is used. also experimental, also can change without notice ๐Ÿ™ˆ
  • kill โ€” Send the specified signal to the container init process. if no signal is specified, SIGTERM is used. periodt.
  • ps โ€” Show the processes running in a container.
  • run โ€” Create and immediately start a container. the combo meal ๐Ÿ”ฅ
  • spec โ€” Generate a configuration file.
  • start โ€” Start a container that was previously created. ๐Ÿšจ a container cannot be started multiple times, so don't try it.
  • state โ€” Output the state of a container.
  • pause โ€” Pause all the processes in the container.
  • resume โ€” Resume the processes in the container.
  • update โ€” Update container resource constraints.
  • checkpoint โ€” Checkpoint a running container using CRIU.
  • restore โ€” Restore a container from a checkpoint.

๐ŸŽ€ STATE ๐ŸŽ€

By default, when running as root user, crun saves its state under the /run/crun directory. as an unprivileged user, though? it honors the XDG_RUNTIME_DIR environment variable instead, and the directory $XDG_RUNTIME_DIR/crun is used. the global option --root overrides this setting. slay ๐Ÿ’…


โญ GLOBAL OPTIONS โญ

  • --debug โ€” Produce verbose output. like, it tells you everything ๐Ÿ‘€
  • --log=LOG-DESTINATION โ€” Define the destination for the error and warning messages generated by crun. if the error happens late in the container init process, when crun already stopped watching it, then it will be printed to the container stderr. it's specified in the form BACKEND:SPECIFIER. these following backends are supported:
    • file:PATH
    • journald:IDENTIFIER
    • syslog:IDENTIFIER

if no backend is specified, then file: is used by default.

  • --log-format=FORMAT โ€” Define the format of the log messages. it can either be text, or json. the default is text.
  • --log-level=LEVEL โ€” Define the log level. it can either be debug, warning or error. the default is error.
  • --root=DIR โ€” Defines where to store the state for crun containers.
  • --systemd-cgroup โ€” Use systemd for configuring cgroups. if not specified, the cgroup is created directly using the cgroupfs backend.
  • --cgroup-manager=MANAGER โ€” Specify what cgroup manager must be used. permitted values are cgroupfs, systemd and disabled.
  • -?, --help โ€” Print a help list.
  • --usage โ€” Print a short usage message.
  • -V, --version โ€” Print program version

๐ŸŒˆ CREATE OPTIONS ๐ŸŒˆ

crun [global options] create [options] CONTAINER
  • --bundle=PATH โ€” Path to the OCI bundle, by default it is the current directory.
  • --config=FILE โ€” Override the configuration file to use. the default value is config.json.
  • --console-socket=SOCKET โ€” Path to a UNIX socket that will receive the ptmx end of the tty for the container.
  • --no-new-keyring โ€” Keep the same session key
  • --no-pivot โ€” Use chroot(2) instead of pivot_root(2) when creating the container. ๐Ÿšจ this option is not safe, and should be avoided. like, fr fr, don't.
  • --preserve-fds=N โ€” Additional number of FDs to pass into the container.
  • --pid-file=PATH โ€” Path to the file that will contain the container process PID.

๐Ÿฆ„ RUN OPTIONS ๐Ÿฆ„

crun [global options] run [options] CONTAINER
  • --bundle=BUNDLE โ€” Path to the OCI bundle, by default it is the current directory.
  • --config=FILE โ€” Override the configuration file to use. the default value is config.json.
  • --console-socket=SOCKET โ€” Path to a UNIX socket that will receive the ptmx end of the tty for the container.
  • --no-new-keyring โ€” Keep the same session key.
  • --no-pivot โ€” Use chroot(2) instead of pivot_root(2) when creating the container. again: not safe, and should be avoided ๐Ÿ˜ฌ
  • --preserve-fds=N โ€” Additional number of FDs to pass into the container.
  • --pid-file=PATH โ€” Path to the file that will contain the container process PID.
  • --detach โ€” Detach the container process from the current session.

๐Ÿ’€ DELETE OPTIONS ๐Ÿ’€

crun [global options] delete [options] CONTAINER
  • --force โ€” Delete the container even if it is still running. menace behavior, but okay ๐Ÿ’…
  • --regex โ€” Treat CONTAINER as a regular expression and delete all matching containers.

๐Ÿงš EXEC OPTIONS ๐Ÿงš

crun [global options] exec [options] CONTAINER CMD
  • --apparmor=PROFILE โ€” Set the apparmor profile for the process.
  • --console-socket=SOCKET โ€” Path to a UNIX socket that will receive the ptmx end of the tty for the container.
  • --cwd=PATH โ€” Set the working directory for the process to PATH.
  • --cap=CAP โ€” Specify an additional capability to add to the process.
  • --detach โ€” Detach the container process from the current session.
  • --cgroup=PATH โ€” Specify a sub-cgroup path inside the container cgroup. the path must already exist in the container cgroup, so no inventing directories bestie.
  • --env=ENV โ€” Specify an environment variable.
  • --no-new-privs โ€” Set the no new privileges value for the process.
  • --preserve-fds=N โ€” Additional number of FDs to pass into the container.
  • --process=FILE โ€” Path to a file containing the process JSON configuration.
  • --process-label=VALUE โ€” Set the asm process label for the process commonly used with selinux.
  • --pid-file=PATH โ€” Path to the file that will contain the new process PID.
  • -t, --tty โ€” Allocate a pseudo TTY.
  • *-u *USERSPEC, --user=*USERSPEC*** โ€” Specify the user in the form UID[:GID]`.

๐Ÿ“ LIST OPTIONS ๐Ÿ“

crun [global options] list [options]
  • -q, --quiet โ€” Show only the container ID. minimalism โœจ

๐Ÿ”ฅ KILL OPTIONS ๐Ÿ”ฅ

crun [global options] kill [options] CONTAINER SIGNAL
  • --all โ€” Kill all the processes in the container.
  • --regex โ€” Treat CONTAINER as a regular expression and send the specified signal to all matching containers.

๐ŸŽ€ PS OPTIONS ๐ŸŽ€

crun [global options] ps [options]
  • --format=FORMAT โ€” Specify the output format. it must be either table or json. by default table is used.

๐Ÿ’œ SPEC OPTIONS ๐Ÿ’œ

crun [global options] spec [options]
  • -b DIR, --bundle=DIR โ€” Path to the root of the bundle dir (default ".").
  • --rootless โ€” Generate a config.json file that is usable by an unprivileged user.

๐ŸŒธ UPDATE OPTIONS ๐ŸŒธ

crun [global options] update [options] CONTAINER
  • --blkio-weight=VALUE โ€” Specifies per cgroup weight.
  • --cpu-period=VALUE โ€” CPU CFS period to be used for hardcapping.
  • --cpu-quota=VALUE โ€” CPU CFS hardcap limit.
  • --cpu-rt-period=VALUE โ€” CPU realtime period to be used for hardcapping.
  • --cpu-rt-runtime=VALUE โ€” CPU realtime hardcap limit.
  • --cpu-share=VALUE โ€” CPU shares.
  • --cpuset-cpus=VALUE โ€” CPU(s) to use.
  • --cpuset-mems=VALUE โ€” Memory node(s) to use.
  • --kernel-memory=VALUE โ€” Kernel memory limit.
  • --kernel-memory-tcp=VALUE โ€” Kernel memory limit for TCP buffer.
  • --memory=VALUE โ€” Memory limit.
  • --memory-reservation=VALUE โ€” Memory reservation or soft_limit.
  • --memory-swap=VALUE โ€” Total memory usage.
  • --pids-limit=VALUE โ€” Maximum number of pids allowed in the container.
  • -r, --resources=FILE โ€” Path to the file containing the resources to update.

๐Ÿฆ‹ CHECKPOINT OPTIONS ๐Ÿฆ‹

crun [global options] checkpoint [options] CONTAINER
  • --image-path=DIR โ€” Path for saving CRIU image files
  • --work-path=DIR โ€” Path for saving work files and logs
  • --leave-running โ€” Leave the process running after checkpointing
  • --tcp-established โ€” Allow open TCP connections
  • --ext-unix-sk โ€” Allow external UNIX sockets
  • --shell-job โ€” Allow shell jobs
  • --pre-dump โ€” Only checkpoint the container's memory without stopping the container. ๐Ÿšจ it is not possible to restore a container from a pre-dump. a pre-dump always needs a final checkpoint (without --pre-dump). it is possible to make as many pre-dumps as necessary. for a second pre-dump or for a final checkpoint it is necessary to use --parent-path to point crun (and thus CRIU) to the pre-dump.
  • --parent-path=DIR โ€” Doing multiple pre-dumps or the final checkpoint after one or multiple pre-dumps requires that crun (and thus CRIU) knows the location of the pre-dump. it is important to use a relative path from the actual checkpoint directory specified via --image-path. it will fail if an absolute path is used ๐Ÿ˜ญ
  • --manage-cgroups-mode=MODE โ€” Specify which CRIU manage cgroup mode should be used. permitted values are soft, ignore, full or strict. default is soft.

โญ RESTORE OPTIONS โญ

crun [global options] restore [options] CONTAINER
  • -b DIR, --bundle=DIR โ€” Container bundle directory (default ".")
  • --image-path=DIR โ€” Path for saving CRIU image files
  • --work-path=DIR โ€” Path for saving work files and logs
  • --tcp-established โ€” Allow open TCP connections
  • --ext-unix โ€” Allow external UNIX sockets
  • --shell-job โ€” Allow shell jobs
  • --detach โ€” Detach from the container's process
  • --pid-file=FILE โ€” Where to write the PID of the container
  • --manage-cgroups-mode=MODE โ€” Specify which CRIU manage cgroup mode should be used. permitted values are soft, ignore, full or strict. default is soft.
  • --lsm-profile=TYPE:NAME โ€” Specify an LSM profile to be used during restore. TYPE can be either apparmor or selinux.
  • --lsm-mount-context=VALUE โ€” Specify a new LSM mount context to be used during restore. this option replaces an existing mount context information with the specified value. this is useful when restoring a container into an existing Pod and selinux labels need to be changed during restore.

๐Ÿซถ Extensions to OCI ๐Ÿซถ

run.oci.mount_context_type=context

Set the mount context type on volumes mounted with SELinux labels.

valid context types are:

  • context (default)
  • fscontext
  • defcontext
  • rootcontext

more information on how the context mount flags work can be found in the mount(8) man page.

run.oci.seccomp.receiver=PATH

if the annotation run.oci.seccomp.receiver=PATH is specified, the seccomp listener is sent to the UNIX socket listening on the specified path. it can also be set with the RUN_OCI_SECCOMP_RECEIVER environment variable. โš ๏ธ it is an experimental feature, and the annotation will be removed once it is supported in the OCI runtime specs. it must be an absolute path.

run.oci.seccomp.plugins=PATH

Okay so if the annotation run.oci.seccomp.plugins=PLUGIN1[:PLUGIN2]... is there, then the seccomp listener fd gets handled through the plugins you named. Each plugin has to either be an absolute path or a file name that gets looked up by dlopen(3) โ€” and if you wanna know exactly how that lookup goes down, the ld.so(8) man page has the deets. ๐Ÿซถ

run.oci.seccomp_fail_unknown_syscall=1

If the annotation run.oci.seccomp_fail_unknown_syscall is present, then crun will legit just fail when it hits an unknown syscall in the seccomp configuration. No quietly ignoring it, bestie โ€” it's a hard fail. ๐Ÿ’€

run.oci.seccomp_bpf_data=PATH

If the annotation run.oci.seccomp_bpf_data is present, then crun ignores the seccomp section in the OCI configuration file entirely and uses the specified data as the raw data for the seccomp(SECCOMP_SET_MODE_FILTER) syscall. That data has to be encoded in base64, no exceptions.

Heads up bb: this is an experimental feature, and the annotation is gonna get removed once it's supported in the OCI runtime specs. So don't get too attached. ๐Ÿ™ˆ

run.oci.keep_original_groups=1

If the annotation run.oci.keep_original_groups is present, then crun skips the setgroups syscall. You know the one โ€” it's normally used to either set the additional groups from the OCI configuration, or reset the list of additional groups when none is specified. Skipped. Bye. โœจ

run.oci.pidfd_receiver=PATH

Experimental feature alert ๐ŸŽ€ โ€” this one gets removed once the feature lands in the OCI runtime specs, fr fr.

If present, you specify the path to the UNIX socket that's gonna receive the pidfd for the container process.

run.oci.systemd.force_cgroup_v1=/PATH

If the annotation run.oci.systemd.force_cgroup_v1=/PATH is present, then crun overrides the specified mount point /PATH with a cgroup v1 mount made of a single hierarchy none,name=systemd. It's iconic for running on a cgroup v2 system with containers that use older systemd versions that just don't have cgroup v2 support. ๐Ÿ‘‘

Note: your container host has to have the cgroup v1 mount already present, otherwise this literally will not work. And if you wanna run the container rootless, the user it runs under needs permissions to that mountpoint. No perms, no vibes. ๐Ÿซ 

For example, as root:

mkdir /sys/fs/cgroup/systemd
mount cgroup -t cgroup /sys/fs/cgroup/systemd -o none,name=systemd,xattr
chown -R the_user.the_user /sys/fs/cgroup/systemd

run.oci.systemd.subgroup=SUBGROUP

This overrides the name for the systemd sub cgroup created under the systemd scope, so the final cgroup ends up looking like:

/sys/fs/cgroup/$PATH/$SUBGROUP

When it's set to the empty string, no sub cgroup gets created at all. โœจ

If you don't specify it, it defaults to container on cgroup v2, and to "" on cgroup v1.

e.g.

/sys/fs/cgroup//system.slice/foo-352700.scope/container

run.oci.delegate-cgroup=DELEGATED-CGROUP

If the run.oci.systemd.subgroup annotation is specified, yet another sub-cgroup gets created and the container process is moved in there. Like, nesting levels, bestie. ๐Ÿช†

If a cgroup namespace is used, the cgroup namespace is created before moving the container to the delegated cgroup.

/sys/fs/cgroup/$PATH/$SUBGROUP/$DELEGATED-CGROUP

The runtime does not apply any limit to the $DELEGATED-CGROUP sub-cgroup โ€” it only uses $PATH/$SUBGROUP.

The container payload fully manages $DELEGATE-CGROUP, but the limits applied to $PATH/$SUBGROUP still apply to $DELEGATE-CGROUP. So the vibes trickle down. ๐ŸŒˆ

Since cgroup delegation is not safe on cgroup v1, this option is supported only on cgroup v2. Periodt. ๐Ÿ’…

run.oci.hooks.stdout=FILE

If the annotation run.oci.hooks.stdout is present, then crun opens the specified file and uses it as the stdout for the hook processes. The file is opened in append mode and it gets created if it doesn't already exist. ๐ŸŽ€

run.oci.hooks.stderr=FILE

If the annotation run.oci.hooks.stderr is present, then crun opens the specified file and uses it as the stderr for the hook processes. The file is opened in append mode and it gets created if it doesn't already exist. Same energy, different stream. ๐Ÿ’–

run.oci.handler=HANDLER

It's an experimental feature, okay? ๐Ÿฆ‹

If specified, it runs the specified handler for execing the container. The only supported values are krun and wasm.

  • krun โ€” when krun is specified, the libkrun.so shared object is loaded and it's used to launch the container using libkrun.
  • wasm โ€” if specified, run the wasm handler for the container. It allows running wasm workload natively. Accepts a .wasm binary as input, and if .wat is provided it gets automatically compiled into a wasm module. The stdout of the wasm module is relayed back via crun.

org.criu.config=FILE

This annotation lets you specify a CRIU RPC configuration file. If you don't provide one, crun looks for /etc/criu/crun.conf. If neither the annotation nor crun.conf exists, then /etc/criu/runc.conf is used for compatibility with runc. This whole thing requires CRIU version 4.2 or newer. โœจ

The options specified in the configuration file override the default values of CRIU options specified by crun. For example, specifying tcp-established or tcp-close can be used to checkpoint/restore containers with TCP established connections, and log-file=<file> sets a custom CRIU logs file. iykyk ๐Ÿซถ


tmpcopyup mount options

If the tmpcopyup option is specified for a tmpfs, then the path that's shadowed by the tmpfs mount gets recursively copied up to the tmpfs itself. Copying it up so it's not just... gone. ๐Ÿ˜ญ

If the copy-symlink option is specified, and the source of a bind mount is a symlink, then the symlink is recreated at the specified destination instead of attempting a mount that would resolve the symlink itself. If the destination already exists and it is not a symlink with the expected content, crun will return an error. No silent overwrites here, bestie. ๐Ÿ’…

dest-nofollow

When this option is specified for a bind mount, and the destination of the bind mount is a symbolic link, crun will mount the symbolic link itself at the target destination. Yes, the link itself. Iconic.

src-nofollow

When this option is specified for a bind mount, and the source of the bind mount is a symbolic link, crun will use the symlink itself rather than the file or directory the symbolic link points to. ๐Ÿ’–

r$FLAG mount options

If a r$FLAG mount option is specified then the flag $FLAG is set recursively for each child mount. Yeah. Every child. It's giving generational. ๐Ÿ‘‘

These flags are supported:

  • "rro"
  • "rrw"
  • "rsuid"
  • "rnosuid"
  • "rdev"
  • "rnodev"
  • "rexec"
  • "rnoexec"
  • "rsync"
  • "rasync"
  • "rdirsync"
  • "rmand"
  • "rnomand"
  • "ratime"
  • "rnoatime"
  • "rdiratime"
  • "rnodiratime"
  • "rrelatime"
  • "rnorelatime"
  • "rstrictatime"
  • "rnostrictatime"

idmap mount options

If the idmap option is specified then the mount is ID mapped using the container target user namespace.

This is an experimental feature and can change at any time without notice. Fr fr, no promises. ๐Ÿ™ˆ

The idmap option supports a custom mapping that can be different than the user namespace used by the container.

The mapping can be specified after the idmap option like: idmap=uids=0-1-10#10-11-10;gids=0-100-10.

For each triplet, the first value is the start of the backing file system IDs that are mapped to the second value on the host. The length of this mapping is given in the third value.

Multiple ranges are separated with #.

These values get written to the /proc/$PID/uid_map and /proc/$PID/gid_map files to create the user namespace for the idmapped mount.

The only two options currently supported after idmap are uids and gids.

When a custom mapping is specified, a new user namespace is created for the idmapped mount. ๐Ÿฆ‹

If no option is specified, then the container user namespace is used.

If the specified mapping is prepended with a @ then the mapping is considered relative to the container user namespace. The host ID for the mapping gets changed to account for the relative position of the container user in the container user namespace.

For example, the mapping: uids=@1-3-10, given a configuration like

"uidMappings": [
      {
        "containerID": 0,
        "hostID": 0,
        "size": 1
      },
      {
        "containerID": 1,
        "hostID": 2,
        "size": 1000
      }
    ]

will be converted to the absolute value uids=1-4-10, where 4 is calculated by adding 3 (container ID in the uids= mapping) and 1 (hostID - containerID for the user namespace mapping where containerID = 1 is found).

Caveat time, bestie ๐Ÿ˜ญ: the current implementation doesn't take into account multiple user namespace ranges, so it is the caller's responsibility to split a mapping if it overlaps multiple ranges in the user namespace. And in such a case, there won't be any error reported. So like... it'll just do a thing. Pay attention. ๐Ÿ’€

Automatically create user namespace

When running as a user other than root, a user namespace is automatically created even if it isn't specified in the config file. The current user is mapped to the ID 0 in the container, and any additional id specified in the files /etc/subuid and /etc/subgid is automatically added starting with ID 1. Automatic. Main character energy. โœจ

CGROUP v1

Support for cgroup v1 is deprecated and will be removed in a future release. ๐ŸŽ€

CGROUP v2

Note: cgroup v2 does not yet support control of realtime processes, and the cpu controller can only be enabled when all RT processes are in the root cgroup. This will make crun fail while running alongside RT processes. Not a vibe. ๐Ÿ’€

If the cgroup configuration found is for cgroup v1, crun attempts a conversion when running on a cgroup v2 system.

These are the OCI resources currently supported with cgroup v2 and how they are converted when needed from the cgroup v1 configuration. ๐Ÿ‘‘

๐Ÿง  Memory controller

okay bestie, here's how OCI memory limits map onto cgroup v2 values โ€” x is the OCI side, y is what actually lands in cgroup 2:

  • limit โ†’ memory.max, conversion y = x (no notes, clean, we love to see it โœจ)
  • swap โ†’ memory.swap.max, conversion y = x - memory_limit โ€” heads up: the swap limit on cgroup v1 includes the memory usage too ๐Ÿซ 
  • reservation โ†’ memory.low, conversion y = x

๐Ÿงฎ PIDs controller

  • limit โ†’ pids.max, conversion y = x

short and sweet, no drama ๐Ÿ’…


โšก CPU controller

  • shares โ†’ cpu.weight, conversion y=10^((log2(x)^2 + 125 * log2(x)) / 612.0 - 7.0 / 34.0) โ€” this is converting from [2-262144] to [1-10000], math girlies rise ๐Ÿ™Œ
  • period โ†’ cpu.max, conversion y = x โ€” note that period and quota are written together
  • quota โ†’ cpu.max, conversion y = x โ€” same deal, period and quota are written together

๐Ÿ’พ blkio controller

  • weight โ†’ io.bfq.weight, conversion y = x
  • weight_device โ†’ io.bfq.weight, conversion y = x
  • weight โ†’ io.weight (fallback), conversion y = 1 + (x-10)*9999/990 โ€” convert linearly from [10-1000] to [1-10000]
  • weight_device โ†’ io.weight (fallback), conversion y = 1 + (x-10)*9999/990 โ€” convert linearly from [10-1000] to [1-10000]
  • rbps โ†’ io.max, conversion y=x
  • wbps โ†’ io.max, conversion y=x
  • riops โ†’ io.max, conversion y=x
  • wiops โ†’ io.max, conversion y=x

look at all those io.max mappings, they really said "same energy" ๐Ÿ˜Œ


๐ŸŽ€ cpuset controller

  • cpus โ†’ cpuset.cpus, conversion y = x
  • mems โ†’ cpuset.mems, conversion y = x

๐Ÿ˜ hugetlb controller

  • .limit_in_bytes โ†’ hugetlb..max, conversion y = x โ€” yes the double dot is exactly how it's written, don't come for me, I'm just the messenger ๐Ÿ’€

aaaand that's a wrap on the cgroup mapping section, bestie!! ๐Ÿฆ‹ you made it through the whole page, i'm so proud of you fr fr ๐ŸŒธ

this has been the crun(1) manual page from the User Commands section โ€” the source/version and the date at the bottom of the page are your receipts for exactly which build and day you're reading, so peek at the footer for those, and go slay your containers ๐Ÿ‘‘๐Ÿ’–

๐Ÿ“ฆ where this page comes from