Trace System Calls Using strace

System Call Tracing

strace attaches to a process (or launches one) and prints each syscall with arguments and return values. It is the fastest way to see what a closed binary actually requests from the kernel.

Reading strace Lines

Example line:

cCopy
Loading…

• Syscall name and args
• Return value (6 bytes written)
• = -1 EACCES signals failure

For example, comparing strace ls vs strace cat shows getdents64 directory reads versus sequential read on one file.

Why This Matters in Production

strace is the first tool SRE teams reach for when a production service mysteriously hangs on a file or socket operation, since it can reveal a blocked read() or a repeated ENOENT on a missing config file without recompiling anything. The -c summary mode you practice here is exactly what engineers use to spot syscall-count regressions, like a library that unexpectedly started calling stat() in a hot loop.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will trace provided programs and answer questions about syscall counts and failure paths. The task asks you to correlate openat failures with errno values seen in application logs.