systemd-cgtop is a read-only Linux command that displays resource usage by control group (cgroup) rather than by an individual process. On a systemd-managed server, groups of processes are organized into services, slices, and scopes. A technician can use the utility to identify which workload hierarchy consumes CPU time, memory, tasks, or block I/O and decide what to investigate next without stopping services or changing resource limits.

Linux Command #67 follows Command #66 — coredumpctl, which investigates application crashes, and Command #65 — systemd-analyze, which examines service startup. Resource monitoring is the next diagnostic skill: a service may start correctly and never crash, yet consume excessive memory or CPU at runtime.

Learning Objectives and Prerequisites

• Explain how Linux control groups organize and account for resources consumed by related processes.
• Interpret systemd-cgtop group paths, task counts, CPU percentages, memory, and disk I/O fields without confusing them with per-process utilization.
• Run a bounded, read-only snapshot with batch mode, ordering, depth limits, and iteration counts.
• Identify when missing CPU, memory, or I/O values reflect controller availability, accounting settings, sampling, or container visibility.
• Contrast the process view of top with the hierarchical group view of systemd-cgtop.
• Apply a documented troubleshooting workflow for a high-resource workload without changing service policies.

Prerequisites are basic Linux shell navigation, familiarity with services from What Is systemd?, and an understanding that a service may consist of multiple processes or threads. The command is part of systemd, not a portable POSIX command; behavior and visibility depend on the host operating system, version, privilege level, kernel, and container environment.

A Control Group Measures a Workload, Not Merely a PID

A control group is a kernel mechanism for grouping processes for resource accounting and control. A systemd service such as a web server may create worker processes, but an operator generally needs to know what the entire service consumes. On a typical systemd host, paths such as /system.slice/ contain system services, /user.slice/ contains user-related workloads, and sometimes /machine.slice/ contains virtual machines or container scopes. The exact hierarchy differs among installations.

Cgroups are also used by many container runtimes, so an isolated container may reveal only its delegated subtree rather than a complete physical host. The Linux kernel’s cgroup v2 documentation describes the unified hierarchy and controller interfaces; the official systemd-cgtop manual specifies the display and command-line options.

The Linux Foundation, “Modern Linux Servers with cgroups,” presented by Brandon Philips of CoreOS at LinuxCon/CloudOpen North America (October 1, 2013). Historical background on cgroup-based service isolation; it predates today’s widespread cgroup v2 operation and should not be used as a current configuration guide.

What the CPU, Memory, Tasks, and I/O Columns Mean

The terminal display can rank groups by CPU, memory, disk I/O, task count, or path. CPU percentage measures activity across available processors: it is not necessarily capped at 100%. For example, on an eight-logical-CPU server, a workload reported at 240% is consuming approximately 2.4 CPU equivalents during the sample, or 240 ÷ 800 = 30% of the host’s aggregate logical CPU capacity if each logical CPU is treated equally for the rough calculation. The value is not a direct measure of completed work, application efficiency, or power draw.

Memory values represent accounted memory used by the group according to the active controller and hierarchy. Disk I/O columns refer to measured I/O activity where the appropriate I/O controller and accounting are available; they are not Ethernet network bandwidth. A task count can include threads, and the command’s -P switch is available when process counting rather than the default task counting is needed. Cgroup hierarchy totals can include descendants, so blindly summing parent and child rows may double-count usage.

The upstream manual warns that memory and I/O values may be unavailable without enabled controllers and accounting. On a relevant unit, MemoryAccounting= and IOAccounting= control systemd accounting. A dash is therefore not equivalent to zero activity. CPU accounting behavior has changed across systemd versions and cgroup modes; use the documentation matching the deployed release before drawing conclusions.

Begin with Help, Version, and a Single Sample

Start in an unprivileged terminal. The first commands are inspection-only and show which syntax the installed version supports:

systemd-cgtop --version systemd-cgtop --help

The example was tested in a restricted Debian GNU/Linux 13 environment with systemd 257.9. The locally installed help output supported --order=, --batch, --iterations=, --depth=, --raw, and --cpu=. The flags have also been checked against the official systemd reference, but another distribution may ship a different release.

For a non-interactive one-shot observation, use a bounded batch command. It does not change the service configuration:

systemd-cgtop --batch --iterations=1 --order=memory --depth=2

On the tested container, the command completed and displayed only the root cgroup, with an observed sample resembling the following single line. The values are environment-specific and will differ on other machines:

/ 66 - 479.9M - -

