debugbashMajor
strace: Tracing System Calls to Debug Silent Failures
Viewed 0 times
stracesyscallptraceENOENTdebugsilent failureopenaterrno
linux
Error Messages
Problem
A process fails with no useful error message, returns exit code 1, or behaves unexpectedly — and there are no application-level logs to diagnose it.
Solution
Use strace to trace system calls and signals, revealing what the process is actually doing.
# Trace a new process
strace /usr/bin/myapp arg1 arg2
# Attach to a running process
strace -p 1234
# Filter to specific syscalls (open, read, write)
strace -e trace=openat,read,write myapp
# Filter to just file operations
strace -e trace=file myapp
# Filter to network syscalls
strace -e trace=network myapp
# Follow child processes (forks)
strace -f myapp
# Write output to file (stderr by default)
strace -o /tmp/strace.log myapp
# Show timestamps and elapsed time
strace -t -T myapp
# Count syscall frequency
strace -c myapp
# Common pattern: find why a file open fails
strace -e openat myapp 2>&1 | grep ENOENTWhy
strace intercepts every kernel system call. A process that fails to open a config file, connect to a socket, or find a library will show the exact path it tried and the exact errno returned. This reveals misconfigurations that produce no application-level log.
Gotchas
- strace adds significant overhead — do not use on high-throughput production processes.
- Attaching to a process with -p requires ptrace permission — may need root or
CAP_SYS_PTRACE. - Some applications (especially Go programs) use non-standard syscall patterns that are harder to interpret.
- strace output goes to stderr by default — redirect with
-ofor complex sessions.
Revisions (0)
No revisions yet.