Trace a container process's syscalls from the host

WHAT THIS TESTS It verifies you understand that container isolation is namespaces over a shared kernel, so the host can observe a container process directly without any in-container tooling.

A GOOD ANSWER COVERS The key realization is that the container process is a normal process on the host, just remapped by PID and other namespaces. So you find its host PID with docker inspect --format '{{.State.Pid}}' <container> or docker top <container>, then run strace -p <host_pid> as root on the host. The kernel records syscalls regardless of namespace boundaries. If you need the container's own filesystem and tooling view, use nsenter --target <pid> --all to enter its namespaces while using host binaries. For broader visibility, perf trace or bpftrace can trace syscalls system-wide and filter by PID, which is lower overhead than strace's ptrace.

COMMON WRONG ANSWERS Insisting you must add strace to the image and rebuild. Trying docker exec when the image has no shell or no strace. Forgetting that strace requires CAP_SYS_PTRACE or root, and that the container PID differs from the host PID.

LIKELY FOLLOW-UPS Why is the in-container PID different from the host PID? What is the overhead of ptrace versus eBPF tracing? How does nsenter differ from docker exec?

ONE CONCRETE EXAMPLE A scratch-based Go service hangs. docker inspect shows .State.Pid is 48213. From the host you run strace -f -p 48213 and see it blocked on a futex waiting on a connection that never resolves, pinpointing a deadlock without ever touching the minimal image.