问题摘要:
Jenkins LTS + 如果在任务运行期间重新启动 Jenkins 服务,则 Durable Task 插件无法正确恢复管道作业。
这是 Jenkins 2.3x 中的回归,似乎与迁移到 systemd(它在 2.2x 中运行得很好)。
相关 Jenkins 问题链接:https://issues.jenkins.io/browse/JENKINS-69061
重现问题的步骤:
- 从单节点 Jenkins 主机开始持久任务插件已安装。
- 在主机上启动管道作业。我在本问题的底部附上了一个示例管道文件。
- 运行时,重新启动jenkins服务“service jenkins restart”(或使用jenkins-cli.jar重启)
- Jenkins 启动后,任务尝试恢复,但最终失败(日志如下)。
Resuming build at Tue Jul 19 23:26:56 UTC 2022 after Jenkins restart
Waiting to resume part of test-job #5: Waiting for next available executor
Ready to run at Tue Jul 19 23:27:01 UTC 2022
wrapper script does not seem to be touching the log file in /data/jenkins_home/workspace/test-job@tmp/durable-b0167617
(JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
抛出上述消息后,作业进入“失败”状态。
- 手动触摸/写入提到的日志文件不能解决问题。
- 问题不是文件系统或可用内存,正如其他解决方案在相关票据/帖子中提到的那样。(这是 Jenkins 最新版本的回归。)
- 没有可用的插件更新(完全最新)。
- 这似乎发生在我们升级到 2.332 版本时,该版本还包含迁移到 systemd。因此,使用 systemd(相对于 2.332 之前使用的旧 init 系统)重启服务可能会破坏持久任务。
该问题已在 Jenkins 官方跟踪器上提交:https://issues.jenkins.io/browse/JENKINS-69061
然而,两个多月以来没有人对该报告做出回应,所以我想问一下这里有没有人知道这个问题可能是什么,如何找到潜在的解决方法,以及如何全面提高问题的可见性/吸引力。
测试此问题时使用的最小/简单管道示例:
pipeline {
agent any
stages {
stage("Sleep for 60 seconds") {
steps {
echo "Go restart jenkins service now and see that this job wont resume"
sh "sleep 60"
echo "The job will never get this far"
}
}
}
}
答案1
我用我掌握的信息回答我自己的问题,但这并不是回归错误的真正解决方案。
原因摘要:
- Jenkins 团队似乎在 2.332.1 中破坏了此功能。我的理论是,这是由于此处记录的 init 系统迁移造成的:https://www.jenkins.io/blog/2022/03/25/systemd-migration/
解决方法(解决方案):
此问题似乎仅影响每个 Jenkins 控制器上包含的“内置”构建代理。您需要禁用内置代理并添加自己的自定义代理。
- 创建代理:
- 即使对于单节点独立安装也要这样做(是的,这对于开发环境来说很烦人)
- 常规 Java 代理可以工作。但是,即使尝试了各种解决方法,我还是很难让 jnlp Java 代理绕过 $JENKINS_URL 值,而且据我所知,不可能让 jnlp 直接连接到“localhost”。因此,我无法在主 $JENKINS_URL 前面有反向代理和 2FA 的生产主机上实现此功能。
- SSH 代理也很好用,我最终使用了它控制器基本上只需通过 ssh 进入其自身:https://plugins.jenkins.io/ssh-slaves/
- 禁用内置代理:
- 一旦新的代理上线并开始工作,您需要配置您的作业以使用新的代理或(更容易)将内置代理上的执行器数量设置为 0。