Stop guessing what your kernel is blocking, just ask eBPF

Technical Briefing | 9/26/2026

We have all been there. A process is failing with an obscure permission error, but the audit logs are empty and strace is drowning in noise. You suspect something like SELinux or a seccomp filter is dropping the ball, but you cannot find the evidence. It is maddening because you know the syscall is happening, but it just vanishes into the void.

Quit digging through logs that do not exist

The reason your standard logs fail you is that they often rely on the application actually reporting the error. When the kernel kills a syscall because of an LSM policy or a namespace restriction, it does not always write a pretty message to journald. eBPF changes the math. Instead of asking the app if it is broken, we attach a kprobe to the syscall exit and watch the return codes in real-time.

bpftrace -e 'tracepoint:syscalls:sys_exit_openat /args->ret < 0/ { printf("%s (%d) blocked on %s: %d\n", comm, pid, str(args->filename), args->ret); }'

• Filter by PID or command name to stop the output firehose
• Check args->ret against your errno.h table to identify the specific error
• Watch for silent drops that bypass syslog entirely

This one-liner has saved me hours during container migrations where seccomp profiles were just slightly too tight. If you are not using bpftrace yet, stop relying on trial and error. Grab the syscall trace, identify the exact path that is hitting the wall, and adjust your policy. Your future self will thank you when the production application finally stops failing in silence.