crun(1)

📦
version 1.21 · 2 versions
, in ubuntu resolute, ubuntu stonking

✨ crun(1) ✨ — General Commands Manual 💅

okay so bestie, meet crun, from the General Commands Manual section. she's a whole vibe and she runs containers. let's get into it 🫶

🌸 NAME 🌸

crun — a fast and lightweight OCI runtime ✨

🎀 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. iconic behavior honestly. she's a runtime, she runs your containers, that's the whole thing, periodt 💅

👑 COMMANDS 👑

okay so these are all the things you can ask crun to do. literally the whole menu:

  • create — Create a container. the runtime detaches from the container process once the container environment is created. heads up tho: after this you have to use start next to actually get it going. it's giving "two-step process" energy.
  • delete — Remove definition for a container.
  • exec — Exec a command in a running container.
  • list — List known containers.
  • kill — Send the specified signal to the container init process. if you don't specify a signal, SIGTERM is used. (no cap, it defaults on you.)
  • ps — Show the processes running in a container.
  • run — Create and immediately start a container. the main character tbh, does both steps at once ✨
  • spec — Generate a configuration file.
  • start — Start a container that was previously created. 🚨 important: a container cannot be started multiple times.
  • 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 🦋

okay so where does crun keep its stuff? it depends on who you are, bestie, and that's so real of her.

By default, when running as root user, crun saves its state under the /run/crun directory. 💾

As unprivileged user, instead the XDG_RUNTIME_DIR environment variable is honored, and the directory $XDG_RUNTIME_DIR/crun is used. 🌸

And if you want to override the whole thing? the global option --root overrides this setting. baddie behavior. 💅

🌈 GLOBAL OPTIONS 🌈

