strace -c and -f: Trace and Count Syscalls
strace -c runs a command and prints a summary table of every system call it made, with counts and time spent; -f follows into child processes.
When a program is slow or stuck on I/O, strace shows the syscalls it makes. The -c summary is a quick way to spot excessive open, stat, or read calls.
What it does
strace intercepts the system calls a process makes and, by default, prints each with its arguments and result. -c suppresses the per-call output and instead prints a summary table: call count, time, and errors per syscall. -f follows forked and cloned children.
Common usage
strace -c ./my-program
# follow child processes (a build that spawns compilers)
strace -f -c ./build.sh
# only trace file-related syscalls, to a file
strace -f -e trace=file -o trace.log ./my-programOptions
| Flag | What it does |
|---|---|
| -c | Print a summary count/time table instead of every call |
| -f | Follow child processes created by fork/clone |
| -e trace=<set> | Limit tracing to a set (file, network, signal, ...) |
| -p <pid> | Attach to an existing process |
| -o <file> | Write the trace to a file |
| -T | Show time spent in each syscall |
In CI
Use strace -f -c to profile syscall overhead of a build or test step. In containers it needs ptrace, so add --cap-add SYS_PTRACE and, on locked-down runners, a seccomp profile that permits ptrace, otherwise strace cannot attach.
Common errors in CI
"strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted" in Docker is the default seccomp/cap restriction; run with --cap-add SYS_PTRACE (and --security-opt seccomp=unconfined if the default profile still blocks it). "strace: Could not attach to process ... Operation not permitted" attaching to a pid is the same restriction plus possibly Yama ptrace_scope. On some minimal images strace is simply not installed.