"Hide processes running in containers" hides nearly all processes when no containers are running

[tuchango]

Description

Enabling "Hide processes running in containers" (O / Display options) hides
almost the entire process list on a plain desktop Linux install with no
containers currently running. Only a single process (ksecretd, a KDE
component) remains visible; every other process, including the shell and
htop itself, disappears from the list.

Disabling the option immediately restores the full process list.

Steps to reproduce

1. On a plain Arch Linux + KDE Plasma desktop with no containers running.
2. Start htop.
3. Press O (or enable "Hide processes running in containers" via F2 →
   Display options).
4. Observe: the process list collapses to a single process.
5. Press O again (or disable the option) — the full process list returns
   immediately.

Expected behavior

Since no processes are actually running inside containers on this system,
enabling the option should have no visible effect on the process list.

Actual behavior

Nearly all processes disappear, as if they were being misidentified as
"running in a container".

Environment

• OS: Arch Linux
• DE: KDE Plasma
• htop version: 3.5.2-1-arch

Additional info

$ cat /proc/self/status | grep NSpid
NSpid:  108407
$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/user@1000.service/app.slice/kitty-104783-0.scope

I noticed some related discussion in PR #1062 about timing issues with the
container-detection logic when the option is toggled, though that seemed to
be about a temporary lag rather than persistently misclassifying almost all
processes as containerized. Not sure if this is the same root cause or a
separate bug.

[ravi-arnan]

I would like to work on this. Reproduced against upstream main (936b39d) on a
machine with no containers running, and the mechanism is measurable.

What the code does

linux/LinuxProcessTable.c:1650 compares each process's /proc/PID/ns/pid
inode against htop's own and treats any mismatch as "running in a container".
When that stat is not permitted, LinuxProcessTable_readStatusFile() falls back
to counting the entries on the NSpid: line and treats more than one the same
way.

Why that hides ordinary processes

A PID namespace is not a container. Chromium's sandbox puts its renderers in
their own PID namespace, so on a plain desktop with a browser open every one of
those tasks is classified as containerized.

Measured here (Zorin 18.1, GNOME/X11, Brave and Chrome open, zero containers
running), instrumenting the classification and counting distinct PIDs over one
six second run with the option enabled:

	tasks
classified not in a container	1836
classified in a container, hidden	903

No task was classified both ways. Every one of the 903 was a Brave or Chrome
sandbox task (ThreadPoolForeg, Chrome_ChildIOT, PerfettoTrace, brave).

The same applies to bubblewrap and Flatpak apps, to plain unshare -p, and on
systemd 257 and newer to any unit with PrivatePIDs=yes. That last one may be
why this bites hardest on a KDE session, where most of the desktop runs as user
units that the reporting user can stat.

The cgroup is the signal that separates them

Ground truth from the same machine, a real docker container next to a Brave
renderer:

docker container   0::/system.slice/docker-32fb0502545c....scope
                   NSpid:  50011  1

brave renderer     0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@x11.service
                   NSpid:  5677  11  1

The namespace test cannot tell these apart. Only the cgroup can, and
linux/CGroupUtils.c already recognises docker-, libpod-, lxc.payload.
and machine.slice.

One more asymmetry

When the ns/pid stat fails, the process is silently left classified as not in
a container. In that run 538 of 2750 stats failed, all of them root owned
processes that an unprivileged htop may not ptrace. So the same process can be
shown or hidden depending on who runs htop, and running htop as root widens the
set that gets hidden rather than narrowing it.

Question before I write a patch

Which direction do you prefer:

1. require a container-looking cgroup, reusing what CGroupUtils.c already
   knows, in addition to the namespace difference, or
2. keep the namespace test and exclude namespaces that are descendants of the
   session htop is running in.

I lean towards 1, since it is the only one that gets the Chromium case right
without special casing a browser.

@tuchango, could you post the output of this on the affected machine? It will
confirm whether your case is the same mechanism or a second one:

for p in /proc/[0-9]*; do stat -L -c %i "$p/ns/pid" 2>/dev/null; done \
  | sort | uniq -c | sort -rn | head

