timeout命令未生效主因是子进程逃逸、SIGTERM被忽略或环境差异；需用--foreground、-k选项、显式检查退出码124，并在systemd/cron中补全PATH和TTY配置。

timeout 命令没生效？先看是不是子进程逃逸了

直接写 timeout 5s bash -c "sleep 10"，超时后 sleep 还在跑——这不是 timeout 失效，而是外层 bash 被杀，内层 sleep 已脱离进程组继续执行。

• 加 --foreground：让命令在当前会话前台运行，避免子 shell 创建新会话导致进程组分裂
• 改用 exec 替代 bash -c：例如 timeout 5s exec sleep 10，避免额外 shell 层级
• 验证是否逃逸：运行后立刻 ps --ppid $(pgrep -f "sleep 10" | head -1)，若父 PID 不是 timeout 进程 ID，说明已逃逸

超时后进程还在？优先用 -k 强制 SIGKILL

timeout 默认只发 SIGTERM（信号 15），很多程序会忽略或捕获它做“优雅退出”，结果卡住不动。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 加 -k 2s：例如 timeout -k 2s 5s ./long-run.sh，先发 SIGTERM，2 秒后不管不顾发 SIGKILL（信号 9）
• 慎用 -s SIGKILL：直接发 SIGKILL 可能导致资源未释放（如临时文件、锁文件残留），-k 更稳妥
• 某些服务（如 ssh、docker run）内部会屏蔽 SIGTERM，必须依赖 -k 才能真正终止

脚本里判断超时，别只靠 && 或 if

if timeout 3s cmd; then echo ok; fi 会把超时（退出码 124）和命令失败（比如返回 1）都当成“非零”进 else 分支，根本分不清是超时还是出错。

• 显式检查 $?：

  timeout 3s some_command<br>case $? in<br>  0) echo "success";;<br>  124) echo "timed out";;<br>  127) echo "command not found";;<br>  *) echo "other error: $?";;<br>esac

• 不要链式调用：timeout 3s cmd && next_step —— 超时会导致 next_step 完全不执行，且无法区分原因
• 封装函数更安全：

  run_with_timeout() {<br>  timeout "$1" "${@:2}"<br>  return $?<br>}

  调用后立刻查 $?，不依赖逻辑运算符

systemd 或 cron 里 timeout 失效？环境变量和会话是关键

交互终端能跑通的 timeout，丢进 cron 就秒退，或在 systemd service 里静默失败，大概率不是命令问题，而是环境缺失。

• cron 默认 PATH 极简：timeout 找得到，但被管控的命令（如 python3、jq）可能找不到，报错退出码 127
• systemd 不分配伪终端（no TTY）：某些命令（sudo、ssh）依赖 TERM 或 stdin/stdout 行为异常，需加 StandardInput=null 或显式指定 PATH
• 调试方法：在 service 或 cron 中先写 env > /tmp/env.log 对比差异，再补全必要变量或绝对路径

实际用的时候，timeout 看似简单，但子进程管理、信号语义、环境隔离这三块最容易漏掉。尤其在自动化任务里，不显式处理退出码 124，后续逻辑就容易误判。