🦭 Podman Error: 'systemd cgroup flag passed, but systemd support not available' on cgroups v1

Exact Error Message

$ podman run --rm --memory=512m docker.io/library/alpine:latest true
Error: OCI runtime error: runc: systemd cgroup flag passed, but systemd
support for managing cgroups is not available

On a rootless v1 host the resource-limit variant is a warning rather than a hard failure:

$ podman run --rm --memory=512m docker.io/library/alpine:latest true
WARN[0000] Resource limits are not supported and ignored on cgroups V1 rootless systems

What It Means

Linux has two cgroup hierarchies. The legacy v1 layout mounts a separate hierarchy per controller under /sys/fs/cgroup/memory, /sys/fs/cgroup/cpu, and so on, and it has no safe way to hand a subtree to an unprivileged user. The v2 unified hierarchy mounts one tree at /sys/fs/cgroup and supports delegation: systemd can mark your user slice as delegated, letting your unprivileged processes create and configure cgroups inside their own subtree. That delegation is the mechanism rootless Podman depends on to apply --memory, --cpus, --cpu-shares, and --pids-limit.

The systemd cgroup flag passed, but systemd support ... is not available message means the OCI runtime was told to use the systemd cgroup manager but could not drive systemd’s cgroup interface on this host — typically because the host booted with the v1 (or hybrid) hierarchy, or because the runtime binary was built without systemd support. The separate Resource limits are not supported and ignored on cgroups V1 rootless systems warning is Podman being explicit that it accepted your flags and then silently did nothing with them, which is far more dangerous in production than an outright error: your memory cap simply is not there.

Common Causes

• The host booted with systemd.unified_cgroup_hierarchy=0 or defaults to hybrid mode (older distro releases, some container-host images).
• Podman or the OCI runtime is configured for cgroup_manager = "systemd" while the host provides only v1.
• The runtime binary (runc/crun) was compiled without systemd cgroup support.
• Running rootless on v1, where delegation is impossible, so limits are accepted and ignored.
• The user slice exists on v2 but memory or cpu is missing from the delegated cgroup.controllers set.
• Running inside a nested container or VM image whose /sys/fs/cgroup was mounted read-only or as v1 by the outer runtime.

Diagnostic Commands

Detect the hierarchy version. cgroup2fs means v2; tmpfs means v1 or hybrid:

stat -fc %T /sys/fs/cgroup
mount | grep -E 'cgroup2?|cgroup '

Ask Podman directly what it sees and which manager it will use:

podman info --format '{{.Host.CgroupVersion}}'
podman info --format '{{.Host.CgroupManager}}'
podman info --format '{{.Host.CgroupControllers}}'
podman info --format '{{.Host.OCIRuntime.Name}} {{.Host.OCIRuntime.Version}}'

On v2, check what your user slice was actually delegated. If memory and cpu are absent here, --memory and --cpus will not work no matter what else you fix:

cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers
cat /sys/fs/cgroup/cgroup.controllers
cat /sys/fs/cgroup/cgroup.subtree_control

Confirm the kernel command line that produced the current hierarchy:

cat /proc/cmdline

Verify the runtime can actually be driven, with debug logging:

podman --log-level=debug run --rm --memory=256m docker.io/library/alpine:latest true 2>&1 \
  | grep -iE "cgroup|systemd|limit"

Step-by-Step Resolution

1. Establish the ground truth before changing anything:

stat -fc %T /sys/fs/cgroup   # expect: cgroup2fs
podman info --format '{{.Host.CgroupVersion}} / {{.Host.CgroupManager}}'

2. If the host is on v1 or hybrid, switch it to the unified hierarchy at boot. On a GRUB-based distro:

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"
sudo reboot

Or edit /etc/default/grub and regenerate:

GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"

sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # or /boot/grub/grub.cfg on Debian/Ubuntu

3. After reboot, confirm the switch took effect:

stat -fc %T /sys/fs/cgroup
podman info --format '{{.Host.CgroupVersion}}'

4. If you are on v2 but memory/cpu are missing from the delegated controllers, add a delegation drop-in for the user manager:

sudo mkdir -p /etc/systemd/system/user@.service.d
sudo tee /etc/systemd/system/user@.service.d/delegate.conf >/dev/null <<'EOF'
[Service]
Delegate=cpu cpuset io memory pids
EOF
sudo systemctl daemon-reload

Log out and back in, then re-check:

cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers

5. Align the cgroup manager with the host. On v2 use systemd; on a v1 host that you cannot reboot, use cgroupfs so the runtime stops asking systemd for something it cannot provide:

podman --cgroup-manager=cgroupfs run --rm docker.io/library/alpine:latest true

Make it persistent in ~/.config/containers/containers.conf (rootless) or /etc/containers/containers.conf (rootful):

[engine]
cgroup_manager = "cgroupfs"

6. Verify limits are genuinely enforced rather than silently dropped. Read the value back from inside the container:

podman run --rm --memory=512m docker.io/library/alpine:latest \
  cat /sys/fs/cgroup/memory.max

A value of 536870912 means the limit is real. If it prints max, or the file does not exist, the limit was ignored and you are still effectively on v1 or missing the memory controller. If the run fails before reaching this point with an sd-bus error instead, see crun sd-bus transport endpoint is not connected.

Prevention

• Standardize on cgroups v2 hosts; make stat -fc %T /sys/fs/cgroup returning cgroup2fs a provisioning assertion.
• Ship the user@.service Delegate= drop-in in your base host configuration so every account gets memory and cpu.
• Assert enforcement in CI by reading /sys/fs/cgroup/memory.max inside a test container rather than trusting the flag.
• Treat Resource limits are not supported and ignored as an error in log pipelines — it is a silent capacity risk.
• Keep cgroup_manager in a managed containers.conf rather than relying on per-invocation flags.
• Pair cgroup delegation with loginctl enable-linger so the user slice exists for non-interactive workloads.

Related Errors

• crun: sd-bus call: Transport endpoint is not connected — the user session bus is missing, a delegation prerequisite. See crun sd-bus transport endpoint.
• cannot set memory limit: cgroup controller not available — v2 is active but memory was not delegated to your slice.
• cannot re-exec process — user-namespace setup failure, unrelated to cgroups. See cannot re-exec process.
• OCI runtime error: unable to apply cgroup configuration — the runtime reached the hierarchy but could not write it, often a read-only /sys/fs/cgroup in nested containers.

Frequently Asked Questions

Can rootless Podman enforce --memory on cgroups v1? No. v1 offers no safe delegation to unprivileged users, so Podman prints the “not supported and ignored” warning and runs the container with no limit. Only v2 with a delegated memory controller enforces it.

Is switching to the unified hierarchy risky for other workloads? Modern container runtimes all support v2, but very old tooling may not. Change it on one host, verify your full stack, then roll out — and remember it requires a reboot.

Why do --cpus and --memory fail while the container itself starts fine? Container startup only needs a cgroup to exist; enforcing limits needs the specific cpu/memory controllers delegated. Check cgroup.controllers in your user@UID.service path.

Should I just use --cgroup-manager=cgroupfs everywhere? It avoids the systemd dependency but gives up delegation, reliable rootless limit enforcement, and clean integration with systemctl --user units. Use it only where v2 is unavailable. For more, see the Podman guides.