Linux / Advanced: boundaries, security, and recovery / Lesson 15

Read cgroup policy and workload boundaries

Use cgroup v2 concepts to understand resource organization, limits, delegation, and workload termination without tuning the host.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Distinguish cgroups from namespaces and traditional process limits.
Interpret memory protection, hard limits, and event counters.
Read systemd resource policy as part of service design.

Cgroups organize processes hierarchically

Cgroup v2 provides a unified hierarchy that organizes processes and exposes controllers for selected resources. A process belongs to a cgroup, and children normally inherit membership at creation. Moving a parent later does not automatically move every existing descendant. Namespaces govern views; cgroups govern resource organization and control. Traditional per-process limits remain useful but are not a substitute for a group-wide boundary covering a service’s descendants. Confirm whether the system uses v2 or a legacy arrangement before interpreting files, because v1 paths and controller semantics differ.

Read before writing controller files

/proc/self/cgroup describes the observing process’s membership as visible from its context. On a usual v2 mount, cgroup.controllers lists controllers available for distribution to children, while cgroup.subtree_control describes enabled controllers for descendants. Availability is not the same as an applied limit. A container may see a delegated subtree rather than the host root. Never write directly into a manager-owned hierarchy simply because the files look editable: doing so can conflict with the manager’s accounting, lifecycle, and delegation rules. Use the supported service-manager interface for planned policy.

bash Inspect the visible v2 context

cat /proc/self/cgroup
findmnt -t cgroup2
cat /sys/fs/cgroup/cgroup.controllers

The final path assumes a conventional v2 mount. Its contents depend on kernel support and delegation. These commands read state only and do not enable controllers or move processes.

Protection, pressure, and limits differ

memory.current reports accounted usage for a cgroup and its descendants. memory.high establishes a throttling and reclaim boundary that pressures the workload without acting as an absolute allocation ceiling. memory.max is a hard boundary that can lead to an out-of-memory action when reclaim cannot satisfy demand. memory.low and memory.min express protection with different guarantees and hierarchy constraints. Interpret event counters and ancestor policy together; a child can be affected by an enclosing limit even when its own file appears unlimited. Do not diagnose every terminated process as a cgroup OOM without evidence.

Express workload policy through the manager

systemd resource-control settings map service intentions to kernel controls where supported. MemoryHigh= can express a normal pressure boundary, MemoryMax= a last-resort limit, and TasksMax= a task-count boundary including threads. CPUWeight= is relative to competing siblings, whereas CPUQuota= expresses a different kind of ceiling. These are policy concepts rather than a general performance-tuning recipe. Choose limits from application requirements and failure behavior, and validate compatibility with the installed systemd and kernel. Resource policy must leave enough capacity for legitimate startup and recovery work.

bash Read a synthetic worker’s resource contract

systemctl show example-worker.service -p ControlGroup -p MemoryHigh -p MemoryMax -p TasksMax
systemctl cat example-worker.service

On a disposable image containing the fictional unit, inspect both effective properties and source configuration. This does not install a drop-in, change limits, or restart the service.

Delegation is an ownership boundary

A delegated subtree allows a trusted manager to organize descendants within granted boundaries; it is not unrestricted control of the entire host hierarchy. Keep one clear owner for each part of the tree. During an incident, capture membership, effective ancestor limits, controller events, unit result, and application logs before changing policy. An OOM event can explain a termination without explaining why memory demand increased; continue to the triggering workload or leak investigation. Recovery should restore useful behavior while preserving evidence, and persistent policy changes need a reproducible lab check.

Common errors and fixes

memory.high is treated as a hard ceiling

Why it happens: Pressure control was confused with a hard allocation boundary.
How to fix it: Read memory.max and controller events separately.
Prevent it next time: Document whether a setting protects, pressures, or limits.

A child appears unlimited but is constrained

Why it happens: An ancestor’s limit was omitted from the investigation.
How to fix it: Inspect the effective hierarchy and manager properties.
Prevent it next time: Review policy along the whole ancestry.

Direct writes conflict with systemd policy

Why it happens: Two managers changed the same resource hierarchy.
How to fix it: Use the supported owner’s policy interface in the lab.
Prevent it next time: Define delegation and ownership before automation.

Check your understanding

1. A worker dies and its unit reports an OOM-related result. What remains to be proved?

Show worked solution

Correlate time, cgroup events, membership, and ancestor limits to establish the relevant boundary. Then identify why demand exceeded the intended policy and whether the application handled pressure correctly. Raising a limit alone does not establish or remove the cause.

2. Why can TasksMax affect a multithreaded program with few visible processes?