strace -p PID 是最常用起点，但必须加 -f 才能跟踪子进程；默认输出冗杂，需用 -e trace=、-z、-s、-T 和 -o 等选项精准过滤、防截断、计时并落盘分析。
直接用 strace -p PID 附加到运行中的进程，是最常用、最有效的起点；但不加 -f 就看不到子进程调用，90% 的线上服务问题会因此漏掉关键线索。
怎么快速 attach 到一个正在跑的进程
先用 ps 或 pidof 拿到 PID，比如查 nginx 主进程：
pidof nginx（通常返回主进程 PID，如 1234）
然后立刻 attach：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
strace -p 1234—— 只跟踪主进程，适合极简排查 -
strace -f -p 1234—— 必须加-f，否则 worker 进程、fork 出的子任务全看不到 - 按
Ctrl+C可安全退出，原进程不受影响 - 如果提示
Operation not permitted，说明权限不够：普通用户只能跟踪自己启动的进程；跟踪 root 进程必须加sudo
为什么输出里全是 open/read/write，却找不到错误源头
默认输出太杂，关键失败项（返回 -1）被淹没在成百上千行中。要定位真实问题，得主动过滤：
- 只看失败调用：
strace -e trace=all -z -p 1234，-z会让所有= -1行带标记（如open("/etc/ssl/certs", ...) = -1 EACCES (Permission denied)） - 只盯文件访问：
strace -e trace=open,openat,stat,fstat,read -p 1234，避免被futex、epoll_wait等干扰 - 加
-s 1024防止路径被截断（默认只显示 32 字节），否则你看到的是open("/var/log/app/2026-09-xx-...", ...)，根本不知道具体是哪个日志文件
如何保存完整日志用于事后分析
终端滚动太快，靠眼睛盯几乎不可能发现耗时异常或调用顺序问题。必须落盘：
-
strace -f -o /tmp/trace.log -s 1024 -T -p 1234是线上排查黄金组合：-T显示每次系统调用耗时（如），-o写入文件，-s 1024防截断 - 如果进程有大量子进程（如 Python 多进程、Java fork），加
-ff配合-o，会生成trace.log.1234、trace.log.1235等独立文件，比混在一起好分析得多 - 别用重定向
>替代-o：strace 输出走 stderr，>只捕获 stdout，会导致日志为空
常见误操作和隐性坑
很多问题不是 strace 不好用，而是用法踩了内核或工具链的边界：
- 同一个进程不能同时被
strace和gdbattach：ptrace是独占机制，强行双开会报Operation not permitted -
-f跟踪多线程程序时，实际抓到的是 clone/fork 出的子进程，不是 pthread 线程本身——想看线程级调度，得配合perf或/proc/PID/status查Threads:行 - 某些容器环境（如 rootless Podman）或启用了
ptrace_scope=2的系统，普通用户连自己的进程都 attach 不上，需临时改/proc/sys/kernel/yama/ptrace_scope（仅调试用） - 输出里看到大量
futex(0x..., FUTEX_WAIT_PRIVATE, 0, NULL)卡住？这不是错误，是线程在等锁；重点看它前面有没有write失败或connect超时