Assisted-by: Claude:opus-5

[tuchango]

Thanks for digging into this — the analysis reads convincing, and option 1 makes sense to me too.

Here's the output you asked for:

for p in /proc/[0-9]*; do stat -L -c %i "$p/ns/pid" 2>/dev/null; done \
  | sort | uniq -c | sort -rn | head
     84 4026531836

It answers your question in the least useful way: the symptom no longer reproduces on my machine, and hasn't for some time. Same htop version, no config changes. I went back through my package and boot logs for the two weeks the issue was open and found nothing that lines up with when it stopped.

So I can't confirm my case was the mechanism you measured, and I can't point you at a second one either. All I can tell you is the shape of what I saw: it wasn't a subset of processes being hidden, it was nearly all of them, a couple of hundred down to 2. I was running htop as my own user.

Sorry for the loose end. Your reproduction stands on its own so I don't think the issue depends on mine, and if it comes back I'll capture proper detail before changing anything. Happy to test a patch.

[ravi-arnan]

Thanks for running it, and no need to apologise: that output is more useful than a confirmation would have been, because it rules something out.

Your case and mine are the same option but opposite orientations, and the numbers you gave are what separates them.

What I measured is a subset going away: 903 of 2739 tasks hidden, every one of them a Brave or Chrome sandbox task, on a host with no containers running. The odd namespace belongs to the processes, and htop's own baseline is the host one.

Yours is nearly everything going away, a couple of hundred down to 2. For that to happen the comparison has to fail in the other direction. htop takes its baseline from its own namespace, stat("/proc/self/ns/pid") at LinuxProcessTable.c:276, and calls every process whose inode differs a container. If htop itself is the one sitting in a nested PID namespace while still reading the host /proc, then every host process differs from it and the option hides the machine, leaving only whatever shares htop's namespace. Two survivors fits that shape exactly. I cannot prove that is what you hit and I am not going to claim it, since it no longer reproduces, but it is the only orientation that produces your ratio.

That distinction matters for the fix, so here is the honest limit of what I proposed. Confirming the namespace difference against the cgroup fixes my case completely, and in yours it would give you back the processes in your session's user.slice. It would not give you back the system daemons: system.slice is outside user.slice and carries no container label, which is exactly how a Kubernetes or CRI payload looks, so those stay hidden. So option 1 does not cover your orientation, and I would rather say that now than have you find it later.

If it ever comes back, the two numbers that settle it in one line, from the same shell you launch htop from:

stat -L -c %i /proc/self/ns/pid /proc/1/ns/pid

Two different inodes means htop's baseline is not the host namespace and the heuristic is inverted for you. Same inode means it is something else and worth a new issue.

The patch is written and measured locally. I am holding it until a maintainer picks between confirming the namespace against the cgroup and the narrower alternative, since that is a definition call rather than a bug with one obvious answer. I will ping you here when it is up, and thanks for the offer to test it.

[bibliophile17]

I'd be happy to help test the proposed fix. I'm currently working with htop from source on Ubuntu/WSL and can build the patch and test the container/process filtering behavior, including cases with and without containers.

Please let me know when the patch/PR is available for testing.

[ravi-arnan]

Thanks for the offer to test, and apologies for the slow reply. I am tracking your username here so you are pinged the moment there is something to run.

Honest status: the fix is written and measured locally, but it has not been opened as a PR yet because the right shape is a definition call that I deliberately left to the maintainers. The current heuristic treats any PID-namespace difference as "in a container", which hides every Chromium sandbox task on a normal desktop. Two directions are on the table: require a container-looking cgroup on top of the namespace difference (what I measured, and what the reporter leaned towards), or exclude namespaces descended from the session htop runs in. They behave differently for the edge cases, so I would rather not ship one silently.

That question has been up on this thread since 08-12 with no maintainer reply yet. The moment it moves, or the PR opens, I will ping you here.

And in case it helps your testing either way: the one-line check that separates a real container from a Chromium sandbox is the cgroup. A docker container reads 0::/system.slice/docker-<id>.scope, a Brave renderer reads 0::/user.slice/user-<uid>.slice/.../session.slice/....