When should you NOT use cgroups — Linux Control Groups?

You control the whole machine and trust every process on it — plain ulimit may suffice. Running on a non-Linux OS — macOS and Windows containers use different mechanisms.

When is cgroups — Linux Control Groups the right choice?

You need to cap resource usage per process group — mandatory for multi-tenant hosts. Debugging OOM kills or CPU throttling in containerised workloads. Building a container runtime or systemd-delegated service manager.

← Back to glossary

cgroups — Linux Control Groups

linux Advanced

Also Known As

Control Groups cgroup cgroups v2

TL;DR

A Linux kernel feature that groups processes and meters or limits their access to CPU, memory, I/O, network, and other resources — the core primitive that makes Docker, systemd, and Kubernetes resource limits possible.

Explanation

Control groups (cgroups) let the kernel organise processes into hierarchical groups and enforce resource controls per group. Each 'controller' (cpu, memory, io, pids, etc.) tracks and can cap usage for every process in the group. cgroups v1 used one directory tree per controller under /sys/fs/cgroup/<ctrl>/, while cgroups v2 (default on most modern distros) unifies them under a single /sys/fs/cgroup/ tree with a single hierarchy. When you run 'docker run --memory 512m', Docker writes 536870912 to memory.max inside a cgroup it creates for the container. Kubernetes resource requests and limits, systemd service memory caps, and PHP-FPM pool limits via Unit delegation all ultimately configure cgroups. Understanding cgroups is what separates people who can debug 'why is my container being OOM-killed' from people who just add more memory and hope.

Common Misconception

✗ cgroups and namespaces are often lumped together as 'container tech', but they do different jobs: namespaces give processes their own view of the system (PIDs, network, mounts), while cgroups enforce how much of the real system each group can consume. A container needs both.

Why It Matters

Every container runtime, every systemd unit's MemoryMax, every Kubernetes pod's resource limit — they all reduce to cgroup writes. When something gets OOM-killed in a container, 'dmesg' shows the cgroup that tripped the limit. Without cgroups, one noisy neighbour process can starve the entire host.

Common Mistakes

Confusing cgroups v1 and v2 paths — v1 has /sys/fs/cgroup/memory/, /sys/fs/cgroup/cpu/ etc.; v2 has a single /sys/fs/cgroup/ tree with cgroup.controllers listing active controllers.
Setting memory.max without considering memory.swap.max — a process can escape a memory cap if swap is uncapped.
Forgetting that cgroup OOM kills the whole container in most runtime configs — set memory requests above typical spikes to avoid churn.
Reading /proc/<pid>/cgroup expecting meaningful output inside a container — you see the cgroup path relative to the container's namespace, not the host.
Confusing CPU shares (relative weight) with CPU quota (hard cap) — shares only matter when CPU is contested; quota caps regardless.

Avoid When

You control the whole machine and trust every process on it — plain ulimit may suffice.
Running on a non-Linux OS — macOS and Windows containers use different mechanisms.

When To Use

You need to cap resource usage per process group — mandatory for multi-tenant hosts.
Debugging OOM kills or CPU throttling in containerised workloads.
Building a container runtime or systemd-delegated service manager.

cgroups — Linux Control Groups

Also Known As

TL;DR

Explanation

Common Misconception

Why It Matters

Common Mistakes

Avoid When

When To Use

References

Tags

cgroups — Linux Control Groups

Also Known As

TL;DR

Explanation

Common Misconception

Why It Matters

Common Mistakes

Avoid When

When To Use

References

Tags

Related Terms