strace vs ltrace

Two tools; different layers.

strace: syscall-level

strace traces system calls at the process-to-kernel boundary. The right tool for IO, network, and child-process debugging where the answer lives in what the process asked the kernel to do.

• System call tracing. Captures open, read, write, connect, fork; the process-to-kernel boundary in detail.
• Useful for IO and network issues. File access, network connection, child process investigation; standard fits for "what is the process trying to do" questions.
• Output shape. One line per syscall with arguments and return value; easy to grep, easy to redirect to file.
• Filter flags. -e trace=network,file cuts noise to relevant syscalls; without filtering, strace output overwhelms.

ltrace: library-call-level

ltrace traces library function calls at the application-to-library boundary. Closer to application semantics than strace; the right tool for memory and library-API issues where the answer lives at a higher abstraction layer.

• Library function tracing. Captures malloc, printf, strcpy; the application-to-library boundary rather than syscall boundary.
• Useful for memory and library issues. Allocation patterns, library API misuse, higher-level behaviour view that strace cannot give.
• Less granular than strace. Closer-to-application output; easier to read when the bug is at the library layer.
• Symbol filter. -e malloc+free cuts noise to the calls you actually care about.

When to use which

The decision is layer-driven. Syscall-layer issues belong to strace; library-layer issues belong to ltrace; both are safer than attaching gdb to a running production process.

• IO or network issue: strace. Syscalls are the right level; the answer lives in what the kernel was asked to do.
• Library bug or memory issue: ltrace. Library functions are the right level; the answer lives at the application/library interface.
• Both safer than gdb. Read-only inspection posture; less risk than attaching a debugger that can pause execution.
• Documented choice per investigation. "Used X because Y" note in the postmortem supports later clarity.

Operating in production

Both tools add overhead. Brief attaches only, save output to a file, document the detach plan; forgetting an attached strace can degrade a production process for hours.

• Both add overhead. Process slowdown cost varies; neither is suitable for steady-state production tracing.
• Brief attaches during incidents. strace -p PID short capture, time-bounded; detach as soon as you have the data.
• Save output to file. -o /tmp/trace.txt redirect avoids terminal flooding and supports later analysis.
• Documented detach plan per attach. Named exit so the trace does not stay attached when the engineer walks away.