How to Debug Processes Using the strace Command in Linux

When a complex Linux application abruptly crashes, hangs indefinitely, or refuses to open a specific file, debugging the issue using standard log files is often completely useless. If the application developers failed to write comprehensive error logging into their code, you are left completely blind. To bypass the application entirely and spy directly on the raw mathematical conversations happening between the program and the Linux kernel, you must use the strace command.

How the strace Command Works

The strace (System Call Trace) command is a highly aggressive forensic diagnostic tool. Every single time a program wants to do anything on a Linux machine—whether it is reading a file, allocating memory, or sending a network packet—it must politely ask the Linux kernel for permission by executing a “System Call.” The strace command intercepts, records, and translates every single one of these microscopic system calls in real-time.

To trace a program, simply prefix your normal command with strace:

strace cat /etc/passwd

The moment you press Enter, your terminal will instantly explode with hundreds of lines of chaotic, highly technical output before the actual program finishes executing.

openat(AT_FDCWD, "/etc/passwd", O_RDONLY) = 3
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 2841
close(3) = 0

Diagnosing File Permission Errors

The raw output looks intimidating, but it is incredibly easy to read once you know what to look for. The most common use case for strace is diagnosing exactly why a program is failing to start.

Imagine a custom web server daemon keeps crashing immediately upon startup with a generic “Initialization Failed” error. You can run it through the tracer:

strace ./my_web_server

You can aggressively scan the output specifically looking for lines that contain a negative return value (usually indicated by a -1) and an EACCES or ENOENT error code.

openat(AT_FDCWD, "/var/log/server_config.ini", O_RDONLY) = -1 ENOENT (No such file or directory)

In three seconds, strace has completely solved the mystery: The web server is crashing because it is hard-coded to look for a configuration file located at /var/log/server_config.ini, but that file physically does not exist on the hard drive. Without strace, you would have spent hours blindly guessing what the program was trying to do.

Tracing Active Processes

You do not have to restart a program to trace it. If a database process has randomly frozen and is currently chewing up 100% of your CPU, you can use the -p (PID) flag to forcefully attach the tracer to the live, running process.

strace -p 4821

The terminal will instantly begin streaming the live system calls being executed by PID 4821, allowing you to watch the exact infinite loop or network timeout that is causing the freeze.