strace能直接暴露程序崩溃、卡死、读写失败根源，但必须配合-f（跟踪子进程）、-e trace=openat,open,read,write,connect,close（聚焦关键调用）、-s 256（防参数截断）、-y（显示fd真实路径）等选项才有效；否则易漏调用、被噪声淹没或无法识别具体文件/错误。
strace 能直接暴露程序崩溃、卡死、读写失败的根源，但必须配合 -f、-e、-s 等关键选项才有效；不加 -f 会漏掉子进程调用，不加 -e trace=... 容易被海量无关输出淹没。
跟踪正在运行的进程时为什么看不到关键错误？
常见现象是执行 strace -p PID 后输出飞快滚动，却找不到 open 失败或 connect 拒绝等线索。根本原因是默认跟踪所有系统调用，而多数调用（如 rt_sigreturn、clock_gettime）与故障无关。
- 用
-e trace=openat,open,read,write,connect,close,stat锁定 I/O 和网络相关调用 - 务必加
-f：很多服务（如 nginx、java 应用）启动后立刻 fork 子进程，不跟子进程就等于没跟踪主体 - 加
-s 256防止路径或参数被截断（默认只显示前 32 字符），否则openat(AT_FDCWD, "/etc/myapp/conf.d/...", ...)可能变成openat(AT_FDCWD, "/etc/myapp/conf.d/...", ...)，看不出具体文件名 - 加
-y可让read(3/var/log/app.log>, ...)这类输出直接显示 fd 对应的真实路径，省去手动查/proc/PID/fd/3
启动即失败的服务怎么抓到第一手错误？
如果程序 ./myapp 执行后秒退，直接 strace ./myapp 可能连错误都来不及看到就退出了。这时必须把输出落地并覆盖全生命周期。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
strace -f -o trace.log -T ./myapp --config /etc/myapp.conf，其中-T显示每次调用耗时，方便发现卡住的点（比如某次open耗时 5 秒，可能挂载点已 hang） - 运行完立即
grep -E "(ENO|EACCES|ENOT|ECONN|EINVAL)" trace.log，快速定位错误码行——ENOENT是文件不存在，ECONNREFUSED是后端未监听，EINVAL常见于共享内存参数非法 - 不要依赖
strace -c统计：它只给汇总，不保留原始调用上下文，对定位“为什么失败”基本无用
如何确认是程序自己退出还是被外部杀死？
strace 输出末尾的提示语是关键判据，但容易被忽略。
- 看到
+++ killed by SIGKILL +++或+++ killed by SIGTERM +++：说明有其他进程发信号终止了它（比如 systemd 超时重启、监控脚本误杀） - 看到
+++ exited with 1 +++（数字为退出码）：程序自身调用exit_group退出，需结合上文找触发点，比如前一行是open(...)= -1 ENOENT，那大概率是加载配置失败后主动退出 - 若最后一行是
wait4(-1, <unfinished >然后戛然而止：可能是进程卡在某个系统调用里没返回，需要看它阻塞前的操作（如poll等待一个永远不就绪的 fd）
真正难的不是跑通 strace 命令，而是从几千行输出里识别出那一两行决定性的错误线索——它往往藏在看似正常的调用序列之后，比如连续三次 read(3, "", 4096) = 0 接着反复 poll(..., POLLIN, 0) = 1，说明程序没处理 EOF 就陷入空轮询。这种细节，只有带着明确怀疑去看，才能一眼抓住。
