strace — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about strace.
strace was created by Paul Kranenburg in 1991 for SunOS¶
The original strace was written by Paul Kranenburg for SunOS in 1991. It was then ported to Linux by Branko Lankester, and later maintained by Wichert Akkerman and Dmitry Levin. Despite being over 30 years old, strace remains the most widely used system call tracer on Linux. Its simplicity — attach to a process and see every kernel interaction — has never been improved upon for quick debugging.
strace works by using the ptrace system call, which was designed for debuggers¶
strace uses ptrace(2), a system call originally created to support debuggers like gdb. ptrace allows one process to observe and control another, intercepting system calls and signals. This same mechanism is used by debuggers, sandbox tools, and some security products. The overhead of ptrace is significant (each syscall requires 4 context switches instead of 2), which is why strace slows processes by 10-100x.
The -p flag to attach to a running process has saved countless production systems¶
Before strace, debugging a hung or misbehaving production process often required restarting it with debug logging — destroying the exact conditions you wanted to observe. The ability to strace -p <PID> and immediately see what a running process is doing, without modifying or restarting it, was revolutionary. Many production issues have been diagnosed within seconds of attaching strace.
strace -c (summary mode) is one of the most underused debugging features¶
Running strace -c produces a statistical summary of system calls: count, time, errors, and percentage of total time for each syscall type. This immediately reveals whether a program is spending its time in network I/O (read/write on sockets), file I/O (open/read on files), or memory allocation (mmap/brk). Many performance problems become obvious from a 30-second -c trace.
The performance overhead of strace makes it unsuitable for some production use¶
strace's ptrace-based approach adds 2 extra context switches per system call, causing 10-100x slowdown in syscall-heavy workloads. For a web server handling thousands of requests per second, attaching strace can itself cause a performance incident. This limitation drove the development of alternatives like perf trace (using kernel tracing infrastructure) and eBPF-based tools like bpftrace, which have near-zero overhead.
strace can reveal secrets and credentials in process arguments and data¶
Running strace on a process shows every byte read from and written to file descriptors — including passwords sent over unencrypted connections, API keys read from config files, and database credentials in connection strings. Security-conscious organizations restrict ptrace access via the kernel.yama.ptrace_scope sysctl setting. In hardened environments, ptrace_scope=1 prevents non-parent processes from tracing.
Brendan Gregg called strace "a useful tool but also a dangerous one" for production¶
Brendan Gregg, the performance engineering expert, has extensively documented strace's performance risks in production. His BPF-based alternatives (using bpftrace and perf) achieve similar observability with dramatically less overhead. Gregg's 2019 blog post "strace Wow Much Syscall" demonstrated how a single strace attachment could increase a target process's latency by 100x and recommended BPF-based tools as safer alternatives.
The -e trace=network filter can diagnose connectivity issues in seconds¶
Running strace -e trace=network (or -e trace=%network in newer versions) filters output to show only network-related system calls: socket, connect, bind, listen, accept, sendto, recvfrom. This immediately reveals whether a program is connecting to the right host and port, experiencing connection timeouts, or getting DNS resolution failures — common production debugging scenarios that would otherwise require packet captures.
strace on a multi-threaded program requires -f to follow threads¶
By default, strace only traces the main thread. For multi-threaded programs (which is nearly everything modern), you must use strace -f to follow child processes and threads via clone/fork. Missing the -f flag is one of the most common strace mistakes — the debugger sees nothing happening while the actual work is happening in threads it's not tracing. This gotcha has wasted countless debugging hours.
ltrace is strace's forgotten cousin that traces library calls instead of system calls¶
While strace shows kernel system calls, ltrace shows user-space library calls (like malloc, printf, strlen). ltrace uses the same ptrace mechanism but intercepts shared library function calls via PLT (Procedure Linkage Table) hooking. It's rarely mentioned in debugging guides but can be invaluable when the problem is in a library rather than the kernel — for example, diagnosing TLS/SSL handshake failures by tracing OpenSSL calls.