Is there a trade off here?

    ps aux | grep nginx | grep root | grep -v grep

    ps -u root -C nginx

    psc 'process.name == "nginx" && process.user == "root"'

  # Find processes connected to a specific port
  psc 'socket.dstPort == uint(443)'

  # Filter by PID range
  psc 'process.pid > 1000 && process.pid < 2000'

> I ran benchmarks on current code in the datadog-agent which reads the relevant data from procfs as described at the beginning of this post. I then implemented benchmarks for capturing the same data with bpf. The performance results were a major improvement.

> On a linux system with around 250 Procs it took the procfs implemention 5.45 ms vs 75.6 us for bpf (bpf is ~72x faster). On a linux system with around 10,000 Procs it took the procfs implemention ~296us vs 3ms for bpf (bpf is ~100x faster).

[1] https://www.grant.pizza/blog/bpf-iter/

- grep /proc/*/maps for " (deleted)" (needs root)

- exclude irrelevancies like paths starting with "/memfd:" (I have lots of other similar exclusions) with grep -v

- extract the pid from the filename part of grep's output with sed

- for each pid, generate readable output from /proc/$pid/cmdline (which is NUL separated) with tr, xargs, bash printf

- show the pid, cmdline, file path

Yes, this is what needs-restarting does too.

With this tool, this pipe chain is now just:

    doas psc -o "process.pid,process.cmdline,file.path" \
      'file.path.endsWith(" (deleted)") && !file.path.startsWith("/memfd:") && !...' \
      | sed 1d

Anyway, my need for the tool was mostly because of these few points:

- scripting can be much easier with psc, especially when you can output what you want

- ebpf iterators are so flexible: we can get anything that is defined in the task_struct that is not even exposed in the proc filesytem if we want. This alone makes the tool extremely powerful, with a reasonable amount of effort for just adding a new field

- I really like querying my system with a simple language. Sometimes I tend to forget about specific ss, lsof, or ps options. In this way, it's much easier for me to get what I need

- no traditional tooling has native container context. It can be extended to even retrieve data from the kubelet, for instance, but I'll think about it

Feel free to reach out if you have any particular need