The container used supervisord rather than systemd as PID 1 and exposed only its restricted cgroup namespace. The absence of individual service rows was an environment limitation, not proof that the host had no running services. For a complete systemd host, an interactive terminal usually displays many service and user groups when permitted. Non-TTY batch output omits column headers, so do not assume the values can be parsed without checking the relevant version’s output format.

Get a More Useful CPU Sample

CPU rate measurement benefits from repeated observations. The following command reads two iterations, stops automatically, orders by CPU, and inspects a deeper control-group tree. Some environments show a dash or incomplete rates for the initial sample because a time interval is needed:

systemd-cgtop --batch --iterations=2 --order=cpu --depth=4

The --batch option disables interactive input, --iterations=2 bounds output, --order=cpu selects the primary sort, and --depth=4 permits deeper traversal than the default. No sudo is required for the examples, although unprivileged access may omit protected details. Production scripts should not assume column positions never change across systemd versions.

On an interactive host, running systemd-cgtop without --batch refreshes the display at regular intervals. It resembles top, but each row names a cgroup instead of an individual PID. Stop the program with the terminal’s standard interrupt if necessary.

Sort by Memory, I/O, Tasks, or Group Path

Sorting helps isolate the kind of resource pressure under investigation. The flags below are read-only, use one iteration, and produce manageable terminal output:

systemd-cgtop --batch --iterations=1 --order=memory systemd-cgtop --batch --iterations=1 --order=io systemd-cgtop --batch --iterations=1 --order=tasks systemd-cgtop --batch --iterations=1 --order=path

Sort order is not a diagnosis by itself. A high memory footprint can be normal for a cache or database; a process tree with many tasks can be expected for a multi-worker service. Correlate resource reports with established baselines, system performance, error logs and the service’s actual responsibilities. A CPU hotspot may show activity while the application’s real bottleneck is I/O wait or an external service.

The tool also supports --cpu=time for CPU time display and --raw for numeric byte counts rather than human-readable units. The -P option counts user-space processes instead of all tasks; read the manual before mixing it with other task-count options.

LinuxCloudHacks, “Systemd Tutorial: User Resource Limits (Stop Resource Exhaustion & Boost Linux Stability)” (March 30, 2025). The demonstration explains systemd slices and explicitly uses systemd-cgtop alongside other management tools. The video includes resource-control changes and a destructive process-stress demonstration; the present lesson does not instruct readers to reproduce those risky steps on production equipment.

Inspect the Hierarchy Without Editing It

If systemd-cgtop identifies a busy slice but the group name is difficult to interpret, use the separate systemd-cgls utility to view the hierarchy of processes. Then inspect known service accounting fields through systemctl show. All of the following examples are read-only, but some require a working systemd manager:

systemd-cgls --no-pager systemctl show --property=CPUAccounting,MemoryAccounting,IOAccounting example.service

Replace example.service with the real, authorized unit name before running systemctl show. Do not interpret a failure to connect to the system manager in a container as a host-service failure. A restricted container without systemd as PID 1 may have cgroup filesystem access while systemctl’s service-management interface is unavailable.

On systems using the unified cgroup v2 hierarchy, the following read-only file can show controllers available to the current cgroup:

cat /sys/fs/cgroup/cgroup.controllers

In the local test container, the controllers listed were cpuset cpu io memory hugetlb pids. Availability in cgroup.controllers does not prove that every controller is enabled in every descendant. The kernel documentation distinguishes available controllers from delegated or enabled controller interfaces; check the target scope before relying on a particular metric.

Worked Diagnostic Scenario: A Busy Data Center Service

Assume a hypothetical eight-logical-CPU Linux system running a network telemetry service. The operator observes its cgroup at 240% CPU for several intervals, approximately 2.4 logical CPUs, or 30% of the machine’s theoretical aggregate CPU percentage range. The same service reports 1.5 GiB of accounted memory on a machine with 16 GiB of physical RAM. Relative to the chosen 16 GiB denominator, that is 1.5 ÷ 16 × 100 = 9.375%. The calculation is explanatory and does not mean every memory category is represented in that metric.

Neither measurement alone establishes a fault. The operator asks whether workload volume increased, whether the service’s response time changed, whether swap pressure or I/O wait appeared, and whether new errors were recorded. A rising task count can suggest more worker threads or a runaway task-creation condition, but a snapshot cannot distinguish the possibilities.

The next checks connect the current observation to journalctl for service error logs and ss for network socket inventory. A technician might use systemd-cgtop to identify an overloaded service, then investigate whether frequent reconnections, invalid requests, application bugs or normal demand explain the utilization. A proposed quota or service restart requires change approval and a rollback plan.

Lab: Compare Observations and Report Limitations

