strace Attach to Running Process: Debug Without Restart (2026)

You’re trying to see what a running process is actually doing, down to the system call level, without killing it and restarting. strace is your tool.

Here’s the core problem: A process is misbehaving, maybe hanging, maybe leaking resources, maybe just not doing what you expect. You need to see its interaction with the kernel – file opens, network calls, memory allocations – to understand its behavior.

Common Causes and Fixes for strace Attachment Issues

If strace isn’t attaching to your process, it’s usually one of these:

1. Process is too fast/short-lived: The process starts, does its thing, and exits before strace can even attach.

   • Diagnosis: Try attaching to a process you know will stay alive, like sleep 60. If strace -p <PID> works for sleep but not your target, this is likely it.
   • Fix: Use strace -f -p <PID>. The -f (follow forks) option is crucial. If the target process spawns children, strace will attach to them too. This is often the case for short-lived helper processes.
   • Why it works: -f ensures that strace also attaches to new processes created by fork() or clone(), catching the brief moments when these child processes are active.

2. Permissions Issue (SELinux/AppArmor): Mandatory Access Control systems are preventing strace from peering into the process.

   • Diagnosis: Check /var/log/audit/audit.log (for SELinux) or /var/log/syslog (for AppArmor) for AVC denied or DENIED messages related to strace or the target process.
   • Fix (SELinux): Temporarily set SELinux to permissive mode: sudo setenforce 0. If strace works, you need to create a proper SELinux policy module. For a quick fix (not recommended for production), you can try sudo chcon -C -n /proc/<PID>/syscall.
   • Fix (AppArmor): Find the AppArmor profile for your process (e.g., sudo aa-status). Edit the profile (e.g., /etc/apparmor.d/usr.sbin.yourprocess) and add ptrace capability. Reload the profile: sudo systemctl reload apparmor.
   • Why it works: SELinux and AppArmor restrict what processes can do. ptrace is the system call strace uses to attach and control other processes, and these security modules often block it by default for non-privileged operations.

3. Process is Already Traced: Another tool (or a previous strace instance) already has a debugger attached to the process. A process can only have one tracer at a time.

   • Diagnosis: Run ps -o pid,stat -p <PID>. Look for the t flag in the STAT column. This indicates the process is stopped by a debugger.
   • Fix: Find and stop the other debugger. If it was a previous strace instance, you might need to find its PID (ps aux | grep strace) and kill it (kill <strace_pid>).
   • Why it works: The kernel enforces that only one process can ptrace another. If a debugger is attached, the kernel prevents subsequent ptrace requests.

4. PID is Incorrect or Process Has Died: You’re trying to attach to a PID that no longer exists or was never valid.

   • Diagnosis: Double-check the PID with ps -p <PID>. If ps returns nothing or an error, the PID is invalid.
   • Fix: Obtain the correct, current PID of the running process. Use pgrep <process_name> or ps aux | grep <process_name> to find it.
   • Why it works: strace -p requires a valid, active process ID to function.

5. ptrace_scope Restriction: Modern Linux kernels have a security feature (kernel.yama.ptrace_scope) that limits which processes can be traced. By default, it might only allow tracing child processes or processes in the same user namespace.

   • Diagnosis: Check the current setting: cat /proc/sys/kernel/yama/ptrace_scope. A value of 0 is unrestricted, 1 allows only parent->child tracing, 2 allows only same-process-tree tracing, and 3 is most restrictive.
   • Fix: For testing or if you understand the security implications, you can temporarily lower it: sudo sysctl kernel.yama.ptrace_scope=0. To make it permanent, edit /etc/sysctl.conf and add kernel.yama.ptrace_scope = 0, then run sudo sysctl -p.
   • Why it works: This kernel parameter is a security measure to prevent user-level processes from arbitrarily attaching to and inspecting other processes, which could be a vector for privilege escalation or data theft. Setting it to 0 disables this restriction.

6. Process is in a Different PID Namespace: If the process is running in a container (like Docker) or a different user/mount namespace, strace run from the host might not see it, or vice-versa.

   • Diagnosis: Check if the process is in a container using docker ps or kubectl exec to see if you can run commands inside the container’s context.
   • Fix: Run strace from within the container’s environment. If you’re on the host and want to trace a container process, you might need to use docker attach or a tool that can bridge namespaces if strace itself doesn’t support it directly across namespaces without specific kernel configurations.
   • Why it works: PID namespaces isolate process trees. A process with PID 1 inside a container is not PID 1 on the host. strace operates within the context of the namespace it’s run in.

The next error you’ll likely hit after fixing these is strace: attach: No such file or directory if the PID disappears between your ps command and your strace command, or a permission error if you miss a subtle SELinux rule.