Linux strace -c: How to Summarize System Calls

This article explores the significance of the -c flag in the Linux strace diagnostic tool, which aggregates and profiles system call activity rather than logging an overwhelming stream of individual events. By summarizing total execution time, call counts, and failure rates into a clean statistical table, the -c option transforms strace from a raw tracing utility into a lightweight profiling tool. Readers will learn how the flag works, how to interpret its output, and why it is indispensable for debugging performance bottlenecks and application failures.

Understanding the Standard strace vs. the -c Flag

By default, strace prints every system call executed by a program directly to standard error in real-time. For complex or long-running applications, this behavior generates millions of lines of raw text, making it difficult to pinpoint where performance degradation or systematic failures occur.

The -c (or --summary-only) flag changes this behavior by intercepting system calls quietly in the background, collecting timing and execution metrics, and printing a single consolidated report when the traced process exits.

Key Metrics in the strace -c Summary Table

When a command runs with strace -c, the resulting output organizes syscall data into a structured table containing six primary columns:

• % time: The percentage of the total elapsed system call time spent on this specific syscall. This metric immediately highlights where the kernel overhead is concentrated.
• seconds: The total accumulated time (in fractional seconds) consumed by the system call across all invocations.
• usecs/call: The average execution time per call, measured in microseconds. A high value here indicates an inherently slow operation, such as blocking disk I/O or network waiting.
• calls: The total number of times the syscall was executed. High counts often indicate inefficient loops or excessive polling.
• errors: The number of invocations that returned an error code (such as ENOENT or EACCES).
• syscall: The name of the specific Linux system call (e.g., read, write, openat, futex).

The Significance of the -c Flag in System Diagnostics

1. Rapid Performance Profiling

The primary significance of the -c flag is its ability to reveal performance bottlenecks without requiring external profilers like perf. If an application is running slowly, the summary table immediately shows whether the delay is caused by excessive file system operations (stat, openat), network latency (recvfrom, poll), or thread contention (futex).

2. Identifying Systematic Failures

The errors column provides an instant overview of failures. Instead of manually searching through megabytes of raw logs for error codes, an administrator can immediately see if an application failed hundreds of connect or openat calls, directing immediate attention to network configuration or missing file dependencies.

3. Reducing Diagnostic Overhead

Writing full strace logs to disk or terminal output introduces significant I/O overhead that can alter the runtime behavior of the program (often referred to as the observer effect). While strace -c still incurs ptrace overhead, it eliminates the I/O bottleneck of streaming textual data, providing a faster and less intrusive snapshot of execution.

Common Usage Examples

Tracing a new command from start to finish:

strace -c ls -la /var/log

Attaching to an existing, long-running process by Process ID (PID) to sample its current behavior (press Ctrl+C to detach and print the summary):

strace -c -p 1234

Sorting the summary output by a specific column using the -S flag (valid sort options include time, calls, name, or nothing):

strace -c -S calls ls -la

Collecting both the real-time event trace and the final summary table together using -C (capital C):

strace -C -o trace_output.txt ls -la

The -c flag is an essential first-response diagnostic tool on Linux systems, providing high-level visibility into kernel-space execution patterns before resorting to deeper, more complex profiling methods.