Stop the kernel from swallowing your syscall errors before they hit the logs

Technical Briefing | 8/19/2026

You have likely been in this position: an application process periodically enters a zombie state or throws an EPERM that never shows up in journald. You check the logs, you check the audit daemon, and everything looks clean. The reality is that the kernel is returning these errors directly to the application, but if the developer didn’t bother to log the return code, it effectively evaporates into the ether.

Why journald misses the quiet failures

Journald is great at capturing stdout and stderr, but it cannot see what isn’t written to them. When a system call fails—like an openat call failing because of an underlying namespace constraint—the kernel just passes an integer back to the binary. If your app isn’t explicitly logging errno, that error remains invisible to your observability stack. You are not just missing logs; you are missing the signal that a process is silently failing its mission.

bpftrace -e 'tracepoint:syscalls:sys_exit_openat { if (args->ret < 0) { printf("Process %s failed openat: %d\n", comm, args->ret); } }'

Tracing the ghost in the machine

• Focus your trace on the specific syscall return codes that cause application instability
• Pipe your output to a temp file if you need to correlate timing with external events
• Use process comm filters to keep the trace overhead from killing your CPU cycles

Next time a process starts acting like it’s hallucinating, don’t waste hours chasing log rotation settings or storage backends. Drop into a bpftrace one-liner. Seeing the negative return code in real time cuts through the noise of what your software thinks it’s doing versus what the kernel is actually telling it.