Linux服务超时强制杀需两阶段：先发SIGTERM并启动倒计时，超时未退出再发SIGKILL；timeout命令最简实现，服务自身应通过sigaction注册SIGTERM与SIGALRM协同清理，禁用kill -9以防资源泄漏。
Linux中服务收到信号后实现超时强制杀，核心不是“等信号再启动计时”，而是用信号机制本身构建一个带时限的响应流程：先发可捕获的终止信号（如SIGTERM），同时启动一个倒计时器；若倒计时结束前服务未退出，再发不可捕获的SIGKILL。这本质上是两阶段退出控制，依赖信号+定时器协同。
用timeout命令最简单直接
对单次命令或短生命周期服务，timeout 是现成方案：
- 默认发送 SIGTERM，超时后自动补发 SIGKILL（除非用
-s指定其他信号） - 例如：
timeout 30s ./myserver—— 启动服务，30秒内没退出就强杀 - 可自定义信号：
timeout -s SIGUSR2 10s ./myserver，超时发 SIGUSR2 而非 TERM - 退出码为 124 表示超时被杀，可用于脚本判断
服务自身实现优雅超时退出
长期运行的服务（如Web服务器、守护进程）需自己处理信号和超时逻辑：
- 注册 SIGTERM 处理函数，在其中启动清理流程，并调用
alarm(30)或setitimer()设置30秒后触发 SIGALRM - SIGALRM 的处理器里调用
exit()或直接kill(getpid(), SIGKILL) - 关键点：清理过程中若已退出，需在退出前取消定时器（
alarm(0)），避免误杀 - 注意
signal()不可靠，应优先用sigaction()注册，屏蔽被中断的系统调用（如read()可能返回 EINTR）
运维侧配合：脚本化两阶段终止
不修改服务代码时，靠外部脚本协调：
- 先
kill $PID（即 SIGTERM），立即记录当前时间 - 循环检查
kill -0 $PID 2>/dev/null是否成功（进程是否还存活） - 每秒检查一次，累计满30秒仍存活，执行
kill -9 $PID - 生产环境建议加日志：
echo "$(date): sent SIGTERM to $PID" >> /var/log/myapp/stop.log
为什么不能只靠 kill -9？
因为 SIGKILL 无法被捕获或忽略，服务来不及做任何清理：
- 数据库连接未关闭 → 连接池泄漏、事务残留
- 临时文件未删除 → 磁盘空间缓慢耗尽
- 共享内存/信号量未释放 → 下次启动失败
- 日志缓冲未刷盘 → 最后几条关键日志丢失
