TMOUT变量需设为整数、全局导出且在shell启动时存在才生效；仅作用于交互式shell，受SSH保活、终端复用工具及后台命令干扰，可靠方案需结合PAM limits、timeout命令等。
TMOUT 变量为什么没生效
Linux 中设置 TMOUT（注意拼写，不是 TMOUT）会导致完全失效。系统只认 TMOUT，且必须是整数、全局变量、且 shell 启动时已存在。
-
TMOUT必须在/etc/profile或/etc/bash.bashrc里用export TMOUT=300形式声明，不能只写TMOUT=300 - 如果用户已有自己的
~/.bashrc，它可能覆盖系统级设置，需检查是否执行了unset TMOUT或重新赋值为 0 -
TMOUT对非交互式 shell（比如bash -c "echo hello"）无效，只作用于登录 shell 和交互式 bash - 某些终端复用工具（如
tmux、screen）会重置或忽略TMOUT，需在其配置中单独处理
ssh 登录后超时不触发的常见原因
即使 TMOUT 正确设置，SSH 连接常因网络保活机制掩盖空闲状态，导致实际不退出。
- OpenSSH 服务端的
ClientAliveInterval和ClientAliveCountMax会抢先断连，此时 shell 根本没机会检测TMOUT；建议把服务端心跳设得比TMOUT大（例如TMOUT=300时，设ClientAliveInterval 400） - 部分 SSH 客户端（如 Windows 上的 PuTTY）默认开启“发送空包”保活，会持续刷新 shell 的空闲计时器，让
TMOUT始终归零 - 只要终端有任意输出（包括命令执行后的 prompt），
TMOUT计时就会重置——所以watch date这类命令会让超时彻底失效
如何让超时更可靠（不只是靠 TMOUT）
TMOUT 是最轻量的方式，但依赖 shell 自身行为，对抗后台任务、长运行命令、伪终端等场景乏力。
- 对关键运维账号，建议在
/etc/security/limits.conf中加* soft timeout 300（需 PAM 模块支持pam_time.so） - 用
timeout命令包装单次操作：比如timeout 60s vi /tmp/file，避免编辑器长期占用 - 若需强制登出所有超时会话，可配合
pkill -u username+loginctl terminate-user username（systemd 系统）定期清理残留 -
TMOUT不影响 root 用户？错。root 同样受控，但若使用sudo -i进入，新 shell 可能未继承环境变量，需确认env_reset是否关闭
脚本里误用 TMOUT 的典型错误
在自动化脚本中直接 export TMOUT，往往导致不可预期中断，尤其调用子 shell 或管道时。
-
TMOUT是 shell 内建变量，子进程（如$(cmd)、|后的命令）不会继承，但当前 shell 的后续命令会受影响 - 写成
TMOUT=60; some_command是危险的：如果some_command卡住超过 60 秒，整个脚本会被 kill，而非仅该命令 - 正确做法是用
timeout：例如timeout 60s ssh user@host 'long-task.sh'，精准控制目标命令生命周期 - 测试时别用
sleep验证——sleep不读取 stdin，而TMOUT超时判断基于“无输入”，真实场景下键盘静默才触发
真正麻烦的是那些不读 stdin 却长期运行的后台命令（比如 tail -f、journalctl -f），它们会让 shell 一直卡在等待输入状态，TMOUT 完全失焦。这时候得靠外部监控或改用 timeout --foreground 配合信号处理。
