Tracing syscalls with eBPF when journald is just not telling you the truth

Technical Briefing | 7/14/2026

You check the logs. You see a service failing with an EPERM or an ENOENT, but your application code looks perfect. You increase the log level, rotate the journal, and watch the output. Nothing. It is just quiet. That is when you realize journald is not missing the logs; the application is simply not logging the system call failure before it dies.

Why journald misses the context

The kernel often denies access or fails a file operation long before your process reaches its own error handling. If the binary is closed-source or compiled without verbose debug prints, you are flying blind. You could reach for strace, but attaching it to a production process usually spikes latency or just causes the application to time out. That is where eBPF shines because it inspects the kernel state without stopping the world.

sudo opensnoop -p $(pgrep my-app-name)

• The -p flag limits the noise by focusing strictly on the PID that is actually causing your headache
• It hooks into kprobes, catching the openat syscall regardless of whether the userspace code even catches the error
• If you see -1 in the result, that is your smoking gun for a permission or path error

Most people treat opensnoop as a simple debug tool, but you can use it to catch things that loggers miss entirely. If you have a process hitting a directory it shouldn’t, or a container losing its mount mapping, this will show you the truth before the process crashes. Next time your logs are suspiciously empty while your metrics are screaming red, ignore the application logs and ask the kernel what it actually saw.