strace 不能直接捕获“超时”这类逻辑错误，它只记录系统调用的发起、返回及耗时，不理解业务语义；超时是应用层或库函数触发的控制流跳转，strace 仅能观察其依赖的系统调用是否阻塞，如 recvfrom 长时间未返回、epoll_wait 持续阻塞等。
strace 能否直接捕获“超时”这类逻辑错误
不能。strace 只记录系统调用的发起、返回及耗时，不理解业务语义。所谓“超时”，通常是应用层（如 Nginx 的 proxy_read_timeout）或库函数（如 curl_easy_setopt 设置的 CURLOPT_TIMEOUT）触发的控制流跳转，strace 看不到这些判断逻辑，只能看到其背后依赖的系统调用是否卡住——比如 recvfrom 长时间没返回、epoll_wait 一直阻塞、或 connect 返回 EINPROGRESS 后迟迟不就绪。
关键要跟踪哪些系统调用和信号
Web 服务超时问题通常集中在 I/O 等待环节，优先关注：
-
connect：连接建立是否卡在三次握手（如 SYN_SENT 状态下无响应） -
recvfrom/read：后端响应迟迟未到达，或客户端读取缓慢 -
sendto/write：发送缓冲区满、对端接收窗口为 0 导致阻塞 -
epoll_wait/poll/select：事件循环卡住，说明没有就绪的 fd（可能因上游未发数据、下游未消费） -
clock_gettime和gettimeofday：确认超时判断是否由高精度计时器触发（常配合alarm或timerfd_create） -
sigreturn和rt_sigprocmask：检查是否被SIGALRM中断，这是很多超时实现的底层机制
实际抓取命令怎么写才不漏关键信息
直接对主进程 strace -p PID 往往不够——Web 服务多线程/多进程，主线程可能只做 accept，真正处理请求的是 worker 进程。必须跟踪到具体处理请求的上下文：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 对 Nginx：先
ps aux | grep nginx找出 worker 进程 PID，再strace -T -tt -e trace=connect,recvfrom,read,sendto,write,epoll_wait,poll,select,clock_gettime,gettimeofday,sigreturn -p <pid></pid> - 对 Gunicorn/Uvicorn：用
strace -f -T -tt -e trace=... python app.py，其中-f必须加，否则子进程调用全丢失 - 避免日志刷屏：加
-s 128控制字符串截断长度，加-o strace.log输出到文件；若怀疑 DNS 延迟，额外加getaddrinfo（但注意它本质是库函数，glibc 内部可能转为socket+connect+read） - 别用
-v：过度展开结构体反而掩盖时间戳和返回值，排查超时反而更难
怎么看日志里哪次调用真“超时”了
strace 输出中每行末尾的 是该系统调用实际耗时（秒），这是唯一能定位“卡点”的依据。重点关注：
- 连续多个
epoll_wait返回0（超时）且—— 说明事件循环按秒级 timeout 轮询，但始终无事件，需查上游是否停发、下游是否堆积 -
recvfrom耗时突然跳到几秒甚至几十秒 —— 直接对应应用层报出的 read timeout，此时应结合网络抓包确认对端是否真的延迟发包 -
connect耗时约 25–30 秒 —— 典型 TCP connect 默认超时，说明目标地址不可达或防火墙丢弃 SYN - 同一 fd 上
write后紧跟着epoll_wait长时间阻塞 —— 可能对端接收缓慢或网络中间设备限速
真正的难点不在捕获，而在于把 strace 时间戳和应用日志里的“超时发生时间”对齐——系统调用返回耗时长 ≠ 应用判定超时的时间点，中间还隔着调度延迟、锁竞争、GC 等干扰。务必用 -tt（微秒级时间戳）并同步服务器时钟。