these work everywhere, they're the universal besties:

  • --debug — Produce verbose output. (basically crun telling you everything she's doing, oversharing era 🙈)
  • --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. 👀
  • --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.
  • --no-pivot — Use chroot(2) instead of pivot_root(2) when creating the container.
  • --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
⚠️ ok wait, real talk about --no-pivot: This option is not safe, and should be avoided. like, genuinely. bestie please don't. 🙏

💜 the log destination format

It is 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.

🎀 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
  • --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.
  • --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. (aggressive, but make it fashion 💅)
  • --regex=REGEX — Delete all the containers that satisfy the specified regex.

⭐ 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. (no creating it yourself, it's already gotta be there 🙈)
  • --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. (minimalist era, we love to see it)

🩸 KILL OPTIONS 🩸

crun [global options] kill [options] CONTAINER SIGNAL
  • --all — Kill all the processes in the container.
  • --regex=REGEX — Kill all the containers that satisfy the specified regex.

🧚 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 works see 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 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

If the annotation run.oci.seccomp.plugins=PLUGIN1[:PLUGIN2]... is specified, the seccomp listener fd is handled through the specified plugins. The plugin must either be an absolute path or a file name that is looked up by dlopen(3). More information on how the lookup is performed are available on the ld.so(8) man page.

run.oci.seccomp_fail_unknown_syscall=1

If the annotation run.oci.seccomp_fail_unknown_syscall is present, then crun will fail when an unknown syscall is encountered in the seccomp configuration.

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 and use the specified data as the raw data to the seccomp(SECCOMP_SET_MODE_FILTER) syscall. The data must be encoded in base64.

It is an experimental feature, and the annotation will be removed once it is supported in the OCI runtime specs.

🧪 heads up bestie: two of these seccomp annotations are explicitly marked experimental, and their annotations will be removed once the OCI runtime specs support them. just so you know what you're getting into ✨

run.oci.keep_original_groups=1

okay so if this annotation is there, crun just... skips the setgroups syscall entirely 💅. And that syscall is normally the thing that either sets the extra groups you listed in the OCI config, or resets the whole extra-groups list when you didn't list any. So yeah, this one is lowkey a "trust me bestie, hands off my groups" button.

run.oci.pidfd_receiver=PATH

this is an experimental feature and it will get removed once the thing lands in the OCI runtime specs. so don't get attached 😭

If it's present, you're telling crun where to send the pidfd for the container process — specifically the path to the UNIX socket that receives it.

run.oci.systemd.force_cgroup_v1=/PATH

If the annotation run.oci.systemd.force_cgroup_v1=/PATH shows up, crun overrides that mount point /PATH with a cgroup v1 mount built out of a single hierarchy none,name=systemd. Very much giving "I need this to work" energy — the point is running containers on a cgroup v2 system when the container's systemd is old and has zero cgroup v2 support 🧚.

Note: your container host has to already have the cgroup v1 mount sitting there, otherwise this straight up won't work. And if you wanna run the container rootless, the user it runs under needs permissions on that mountpoint. no permission, no party 🎀

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 one overrides the name of the systemd sub cgroup that gets created under the systemd scope, so the final cgroup comes out looking like:

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

If you set it to the empty string, then no sub cgroup gets created at all. rip little guy 💀

If you don't specify it at all, 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, then yet another sub-cgroup gets created and the container process gets moved into it. nesting dolls but make it cgroups 🪆

If a cgroup namespace is used, that cgroup namespace is created before moving the container to the delegated cgroup. order matters bestie.

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

The runtime applies no limits to the $DELEGATED-CGROUP sub-cgroup — it only uses $PATH/$SUBGROUP.

The container payload fully manages $DELEGATE-CGROUP, and the limits applied to $PATH/$SUBGROUP still apply to $DELEGATE-CGROUP.

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, crun opens that file and uses it as the stdout for the hook processes. It's opened in append mode, and it gets created if it doesn't already exist. very "make it if it's not there" of it ✨

run.oci.hooks.stderr=FILE

Same deal for stderr, bestie: if run.oci.hooks.stderr is present, crun opens the specified file and uses it as the stderr for the hook processes. Opened in append mode again, created if it doesn't already exist.

run.oci.handler=HANDLER

experimental feature alert 🚨

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. iconic.
  • wasm — if specified, run the wasm handler for the container. This lets you run wasm workloads natively. It accepts a .wasm binary as input, and if you hand it a .wat it'll automatically be compiled into a wasm module. The stdout of the wasm module is relayed back via crun. 🦋

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 into the tmpfs itself. so nothing gets left behind 💖

If the copy-symlink option is specified, then when the source of a bind mount is a symlink, the symlink is recreated at the specified destination instead of attempting a mount that would resolve the symlink itself.

And if the destination already exists and it is not a symlink with the expected content, crun will return an error. no sneaky business 🙈

r$FLAG mount options

If a r$FLAG mount option is specified, then the flag $FLAG is set recursively for each children mount. it's giving "and all their little friends too" 🌈

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 it can change at any time without notice. fr fr, don't build your whole life on it 💀

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

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 are 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 is 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).

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. 😭 you just gotta know, iykyk

Automatically create user namespace

When running as a user different than root, a user namespace is automatically created even if it's not 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. bestie gets a namespace whether she asked or not 💅

CGROUP v1

Support for cgroup v1 is deprecated and will be removed in a future release. okay so pour one out 🥲

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.

If the cgroup configuration found is for cgroup v1, crun attempts a conversion when running on a cgroup v2 system. glow-up conversion arc ✨

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

Memory controller

OCI (x) → cgroup 2 value (y) pattern, here we go:

  • limit → memory.max, conversion y = x, no comment. clean, no notes 👑
  • swap → memory.swap.max, conversion y = x - memory_limit. comment: the swap limit on cgroup v1 includes the memory usage too. sneaky math fr 😭
  • reservation → memory.low, conversion y = x, no comment. periodt.

PIDs controller

  • limit → pids.max, conversion y = x, no comment. that's it, that's the whole table 💖

🌸 CPU controller 🌸

ok so here's the tea on how the OCI values get converted into cgroup 2 values, mapping x → y, no cap:

  • shares → cpu.weight — conversion: y = (1 + ((x - 2) * 9999) / 262142), and the comment is that it converts from [2-262144] to [1-10000] 💫
  • period → cpu.max — conversion: y = x, comment: period and quota are written together 🔥
  • quota → cpu.max — conversion: y = x, comment: period and quota are written together (yes bestie, same team, they go together always) 💞

💅 blkio controller 💅

this one's the big one, so buckle up:

  • weight → io.bfq.weight — conversion: y = x, no comment, it's just that simple ✨
  • weight_device → io.bfq.weight — conversion: y = x, still no comment 🎀
  • weight → io.weight (fallback) — conversion: y = 1 + (x-10)*9999/990, comment: convert linearly from [10-1000] to [1-10000] 📐
  • weight_device → io.weight (fallback) — conversion: y = 1 + (x-10)*9999/990, comment: convert linearly from [10-1000] to [1-10000] (same math, different friend) 🫶
  • rbps → io.max — conversion: y=x
  • wbps → io.max — conversion: y=x
  • riops → io.max — conversion: y=x
  • wiops → io.max — conversion: y=x

ngl those last four are the chillest rows in the whole page, they literally just pass the value through 😌

🦋 cpuset controller 🦋

short and slay, we love her:

  • cpus → cpuset.cpus — conversion: y = x
  • mems → cpuset.mems — conversion: y = x

no comments, no drama, iconic behavior 💜

🍓 hugetlb controller 🍓

one whole row, she's minimal:

  • .limit_in_bytes → hugetlb..max — conversion: y = x

that's it bestie, that's the entire controller, and honestly? queen 💅

aaaand that's the whole page!! 🎉 thanks for reading all three parts, you're literally a main character for making it to the end 🫶

so real quick about the footer, since we're not copy-pasting it: this page lives in the User Commands section and it's crun(1), and it's got its own source/version and date stamps down there — so if you ever need to cite it or check what version you're reading, that's where to look 💖

go forth and containerize, babe 🐳✨

📦 where this page comes from