straceTrace the system calls a process makes
strace shows every request a program makes to the kernel: each file it opens, socket it connects, byte it reads or writes, with arguments, return values and errors. When an app fails with a vague message or hangs, strace tells you exactly what it was doing.
strace [-f] [-tt] [-T] [-e trace=SET] [-s N] [-o FILE] { COMMAND [ARG]... | -p PID }You want to see the conversation between a program and the kernel for the simplest possible case.
straceThe tracer. It attaches to a process with ptrace and prints one line per system call.
strace is built on the ptrace(2) system call, the same mechanism debuggers use. It either starts the command as its own child or attaches to a running PID with PTRACE_SEIZE. It then asks the kernel to stop the tracee at every syscall entry and exit (PTRACE_SYSCALL). At each stop strace reads the syscall number and arguments from the registers (PTRACE_GET_SYSCALL_INFO), copies strings and structs out of the tracee's memory, decodes them into readable form, then resumes it. That is two context switches per syscall, which is why a traced program can run 10 to 100 times slower. Attaching needs the same user and, on Ubuntu, kernel.yama.ptrace_scope=1 limits it to your own children unless you are root (CAP_SYS_PTRACE). Only one tracer can attach at a time, so strace and gdb on the same PID conflict. Output goes to stderr.
strace uses ptrace to make the kernel stop the program at every syscall, reads the arguments, prints them, then lets it continue.
strace calls ptrace(PTRACE_SEIZE) on PID 4211 and asks the kernel to stop it at every syscall entry and exit. This needs root or your own child process.
-p PIDAttach to a running process (detach with Ctrl-C; the process keeps running)-fFollow child processes and threads created with fork/clone-e trace=SETOnly these syscalls: openat,connect or classes like %file, %network, %process-e trace=!SETEverything except these, e.g. trace=!futex,epoll_wait to drop noise-cCount: a table of calls, errors and time per syscall instead of each line-tt / -tttTimestamp each line (microseconds / epoch seconds)-TShow time spent inside each syscall, in <seconds> at the end of the line-s NPrint up to N chars of each string (default 32, so data looks cut off)-o FILEWrite the trace to FILE; with -f each line starts with the PID-y / -yyShow the path or socket address behind each file descriptor-z / -ZOnly show successful / only show failed syscalls--seccomp-bpfWith -f, stop only on traced syscalls: much lower overheadstrace ./app | grep openstrace writes its trace to stderr, so the pipe only carries the app's own stdout and grep finds nothing.
strace -e trace=openat ./app 2>&1 | grep open (or -o trace.txt, then grep the file)strace -p 4211 on a multi-threaded server and seeing nothing-p alone attaches to one thread. The work may happen in other threads, which you are not watching.
sudo strace -f -p 4211Leaving strace attached to a busy production process for minutesEach syscall stops the process twice. Latency jumps, health checks can fail and the load balancer may pull the node.
Trace for seconds, filter with -e, or use timeout 10 strace -c ... for a summaryConcluding the data is truncated because strace shows "GET /api/v1/us"...strace prints only 32 characters of each string by default; the app sent the full request.
strace -s 256 ... to see longer stringsTry these on a Linux machine of your own. Each task has a hint and a solution.
Trace only the files opened when listing ~/app, and spot the libraries ls loads before it reads the directory.
Get a summary table of the syscalls made by 'ls -lR ~/data', without the listing filling the screen.
Run cat on a file that doesn't exist and save the trace to /tmp/t.txt, then find the failing call in it.
Start 'sleep 300 &' and attach strace to it. What syscall is it blocked in? Detach without killing sleep.
straceTrace the system calls a process makes
strace shows every request a program makes to the kernel: each file it opens, socket it connects, byte it reads or writes, with arguments, return values and errors. When an app fails with a vague message or hangs, strace tells you exactly what it was doing.
strace [-f] [-tt] [-T] [-e trace=SET] [-s N] [-o FILE] { COMMAND [ARG]... | -p PID }You want to see the conversation between a program and the kernel for the simplest possible case.
straceThe tracer. It attaches to a process with ptrace and prints one line per system call.
strace is built on the ptrace(2) system call, the same mechanism debuggers use. It either starts the command as its own child or attaches to a running PID with PTRACE_SEIZE. It then asks the kernel to stop the tracee at every syscall entry and exit (PTRACE_SYSCALL). At each stop strace reads the syscall number and arguments from the registers (PTRACE_GET_SYSCALL_INFO), copies strings and structs out of the tracee's memory, decodes them into readable form, then resumes it. That is two context switches per syscall, which is why a traced program can run 10 to 100 times slower. Attaching needs the same user and, on Ubuntu, kernel.yama.ptrace_scope=1 limits it to your own children unless you are root (CAP_SYS_PTRACE). Only one tracer can attach at a time, so strace and gdb on the same PID conflict. Output goes to stderr.
strace uses ptrace to make the kernel stop the program at every syscall, reads the arguments, prints them, then lets it continue.
strace calls ptrace(PTRACE_SEIZE) on PID 4211 and asks the kernel to stop it at every syscall entry and exit. This needs root or your own child process.
-p PIDAttach to a running process (detach with Ctrl-C; the process keeps running)-fFollow child processes and threads created with fork/clone-e trace=SETOnly these syscalls: openat,connect or classes like %file, %network, %process-e trace=!SETEverything except these, e.g. trace=!futex,epoll_wait to drop noise-cCount: a table of calls, errors and time per syscall instead of each line-tt / -tttTimestamp each line (microseconds / epoch seconds)-TShow time spent inside each syscall, in <seconds> at the end of the line-s NPrint up to N chars of each string (default 32, so data looks cut off)-o FILEWrite the trace to FILE; with -f each line starts with the PID-y / -yyShow the path or socket address behind each file descriptor-z / -ZOnly show successful / only show failed syscalls--seccomp-bpfWith -f, stop only on traced syscalls: much lower overheadstrace ./app | grep openstrace writes its trace to stderr, so the pipe only carries the app's own stdout and grep finds nothing.
strace -e trace=openat ./app 2>&1 | grep open (or -o trace.txt, then grep the file)strace -p 4211 on a multi-threaded server and seeing nothing-p alone attaches to one thread. The work may happen in other threads, which you are not watching.
sudo strace -f -p 4211Leaving strace attached to a busy production process for minutesEach syscall stops the process twice. Latency jumps, health checks can fail and the load balancer may pull the node.
Trace for seconds, filter with -e, or use timeout 10 strace -c ... for a summaryConcluding the data is truncated because strace shows "GET /api/v1/us"...strace prints only 32 characters of each string by default; the app sent the full request.
strace -s 256 ... to see longer stringsTry these on a Linux machine of your own. Each task has a hint and a solution.
Trace only the files opened when listing ~/app, and spot the libraries ls loads before it reads the directory.
Get a summary table of the syscalls made by 'ls -lR ~/data', without the listing filling the screen.
Run cat on a file that doesn't exist and save the trace to /tmp/t.txt, then find the failing call in it.
Start 'sleep 300 &' and attach strace to it. What syscall is it blocked in? Detach without killing sleep.