1. Confirm the installed command’s version with systemd-cgtop --version and preserve the distribution information.
2. Collect one bounded memory-ordered snapshot with --batch --iterations=1, noting whether the environment is a full systemd host or container.
3. Collect two CPU-ordered iterations without changing any unit configuration. Record whether the first and second samples differ.
4. Inspect the control-group tree with systemd-cgls --no-pager if the current environment permits it.
5. Record missing metrics honestly: an unavailable column, a restricted namespace, lack of privileges, or disabled accounting may make the observation incomplete.
6. Choose an existing service and compare its relevant accounting properties with systemctl show. Use read-only commands and avoid changing units on shared infrastructure.
7. Write a short diagnostic report stating the systemd release, timestamp, commands, cgroup path, observation, uncertainty, and safe next step.

Avoid load generators, fork bombs, service restarts, setting CPU quotas, or modifying slice configurations on production systems as part of the introductory exercise. The lab is complete when a learner can explain what the utility could and could not observe, even if the sandbox shows only the root control group.

Common Failure Modes and Correct Interpretation

• No command found: confirm the installed systemd packages, distribution, and path. Some containers and minimal systems omit the tool.
• No service rows: check whether the container sees a limited cgroup namespace and whether systemd is acting as the host service manager.
• Dash in the I/O column: investigate whether the relevant controller and I/O accounting are available; do not read it as zero disk traffic.
• CPU above 100%: multi-CPU workloads can consume more than one logical CPU. The result is not a syntax error.
• Unexplained parent totals: remember that the hierarchy is nested; summing both parents and children can inflate totals.
• Unexpected task count: distinguish kernel threads, user threads, processes, and the -P counting option.
• Different output from a manual screenshot: compare versions, terminal versus batch display, controller state, and system load.
• Performance still poor with low cgroup CPU: consider I/O latency, locks, network dependencies, throttling or stalled external services rather than assuming the CPU view covers every bottleneck.

Knowledge Check With Explanations

1. What is the key difference between top and systemd-cgtop? The latter organizes resource usage by cgroup, which may contain many processes or threads, instead of primarily listing individual processes.
2. How can a group show 240% CPU? It can consume 2.4 logical CPU equivalents on a multi-processor machine during a sample. The theoretical aggregate on eight logical CPUs is up to 800%.
3. Does a dash in an I/O column mean no disk operations? No. Data can be absent because of controller, accounting, or visibility limitations.
4. What does --iterations=2 change? It stops the program after two measurement iterations, which is appropriate for bounded batch diagnostics.
5. Why might a container display only the root cgroup? Namespace delegation and restricted visibility can prevent it from seeing the host’s complete group hierarchy.
6. What is a safe next check after finding a busy service? Correlate with service state, logs, load baseline and accounting settings before proposing operational changes.
7. Why should parent and child utilization not always be added? Hierarchical group totals can already account for descendant usage.
8. What did the local test prove? systemd 257.9 recognized the documented flags and returned a root-group snapshot in an isolated container; it did not validate complete host-level service attribution.

Official Documentation and Further Reading

Primary sources: systemd-cgtop(1) upstream manual; systemd.resource-control(5); systemd-cgls(1); systemctl(1); and the Linux kernel cgroup v2 administrator guide. The original lesson’s video materials provide historical cgroup context and a practical systemd administration demonstration, not a substitute for the version-matched man page.

Elementary Conclusion

systemd-cgtop helps a Linux technician connect resource usage to operational units. Its strength is the control-group view: a service or slice can be investigated as a workload instead of as a collection of unrelated PIDs. Its limitation is that the numbers depend on accounting, permissions, sampling, kernel support, and the visible hierarchy. Accurate diagnosis requires confirming those conditions and correlating metrics with established baselines and service behavior.

Editor’s Note: Linux Command #67 follows the published Command #66 and preserves the full Open Source Tech Cert subject rotation, including specialty and programming tracks. The systemd 257.9 --help and a bounded systemd-cgtop snapshot were executed in Debian GNU/Linux 13, inside a limited container that exposed only the root cgroup. No production service was modified. The CPU and memory percentages in the worked example are hypothetical calculations. The editorial cover and two in-body photographs are AI-generated conceptual illustrations, not screenshots of the executed terminal. Embedded videos are credited to their source channels; server-rendered iframe verification and interactive playback are tracked separately.

For mobile scanning, display the lesson and original QR code on a computer or second screen, then scan it using a compatible Bitcoin wallet. On the same phone, a wallet may support scanning an image saved from the page. Verify the destination before sending 5,000 sats: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb.

We volunteer daily to ensure the information on this platform is Verifiably True. If you would like to support the research, please scan the original donation QR code to contribute 5,000 sats.

BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.