# strace: the Linux syscall tracer, and what it costs you in practice > strace monitors and tampers with the boundary between a process and the Linux kernel through ptrace. This is what it is for, how to install it, and where it stops being the right tool. **strace/strace** — strace is a diagnostic, debugging and instructional userspace utility for Linux - Repository: https://github.com/strace/strace - Stars: 2,706 · Forks: 502 - Language: C - License: NOASSERTION - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/strace-strace ## The problem strace solves, and who actually has it A program can fail without telling you why. It exits with a code, writes a truncated log line, or simply stops. Everything above the kernel boundary looks correct, so the missing information is below it: which file it tried to open, which syscall returned an errno, whether a signal arrived before the process died. strace answers those questions by monitoring and tampering with the interactions between processes and the Linux kernel, which the README lists as system calls, signal deliveries, and changes of process state. The audience is narrow and technical. Distribution packagers diagnosing a build failure, systems engineers chasing a service that will not start, kernel-adjacent developers checking whether a library calls what they think it calls. The README also calls strace instructional, and that is fair: reading a syscall trace is one of the faster ways to learn what a program actually does rather than what its documentation claims. If you write application code and never touch process startup, filesystem permissions or container policy, strace will rarely be your first move. ## How ptrace turns a trace into text strace does not instrument your program. The README states plainly that its operation is made possible by the kernel feature known as ptrace. That single sentence explains most of strace's behaviour and most of its cost. The tracer attaches to a tracee, the kernel stops the tracee at defined points, reports the event, and waits for the tracer to resume it. Each syscall entry and exit is one such stop. The trace you read is the tracer's rendering of those stops. The consequence is that strace observes from outside the process. It needs no recompilation, no source, no cooperation from the program, and it can attach to something already running. It also means the traced process runs under a different scheduler pattern than it would alone, because it is being stopped and resumed constantly. A trace is a truthful record of syscalls and a distorted record of timing. When you read a strace log, trust the ordering and the return values, and be sceptical of the durations. The repository layout reflects how much surface that mechanism has to cover: src/ holds the tracer, tests/ holds a suite large enough that it carries its own licence, and doc/ holds the developer documentation index. The presence of a separate tests/COPYING is a useful signal about how much of this project's risk lives in matching kernel behaviour precisely. ## Installing strace and reading your first real trace The README points at downstream packages, and that is the intended path for most users. It does not spell out a package manager command, so the practical step is to check your distribution's repositories for the strace package. If you are building from a git checkout rather than a release tarball, the README directs you to INSTALL-git.md for build instructions, and the repository ships a bootstrap script alongside configure.ac for that route. Most readers should not take that route. For a first trace, do not attach to anything important. The README describes strace as having a traditional command-line interface; the man page, also available as `man strace` after installation, is where the flags are documented. Start by tracing a trivial command and reading the tail, where the interesting failure usually is. Follow child processes if the command forks, and write the trace to a file instead of mixing it with the program's own output. You should see the process fail, and the trace file should contain the syscall sequence ending in the call that failed and the errno that followed. That is the whole workflow: reproduce, trace, read the last few lines before the failure. To attach to a process that is already running, you are exercising the monitoring of existing interactions that the README describes. You need the process ID and, on most systems, the same user or elevated privileges. The README does not document rollback or detach semantics, so check your local man page for how to leave a process in the state you want before you attach to anything you cannot restart. ## The costs that make strace the wrong tool sometimes The honest limitation is the mechanism itself. Because every traced syscall involves stopping and resuming the tracee, a heavily syscall-bound program traced with strace can slow dramatically, and its behaviour can change. A race condition may stop reproducing. A timeout may start firing because the process is spending time stopped rather than working. You are not observing the original program; you are observing a program under a tracer. There is a second boundary. strace sees kernel crossings. A bug entirely inside userspace, a lock contention problem, a hot loop that never calls into the kernel, is invisible to it. A trace of such a program shows a clean syscall pattern and tells you nothing about where the time went. If the question is why code is slow rather than what the kernel was asked to do, strace is the wrong instrument. A third case is production. Attaching a tracer to a live service is a change to that service's execution. The README describes strace as a diagnostic and debugging utility, not a monitoring agent, and nothing in the repository suggests it is intended to run continuously against production workloads. For a first look at a failing service, prefer tracing a reproduction or a canary instance. ## strace against ptrace, and against in-process alternatives The most common confusion is treating strace and ptrace as alternatives. They are not. ptrace is the kernel interface; strace is a userspace program built on top of it. Choosing ptrace instead of strace means writing your own tracer, which is reasonable if you need custom filtering, custom output, or to embed tracing in another tool, and unreasonable if you just want to know which file a process failed to open. A more meaningful comparison is against tools that work inside the process rather than across the ptrace boundary. Dynamic instrumentation and in-process profilers attach to functions and sample stacks, so they see userspace behaviour and avoid the stop-and-resume pattern. The difference in approach produces different blind spots: a ptrace-based tracer sees every syscall and no function call, while an in-process tool sees function calls and can miss the kernel boundary entirely. Neither replaces the other. When strace shows a syscall returning an unexpected errno, an in-process tool will not explain it, and when an in-process tool shows a hot function, strace has nothing to say about it. Platform is the other axis. strace is a Linux utility; the README describes it as a userspace utility for Linux, and ptrace as a Linux kernel feature. There is no Windows or macOS build described here, and the repository contains no portability layer for those systems. If you are not on Linux, this is not the tool for the job. ## Licence, maintenance and the cost of staying current strace itself is released under the GNU Lesser General Public License version 2.1 or later, per the README, with the COPYING file as the reference. The test suite is separate and released under the GNU General Public License version 2 or later, with tests/COPYING as its reference. The practical implication is that the tracer and the tests carry different obligations, which matters if you vendor or redistribute either. That is a description of what the repository states, not legal advice; read both files before you ship anything derived from them. The project is not archived, and the last push was on 2026-09-15. Releases are frequent: v7.0 in April 2026, v7.1 in June 2026, v7.2 in August 2026. That cadence has a cost for anyone pinning a version. Syscall decoding is tied to kernel headers and to kernel behaviour, so an older strace on a newer kernel can render unfamiliar syscalls poorly or not at all. If you are debugging something recent, check your distribution's package version against the upstream releases before concluding the trace is complete. The repository's NEWS file is where the README sends you for what changed. ## Conclusion Reach for strace when a process fails in a way that only the kernel boundary can explain: a missing file, a permission denial, a syscall returning an unexpected errno, a hang with no userspace log. Do not reach for it as a production profiler or as a way to trace code that never enters the kernel; an in-process profiler or a dynamic instrumentation tool fits that job better, and ptrace's stop-and-report model changes the timing of whatever you attach to. Before adopting it, check three things on your own machine: whether your distribution's package carries the version you need, whether your kernel permits ptrace under its current Yama setting, and what your container's seccomp policy does to the ptrace syscall itself. ## FAQ ### What is strace and what is it used for? strace is a diagnostic, debugging and instructional userspace utility for Linux that monitors and tampers with interactions between processes and the kernel, including system calls, signal deliveries and process state changes. It is used to see what a program actually asks the kernel to do, which is often where a failure originates. ### What is the difference between strace and ptrace? ptrace is the Linux kernel feature, and strace is a userspace utility whose operation is made possible by it. Using ptrace directly means writing your own tracer; using strace means using an existing one. ### Is there a Windows version of strace? No. The README describes strace as a userspace utility for Linux and ties its operation to the Linux kernel feature ptrace, and the repository contains no Windows port. ### How do I install strace on Linux? The README points to downstream packages, so the normal route is your distribution's package manager. Building from a git checkout is a separate path documented in INSTALL-git.md. ### How do I use strace on a running process? Attach to it with the process ID, which exercises the monitoring of an existing process that the README describes. You generally need to be the same user as the process or to have elevated privileges. ## Sources - [Issues](https://github.com/strace/strace/issues) - [README](https://github.com/strace/strace/blob/master/README.md) - [Releases](https://github.com/strace/strace/releases) - [strace/strace on GitHub](https://github.com/strace/strace) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/strace-strace