How Does htop Manage Container Processes?

The htop command-line utility provides a dynamic, real-time view of a Linux system’s running processes, including those operating inside isolated containers like Docker or LXC. Because containers share the host system’s Linux kernel, htop running on the host naturally sees and displays all containerized processes alongside standard host processes. However, without proper configuration, distinguishing which process belongs to which container can be challenging. This article explores how htop interacts with containerized environments, how to identify container processes using built-in features, and how to run htop inside a container to isolate its view.

The Host View: Kernel Sharing and Visibility

Unlike traditional virtual machines that run their own isolated guest kernels, containers leverage host kernel features called namespaces (for isolation) and cgroups (for resource limiting). Because of this shared-kernel architecture, the host operating system’s process table contains every single process running on the machine, regardless of whether it is inside a Docker container, an LXC container, or running natively on the host.

When you run htop directly on the host system, it reads data from the /proc filesystem. Since the host’s /proc directory has visibility into all namespaces, htop displays containerized processes by default.

Identifying Container Processes in htop

While htop shows container processes automatically, they initially look identical to standard host processes. To differentiate them, htop offers specific features and columns that map processes back to their respective containers:

• The Container Column: Modern versions of htop include a dedicated CONTAINER column. When enabled, this column displays the name or ID of the container (such as the Docker container name) handling that specific process.
• Virtual Environment (VIRTUAL) Column: Similar to the container column, this field identifies the virtualization or containerization technology associated with the process.
• Filtering by cgroups: You can add the CGROUP column to htop. Since container runtimes organize containers into specific cgroup pathways (e.g., /docker/simulation... or /system.slice/docker-...), reading the cgroup path allows you to pinpoint the exact container origin.

To enable these columns, press F2 (or S) to enter the Setup menu, navigate to Columns, select the desired column from the available choices, and add it to your active display.

Tree View and Process Hierarchy

Another powerful way to analyze containerized workloads in htop is by enabling the Tree View (by pressing F5).

Container engines run a main daemon process on the host (like dockerd for Docker or containerd). When a container starts, the engine spawns shim or runtime processes, which then act as the parents to the actual applications running inside the container. Tree view visually maps this hierarchy, allowing you to see exactly which application processes are children of the Docker or LXC daemon.

Running htop Inside a Container

If you execute htop inside a specific Docker or LXC container rather than on the host, its behavior changes due to namespace isolation:

• PID Namespace Isolation: By default, a container is restricted to its own Process ID (PID) namespace. Inside the container, htop will only see the processes running within that specific container, mapping the container’s primary application as PID 1.
• The Host PID Flag: If you need htop to run from a containerized administrative tool but still view the entire host system, you must bypass this isolation. For Docker, this is achieved by passing the --pid=host flag during execution:

docker run --rm -it --pid=host --privileged pidone/htop

This command grants the containerized htop instance full visibility into the host’s process table, mirroring the behavior of running the tool directly on the host machine.