Procs not showing user processes on some machines

[mjklemm]

When running procs on some of machines, I do see all the processes as expected. However, I have a few machines where only kernel-land processes are being shown:

 PID  User │ TTY:▼ CPU MEM CPU Time │ Command
           │       [%] [%]          │
 274  root │       0.0 0.0 00:00:00 │ [idle_inject/43]
 53   root │       0.0 0.0 00:00:02 │ [migration/6]
 113  root │       0.0 0.0 00:00:03 │ [migration/16]
 813  root │       0.0 0.0 00:00:00 │ [cpuhp/133]
 529  root │       0.0 0.0 00:00:00 │ [kworker/85:0-rcu_par_gp]
 824  root │       0.0 0.0 00:00:00 │ [kworker/134:0H-events_highpri]
 442  root │       0.0 0.0 00:00:00 │ [idle_inject/71]
 603  root │       0.0 0.0 00:00:00 │ [cpuhp/98]
 27   root │       0.0 0.0 00:00:00 │ [cpuhp/2]
 230  root │       0.0 0.0 00:00:00 │ [kworker/35:0H-events_highpri]
 116  root │       0.0 0.0 00:00:00 │ [kworker/16:0H-events_highpri]
 574  root │       0.0 0.0 00:00:00 │ [idle_inject/93]
 1121 root │       0.0 0.0 00:00:03 │ [migration/184]
 1048 root │       0.0 0.0 00:00:00 │ [idle_inject/172]
 873  root │       0.0 0.0 00:00:00 │ [cpuhp/143]
 874  root │       0.0 0.0 00:00:00 │ [idle_inject/143]
 464  root │       0.0 0.0 00:00:00 │ [kworker/74:0H-events_highpri]
 814  root │       0.0 0.0 00:00:00 │ [idle_inject/133]
 360  root │       0.0 0.0 00:00:00 │ [ksoftirqd/57]

I'd appreciate help in debugging this and see where this comes from.

[Toliak]

Hello. I have, I think, the same issue. I am running x86_64 docker container on OSX using colima+vz+rosetta.

Some logs from the container:

bash-5.1# lscpu | grep Arch
Architecture:                         x86_64

bash-5.1# procs --version
procs "0.14.10 ( rev: e631556, rustc: 1.85.1, build at: 2025/03/28 06:52:24 )"

bash-5.1# whoami
root

bash-5.1# cat /etc/os-release 
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
...

bash-5.1# procs
 PID:▲ User │ TTY CPU MEM CPU Time │ Command
            │     [%] [%]          │        

bash-5.1# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0 387916  7504 pts/0    Ss   Aug15   0:00 /bin/bash
root          68  0.0  0.0 387708  6396 pts/0    S    Aug15   0:02 /usr/bin/bash
root        3342  0.0  0.0 390176  5748 pts/0    R+   23:22   0:00 /usr/bin/ps aux

[apage43]

I have noticed the same issue - on my machine I tracked it down to running afoul of the open file descriptor limit - it shows more processes after increasing the limit with ulimit -n, because of how the procfs crate's Process struct work and how procs uses it - if you have a procfs Process it is always holding an open fd to /proc/<pid>, and procs tries to collect all the Processes in a Vec before applying filters

once the fd limit is hit operations from the procfs crate start to fail, and procs mostly silently ignores errors from procfs and simply drops the related process from the list

therefore procs can never show more processes than your nofile limit - and probably fewer than that as in the filtering step it will drop more of them when failing to open fds to read files in /proc as well (like stat)

[mjklemm]

Ah, that makes complete sense! I have increased my ulimit to 100k on my system, and this appears to be sufficiently large for the usual load on our servers. So, I'd be OK with this workaround for now (I will certainly forget to remember to put the ulimit command on a new machine).

I wonder if this could be eventually fixed though, e.g., by querying and accumulating in the data structure and then do post-processing.

[mikeiz404]

I think it would also be helpful for procfs to report when the ulimit has been reached and to notify the user that processes may be missing from the output (with a tip on increasing the open file descriptor ulimit).

[fzlzjerry]

I can work on this. On current master, a synthetic --procfs tree with 96 processes shows only 28 at RLIMIT_NOFILE=32 and 60 at 64, with no error. All 96 appear at 1024.

The second sampling pass retains each procfs::Process in the result vector. I'll make Linux collection feed one process at a time into the columns, then release its handle, and add a low-limit regression test. This should preserve the existing per-process reads and thread/tree handling without raising the user's limit.