cgroupfs vs systemd

When people talk about cgroupfs vs. systemd, they are usually talking about which Cgroup Driver a container runtime (like Docker or containerd) should use to manage system resources (CPU, Memory).

Think of cgroupfs as the "Raw" approach and systemd as the "Managed" approach.

cgroupfs: The Raw Kernel Interface

cgroupfs is the virtual filesystem that the Linux kernel provides at /sys/fs/cgroup.

• How it works: To manage resources, you interact directly with files and folders.
  • Want a new group? mkdir /sys/fs/cgroup/memory/my-container
  • Want to limit memory? echo 500M > /sys/fs/cgroup/memory/my-container/memory.limit_in_bytes
  • Want to add a process? echo [PID] > /sys/fs/cgroup/memory/my-container/cgroup.procs
• Pros: It is simple, has no dependencies, and works even if you don't have an init system like systemd.
• Cons: It is "dumb." It doesn't know about the rest of the system's services. If two different programs try to edit the same file, they can overwrite each other.

systemd: The Central Manager

On most modern Linux distributions (Ubuntu, Debian, RHEL, Fedora), systemd is the "init system" (the first process that starts). Because systemd manages services, it also insists on managing the cgroup hierarchy.

• How it works: You don't touch the files in /sys/fs/cgroup yourself. Instead, you send an IPC message (via D-Bus) to systemd saying, "Please create a slice for this container with these limits." Systemd then does the file-writing for you.
• Pros: It provides a single source of truth. It knows about every service, cron job, and container on the system and ensures they don't conflict.
• Cons: It is more complex and adds a dependency on the systemd daemon.

The "Single Writer" Problem

This is the most important concept. Linux Cgroups (especially Cgroup v2) are designed with a "Single Writer" rule. This means only one piece of software should be writing to the cgroup filesystem.

• The Conflict: If your OS is running systemd, then systemd already thinks it owns /sys/fs/cgroup.
• The Mess: If you configure Docker or Kubelet to use the cgroupfs driver, they will start writing to those files directly. Now you have two "bosses" (systemd and the container engine) fighting over the same files.
• The Result: Under heavy load, the system becomes unstable. Systemd might try to move a process that the container engine just locked, or vice versa, leading to "zombie" processes or containers that refuse to stop.

Comparison Table

Feature	cgroupfs Driver	systemd Driver
Mechanism	Writes directly to /sys/fs/cgroup	Talks to systemd via D-Bus
Organization	Flat or nested folders	Structured into Slices and Scopes
Cgroup v2 Support	Limited/Difficult	Native and Full
Primary User	Docker (Legacy), Non-systemd OS	Kubernetes (Standard), Modern Docker
Stability	Risk of conflict with OS	High (Aligned with OS)

Why Kubernetes mandates systemd

For a long time, Docker defaulted to cgroupfs. However, Kubernetes now strongly recommends (and sometimes requires) the systemd driver.

1. Cgroup v2: Modern Linux is moving to Cgroup v2, which is much stricter about the "Single Writer" rule. systemd is the only reliable way to manage Cgroup v2 on a modern distro.
2. Node Pressure: When a Kubernetes node runs out of memory (OOM), the Kubelet needs to know exactly which process is the culprit. If systemd and Kubelet have different views of the cgroups, the Kubelet might kill the wrong process or fail to see the pressure entirely.
3. Unified Hierarchy: Using the systemd driver allows you to see your containers in standard tools like systemd-cgtop alongside system services.