How to Trace Open System Calls and File Access in Linux Using opensnoop

Diagnosing mysterious software failures in Linux often traces back to missing configuration files, corrupted shared libraries, or invalid file permissions. Traditional debugging utilities like strace can inspect system calls, but attaching strace to high-throughput production servers incurs massive performance overhead (slowing execution by 10x to 100x) and cannot easily monitor system-wide activity across newly spawned processes.

opensnoop is an eBPF (extended Berkeley Packet Filter) tracing tool part of the BCC (BPF Compiler Collection) suite. It hooks directly into the Linux kernel’s open() and openat() system calls, recording which processes open files across your entire operating system in real time with negligible CPU impact. It allows system administrators to uncover hidden dependencies, identify runaway file activity, and discover failed file lookups instantly. You can pair it with complementary kernel tools, such as learning how to trace process signals with killsnoop and monitor filesystem I/O with filetop.

How opensnoop Works in the Linux Kernel

Whenever an application reads data, searches for dynamic libraries (.so files), or opens an endpoint in /etc, it issues an openat() syscall to obtain a file descriptor. opensnoop attaches kernel probes (kprobes or tracepoints) to this syscall. It extracts the process ID (PID), command name, file path, access flags, and return code before emitting structured output to user space via an eBPF ring buffer.

Installing opensnoop on Linux

opensnoop is distributed within the standard bpfcc-tools or bcc-tools packages across major enterprise distributions.

Installing on Ubuntu and Debian

sudo apt update
sudo apt install bpfcc-tools linux-headers-$(uname -r)

On Debian systems, BCC binaries are installed with a -bpfcc suffix (e.g., opensnoop-bpfcc) located in /usr/sbin.

Installing on Fedora, RHEL, and AlmaLinux

sudo dnf install bcc-tools kernel-devel-$(uname -r)

On RHEL-based systems, tools reside directly in /usr/share/bcc/tools/opensnoop.

Installing on Arch Linux

sudo pacman -S bcc bcc-tools linux-headers

How to Use opensnoop to Trace File Activity

Because opensnoop attaches low-level kernel probes, it must be executed with root privileges.

1. Live System-Wide Tracing

To trace every file opened across your operating system in real time, run:

sudo opensnoop-bpfcc

The console displays a live scrolling event log:

PID    COMM               FD ERR PATH
1420   systemd-resolved   12   0 /etc/hosts
3104   nginx               6   0 /var/www/html/index.html
4190   python3            -1   2 /home/deploy/.env
4210   curl                3   0 /etc/ssl/certs/ca-certificates.crt

Columns represent:

• PID: Process ID initiating the open syscall.
• COMM: Executable or command name.
• FD: Assigned file descriptor (a positive integer indicates success).
• ERR: Error code returned by the kernel. A value of 0 means success, while negative numbers or positive errno codes (such as 2 for ENOENT / No such file or directory) highlight failures.
• PATH: Full absolute or relative filesystem target path.

2. Filtering for Failed Opens Only (Finding Missing Files)

One of the most powerful troubleshooting use cases is discovering which configuration files an application is searching for but failing to find. Use the -x flag to record failed open calls exclusively:

sudo opensnoop-bpfcc -x

This quickly flags missing configuration files, absent licensing tokens, or misplaced environment definitions.

3. Filtering by Process Name or Process ID

To isolate noise and focus strictly on a specific daemon (such as mysqld, nginx, or node), use the -n (name) or -p (PID) options:

sudo opensnoop-bpfcc -n nginx

sudo opensnoop-bpfcc -p 3104

4. Timestamping File Access Events

To correlate file opens with external application logs, add the -T (system time) or -t (relative seconds) flag:

sudo opensnoop-bpfcc -T

Output prepends precise wall-clock timestamps (e.g., 17:08:42) to each event.

opensnoop vs. strace Command Comparison

Feature	strace	opensnoop (eBPF)
Mechanism	ptrace context switching	In-kernel eBPF tracepoints
CPU Overhead	Heavy (10x–50x performance degradation)	Negligible (suitable for production)
Scope	Attached to specific PID or command	System-wide across all current and future processes
Failure Filtering	Requires complex grep filters	Native -x flag for instant error isolation

Frequently Asked Questions

Does opensnoop trace memory-mapped files?

opensnoop captures the initial open() or openat() call that provides the file descriptor before mmap() is invoked. However, subsequent memory reads and writes through that memory pointer are not logged as new open syscalls.

Can I export opensnoop data to a file for analysis?

Yes. Pipe standard output into a text file or log utility:

sudo opensnoop-bpfcc -x > missing_files.log

Why does opensnoop require kernel headers?

BCC compiles the eBPF C program dynamically against your active kernel data structures. The linux-headers package provides the required kernel symbol tables.