Tracing System Calls with strace and ltrace

CPU, memory, and I/O tools tell you that something is slow. To learn why, you trace what a process actually asks the kernel to do. strace and ltrace open that window.

strace records every system call: file opens, reads, network sends, and their return values, including errors.

Use -p PID to trace something already running, such as a stuck service.

-e trace= limits output to calls you care about, e.g. only file-related ones.

A classic use: see which file a program fails to open. Look for ENOENT (no such file) in the output.

-c prints a profile: which syscalls consumed the most time and how often each was called.

-T shows how long each syscall took, and -t adds timestamps, pinpointing where a process blocks.

-f follows forks so you trace child processes too, essential for servers that spawn workers.

Traces are noisy; -o writes them to a file you can grep later without cluttering the terminal.

While strace shows kernel calls, ltrace shows library calls like malloc or strcmp, useful for logic-level debugging.

When a service hangs: attach with strace -f -p, watch for a syscall that never returns (often a blocked read or connect), and you have found the stall.

What kind of activity does strace primarily reveal?

You can now trace a process at the syscall level:

• strace cmd or -p PID to attach
• -e trace= filters, -c profiles, -T/-t time
• -f follows children, -o saves output
• ltrace shows library calls

Watch for errors like ENOENT or a syscall that never returns.