Rundeck作业异常求助：运行超1小时后停滞为“Running”状态

我之前在维护Rundeck 2.x版本时，刚好碰到过和你一模一样的问题——文件存储下长作业超1小时就卡Running、日志断更，远端结束后还得手动终止，而且一开始也没在日志里找到有效线索。结合当时的排查和解决经验，给你几个具体的方向：

1. 检查日志写入的超时配置 #

这大概率是触发了Rundeck文件存储的日志空闲超时限制。在rundeck-config.properties里有个rundeck.logs.file.timeout参数，默认值刚好是3600秒（1小时），超过这个时间如果作业日志没有新输出，Rundeck会关闭日志文件句柄，后续日志就写不进去，同时因为没收到作业结束的信号，状态一直停在Running。

• 把这个参数改成更大的值（比如rundeck.logs.file.timeout=7200），或者直接设为0禁用超时，然后重启Rundeck服务。

2. 优化远端执行器的心跳机制 #

如果作业在远端节点长时间无输出，Rundeck和节点的SSH连接可能因为心跳不足被断开，导致状态同步中断：

• 打开framework.properties，找到rundeck.ssh.keepAliveInterval，默认是0（不发心跳），改成30（每30秒发送一次心跳包）。
• 同时检查远端节点的SSH服务配置，确保没有ClientAliveInterval这类短超时设置，避免节点主动断开连接。

3. 修复作业状态同步逻辑 #

有时候远端作业已经结束，但Rundeck没收到结束信号，导致状态一直卡着：

• 可以在作业的最后一步添加主动状态上报，比如执行echo "RD-JOB-COMPLETE"，Rundeck会识别这个特殊标记，自动更新作业状态为完成。
• 另外检查framework.properties里的executor.threadpool.size，如果线程池满了，状态更新的线程会被阻塞，适当调大这个值（比如从默认10改成20）。

4. 排查文件存储的性能瓶颈 #

基于文件的数据存储在处理长作业时，可能遇到磁盘IO瓶颈或者文件锁问题：

• 用iostat命令检查Rundeck存储目录（默认/var/lib/rundeck）所在磁盘的IO使用率，如果IO负载过高，考虑把存储目录迁移到性能更好的磁盘。
• 可以临时切换到数据库存储测试（虽然2.10.4版本配置稍繁琐），如果问题消失，说明确实是文件存储的性能限制导致的。

临时应急方案 #

如果暂时没法修改配置，遇到卡Running的作业时：

• 先在远端节点确认作业已经结束，然后用Rundeck CLI命令手动终止：rd-job stop --jobid <你的作业ID> --project <项目名>，比UI手动终止更可靠。
• 去看Rundeck的service.log（不是作业日志），底层的连接异常、线程阻塞信息通常会在这里记录，之前没找到有效信息可能是看的日志文件不对。

内容的提问来源于stack exchange，提问作者MKO