Stop using strace when you can just watch the kernel move files

Technical Briefing | 11/9/2026

We have all been there. A background process is moving files into the wrong directory, or worse, deleting them, and you have zero clue why. You try to attach strace to the PID, but the process is so busy it freezes the entire application, or the output is just a firehose of noise that misses the actual system call you care about. It is a classic trap.

Why eBPF is the better mousetrap

The reason strace hurts is because it stops and restarts the process for every system call. It is invasive. If you want to see which process is opening a specific file path without killing your production throughput, you need to reach for eBPF. Specifically, the opensnoop tool from the BCC toolkit lets you hook into the vfs_open function. It just watches the kernel events fly by in real-time.

/usr/share/bcc/tools/opensnoop -d -n my_app_name

• The -d flag shows you the relative path which helps if you are confused by chroot environments
• The -n flag filters by process name so you are not drowning in log noise from every cron job on the system
• It avoids the context switching penalty that makes strace so dangerous on high-load servers

If you are still hunting ghosts with lsof or heavy tracing tools, you are making your life harder than it needs to be. Try keeping the BCC toolkit handy on your baseline image. It turns hours of guessing into ten seconds of observation.