For execsnoop, people running systems with DTrace can find the same:
* https://github.com/jorgev/dtrace-scripts/blob/master/execsno...
On macOS Monterey+ you'll probably have to install the Kernel Debug Kit per:
* https://developer.apple.com/forums/thread/692444
The Linux variant was written Brendan Gregg (who previous did a lot of work on Solaris, where DTrace was created):
* https://github.com/brendangregg/perf-tools/blob/master/execs...
* https://github.com/iovisor/bcc/blob/master/tools/execsnoop.p...
In Hidden gems of moreutilsiovisor
bcc
C2016–2026
iovisor / bcc
bcc
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
64Distinct people
78Mentions
0Explicit recommenders
22.7KGitHub stars
What to know before exploring
What it is
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
GitHub
Where it is used
The last source check was inconclusive. This does not establish whether a product uses it.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bpftrace/bpftrace · linked in 5 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year78 dated mentions
Observed mentions: 2016-02-03 15:03:57 UTC to 2026-08-10 08:04:42 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 16 | 6 | 10 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 13 | 4 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
BPF Compiler Collection (BCC)
BCC is a toolkit for creating efficient kernel tracing and manipulation
programs, and includes several useful tools and examples. It makes use of
extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature
that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1
and above.
eBPF was described by Ingo Molnár as:
One of the more interesting features in this cycle is the ability to attach eBPF programs (user-defined, sandboxed bytecode executed by the kernel) to kprobes. This allows user-defined instrumentation on a live kernel image that can never crash, hang or interfere with the kernel negatively.
BCC makes BPF programs easier to write, with kernel instrumentation in C
(and includes a C wrapper around LLVM), and front-ends in Python and lua.
It is suited for many tasks, including performance analysis and network
traffic control.
Screenshot
This example traces a disk I/O kernel function, and populates an in-kernel
power-of-2 histogram of the I/O size. For efficiency, only the histogram
summary is returned to user-level.
# ./bitehist.py
Tracing... Hit Ctrl-C to end.
^C
kbytes : count distribution
0 -> 1 : 3 | |
2 -> 3 : 0 | |
4 -> 7 : 211 |********** |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 1 | |
128 -> 255 : 800 |**************************************|
The above output shows a bimodal distribution, where the largest mode of
800 I/O was between 128 and 255 Kbytes in size.
See the source: bitehist.py. What this traces,
what this stores, and how the data is presented, can be entirely customized.
This shows only some of many possible capabilities.
Installing
See INSTALL.md for installation steps on your platform.
FAQ
See FAQ.txt for the most common troubleshoot questions.
Reference guide
See docs/reference_guide.md for the reference guide to the bcc and bcc/BPF APIs.
Contents
Some of these are single files that contain both C and Python, others have a
pair of .c and .py files, and some are directories of files.
Tracing
Examples
examples/tracing/bitehist.py: Block I/O size histogram. Examples.
examples/tracing/disksnoop.py: Trace block device I/O latency. Examples.
examples/hello_world.py: Prints "Hello, World!" for new processes.
examples/tracing/mysqld_query.py: Trace MySQL server queries using USDT probes. Examples.
examples/tracing/nodejs_http_server.py: Trace Node.js HTTP server requests using USDT probes. Examples.
examples/tracing/stacksnoop: Trace a kernel function and print all kernel stack traces. Examples.
tools/statsnoop: Trace stat() syscalls. Examples.
examples/tracing/task_switch.py: Count task switches with from and to PIDs.
examples/tracing/tcpv4connect.py: Trace TCP IPv4 active connections. Examples.
examples/tracing/trace_fields.py: Simple example of printing fields from traced events.
examples/tracing/undump.py: Dump UNIX socket packets. Examples
examples/tracing/urandomread.py: A kernel tracepoint example, which traces random:urandom_read. Examples.
examples/tracing/vfsreadlat.py examples/tracing/vfsreadlat.c: VFS read latency distribution. Examples.
examples/tracing/kvm_hypercall.py: Conditional static kernel tracepoints for KVM entry, exit and hypercall Examples.
Tools
tools/argdist: Display function parameter values as a histogram or frequency count. Examples.
tools/bashreadline: Print entered bash commands system wide. Examples.
tools/bpflist: Display processes with active BPF programs and maps. Examples.
tools/capable: Trace security capability checks. Examples.
tools/compactsnoop: Trace compact zone events with PID and latency. Examples.
tools/criticalstat: Trace and report long atomic critical sections in the kernel. Examples
tools/deadlock: Detect potential deadlocks on a running process. Examples.
tools/drsnoop: Trace direct reclaim events with PID and latency. Examples.
tools/funccount: Count kernel function calls. Examples.
tools/inject: Targeted error injection with call chain and predicates Examples.
tools/klockstat: Traces kernel mutex lock events and display locks statistics. Examples.
tools/opensnoop: Trace open() syscalls. Examples.
tools/readahead: Show performance of read-ahead cache Examples.
tools/reset-trace: Reset the state of tracing. Maintenance tool only. Examples.
tools/stackcount: Count kernel function calls and their stack traces. Examples.
tools/syncsnoop: Trace sync() syscall. Examples.
tools/threadsnoop: List new thread creation. Examples.
tools/tplist: Display kernel tracepoints or USDT probes and their formats. Examples.
tools/trace: Trace arbitrary functions, with filters. Examples.
tools/ttysnoop: Watch live output from a tty or pts device. Examples.
tools/ucalls: Summarize method calls or Linux syscalls in high-level languages. Examples.
tools/uflow: Print a method flow graph in high-level languages. Examples.
tools/ugc: Trace garbage collection events in high-level languages. Examples.
tools/uobjnew: Summarize object allocation events by object type and number of bytes allocated. Examples.
tools/ustat: Collect events such as GCs, thread creations, object allocations, exceptions and more in high-level languages. Examples.
tools/uthreads: Trace thread creation events in Java and raw pthreads. Examples.
Memory and Process Tools
tools/execsnoop: Trace new processes via exec() syscalls. Examples.
tools/exitsnoop: Trace process termination (exit and fatal signals). Examples.
tools/killsnoop: Trace signals issued by the kill() syscall. Examples.
tools/kvmexit: Display the exit_reason and its statistics of each vm exit. Examples.
tools/
Read the full README on GitHubWhat Hacker News says
6 sourcesIn Linux you can use eBPF. See https://github.com/iovisor/bcc for an easy way to write eBPF, or look for something in the tools/ dir that does what you want. You distro might have these packaged in bcc-tools or similar.
In Bug in macOS 14 Sonoma prevents our app from workingThe whole BPF verifier and development process is so botched, it's ridiculous. It's like maintainers decided to make this as hard as possible out of pettiness and "they have to use C APIs instead" or something.
- Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a "unknown/invalid memory access" error which is super useless as an error message.
- In my personal opinion a bytecode format for both little endian (bpfel) and big endian (bpfeb) machines is kinda unnecessary. I mean, it's a virtual bytecode format for a reason, right!?
- Compiling eBPF via clang to the bpf bytecode format without debug symbols will make every following error message down the line utterly useless. Took me a while to figure out what "unknown scalar" really means. If you forge
Read the rest
t that "-g" flag you're totally fucked.
- Anything pointer related that eBPF verifier itself doesn't support will lead to "unknown scalar" errors which are actually out of bounds errors most of the time (e.g. have to use if pointer < size(packet) around it), which only happen in the verification process and can only be shown using the bpftool. If you miss them, good luck getting a better error message out of the kernel while loading the module.
- The bpftool maintainer is kind of unfriendly, he's telling you to read a book about the bytecode format if your code doesn't compile and you're asking about examples on how to use pointers inside a BPF codebase because it seems to enforce specific rules in terms of what kind of method (__always_static) are allowed to modify or allocate memory. There's a lot of limitations that are documented _nowhere_ on the internet, and seemingly all developers are supposed to know them by reading the bpftool codebase itself!? Who's the audience for using the bpftool then? Developers of the bpftool itself?
- The BCC tools (bpf compiler collection) are still using examples that can't compile on an up-to-date kernel. [1] If you don't have the old headers, you'll find a lot of issues that show you the specific git hash where the "bpf-helpers.h" file was still inside the kernel codebase.
- The libbpf repo contain also examples that won't compile. Especially the xdp related ones [2]
- There's also an ongoing migration of all projects (?) to xdp-tools, which seems to be redundant in terms of bpf related topics, but also has only a couple examples that somehow work [3]
- Literally the only userspace eBPF generation framework that worked outside a super outdated enterprise linux environment is the cilium ebpf project [4], but only because they're using the old "bpf-helpers.h" file that are meanwhile removed from the kernel itself. [5] They're also incomplete for things like the new "__u128" and "__bpf_helper_methods" syntax which are sometimes missing.
- The only working examples that can also be used for reference on "what's available" in terms of eBPF and kernel userspace APIs is a forked repo of the bootlin project [6] which literally taught me how to use eBPF in practice.
- All other (official?) examples show you how to make a bpf_printk call, but _none_ of them show you how to even interact with bpf maps (whose syntax changed like 5 times over the course of the last years, and 4 of them don't run through the verifier, obviously). They're also somewhat documented in the wiki of the libbpf project, without further explanation on why or what [7]. Without that bootlin repo I still would have no idea other than how to make a print inside a "kretprobe". Anything more advanced is totally undocumented.
- OpenSnitch even has a workflow that copies their own codebase inside the kernel codebase, just to make it compile - because all other ways are too redundant or too broken. Not kidding you. [8]
Note that none of any BPF related projects uses any kind of reliable version scheme, and none of those project uses anything "modern" like conan (or whatever) as a package manager. Because that would have been too easy to use, and too easy on documenting on what breaks when. /s
Overall I have to say, BPF was the worst development experience I ever had. Writing a kernel module is _easier_ than writing a BPF module, because then you have at least reliable tooling. In the BPF world, anything will and can break at any unpredictable moment. If you compare that to the experience of other development environments like say, JVM or even the JS world, where debuggers that interact with JIT compilers are the norm, well ... then you've successfully been transferred back to the PTSD moments of the 90s.
Honestly I don't know how people can use BPF and say "yeah this has been a great experience and I love it" and not realize how broken the tooling is on every damn level.
I totally recommend reading the book [9] and watching the YouTube videos of Liz Rice [10]. They're awesome, and they show you how to tackle some of the problems I mentioned. I think that without her work, BPF would have had zero chance of success.
What's missing in the BPF world is definitely better tooling, better error messages (e.g. "did you forget to do this?" or even "unexpected statement" would be sooooo much better than the current state), and an easier way to debug an eBPF program. Documentation on what's available and what is not is also necessary, because it's impossible to find out right now. If I am not allowed to use pointers or whatever, then say so in the beginning.
[1] https://github.com/iovisor/bcc
[2] https://github.com/libbpf/libbpf
[3] https://github.com/xdp-project/xdp-tools
[4] https://github.com/cilium/ebpf/
[5] https://github.com/cilium/ebpf/tree/master/examples/headers
[6] https://elixir.bootlin.com/linux/latest/source/tools/testing...
[7] https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-g...
[8] https://github.com/evilsocket/opensnitch/blob/master/ebpf_pr...
[9] https://isovalent.com/learning-ebpf/
[10] (e.g.) https://www.youtube.com/watch?v=L3_AOFSNKK8
I wrote an eBPF application that is launched and killed by a PAM session script. It uses the PPID to only record commands and arguments associated with that session. My application was heavily influenced by execsnoop:
https://github.com/iovisor/bcc/blob/master/tools/execsnoop.p...
In Session recording for Tailscale SSH in betaOn Linux, this can be done using BPF (Berkley Packet Filter). In fact there is a tool in BCC[0] called filetop, which lists reads/writes by process and file[1].
0. https://github.com/iovisor/bcc
1. https://github.com/iovisor/bcc/blob/master/tools/filetop.py
In Sloth – A Mac app that shows all open files, directories, sockets, etc.