strace is the tool of first resort when you need to know what a program is actually asking the operating system to do. The strace project site describes it as a diagnostic, debugging, and instructional userspace utility for Linux, used to monitor and tamper with the interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state. In practice this means strace shows the live conversation a process holds with the kernel, even when you have no source code for the program.
Its core function is narrow and well defined. As the strace(1) man page states, the tool intercepts and records the system calls made by a process and the signals a process receives. For each system call it prints the call name, the decoded arguments, and the return value, so a single trace reveals which files a program opened, which network connections it made, where it failed with an errno, and which signals interrupted it. This is exactly the information that is hardest to recover from logs or a debugger alone, which is why strace is reached for to diagnose hangs, permission errors, missing files, and unexpected kernel-boundary behavior.
The mechanism underneath is the ptrace system call, the same kernel facility that debuggers use to control another process. strace attaches to a target with ptrace, arranges to be notified on each entry to and exit from a system call, reads the traced process’s registers and memory to decode the arguments, and then lets it continue. Because every system call traps into strace, tracing imposes real overhead and slows the traced program, so strace is a diagnostic instrument rather than something left running in production. The man page lists ptrace(2) among its related references, underscoring that strace is essentially a focused, user-friendly front end to that low-level tracing interface.
Originally written for SunOS and ported widely, strace became a fixture of Linux systems and is now actively maintained as an open-source project at strace.io. Over time it gained the ability to filter which calls to show, to follow forked children, to decode complex argument structures, and to produce summary statistics of call counts and time spent per system call. It complements rather than competes with profilers: where perf or gprof tell you where CPU time goes inside your code, strace tells you what your code is asking the kernel to do on its behalf, and it pairs naturally with a debugger when a failure turns out to live at the system-call boundary.