Repository navigation
linux: do not treat every PID namespace as a container - #2140
ravi-arnan wants to merge 1 commit into
Conversation
"Hide processes running in containers" compares each process's /proc/PID/ns/pid inode with htop's own and treats any difference as a container, falling back to counting NSpid: entries when that stat is not permitted. A PID namespace is not a container. Chromium's sandbox, bubblewrap and plain unshare(1) all create one inside an ordinary desktop session, so on a machine with a browser open the option hides most of the process list even though nothing is containerized. Measured on a host with no containers running: 903 of 2739 tasks hidden, every one of them a Brave or Chrome sandbox task. Confirm the namespace difference against the cgroup, which is the signal that actually separates the two cases. htop already derives a container name from the cgroup for the CONTAINER column, so the hide option and that column now agree with each other. Container runtimes either label the cgroup, which CGroup_filterContainer() already recognises for docker, podman, LXC and systemd-nspawn including their rootless variants under user.slice, or they place the payload outside user.slice, as Kubernetes and the CRI runtimes do. A sandbox stays in the session's own user.slice cgroup with no label. The cgroup file is read only for the processes that showed a namespace difference, unless a cgroup column is displayed anyway, so the common case costs nothing. Closes htop-dev#2053 Assisted-by: Claude:opus-5
|
No actionable comments were generated in the recent review.
 |
| Objective | Addressed | Explanation |
|---|---|---|
Ensure enabling “Hide processes running in containers” does not hide processes on a system without containers [#2053] |
✅ |
Suggested reviewers: cgzones, benbe
Priority:
Change: Bug fix · Severity of issue fixed: Medium
Merge Risk: 
39624
-
Some container processes with mixed cgroup-v1 paths may remain visible when container hiding is enabled. This bounded case does not appear to block merging.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A cgroup path enters the test
A user slice is set apart
Container labels guide the check
Namespace flags receive a review
Ordinary processes stay in view
Comment @coderabbitai help to get the list of available commands.
Closes #2053
Problem
"Hide processes running in containers" (
O/ Display options) compares each process's/proc/PID/ns/pidinode with htop's own and treats any difference as a container, falling back to countingNSpid:entries when that stat is not permitted.A PID namespace is not necessarily a container. Chromium's sandbox, bubblewrap, flatpak runners, and plain
unshare(1)all create one inside an ordinary desktop session. On a desktop machine with a browser open, enabling the option hides most of the process list even though nothing is containerized.Measured on a host with no containers running: 903 of 2,739 tasks hidden, every one of them a Brave or Chrome sandbox task.
The change
Confirm the namespace difference against the cgroup, which is the signal that actually separates real containers from desktop process sandboxes:
CGroup_looksLikeContainer(const char* cgroup):CGroup_filterContainer()(docker, podman, LXC, systemd-nspawn, including rootless variants underuser.slice).user.slice(such as Kubernetes underkubepods, or system services/containers undersystem.slice).user.slicewith no container label, so they are not treated as containers.CONTAINERcolumn now agree with each other./proc/PID/cgroupis read only for the few processes that showed a namespace difference (unless a cgroup column is already enabled in the screen settings), so the common case costs no extra file operations.Verification
Tested locally on Linux (NixOS, Linux 6.17.0, x86_64):
docker run --rm -d alpine sleep 60):sleep 60process has its cgroup identified (docker-...) and is correctly hidden when "Hide processes running in containers" is enabled.-std=c99 -pedantic -Wall -Wextra, 0 errors.