Jenkins仅单个Job的Git Poll SCM轮询失效问题排查

这类单Job Git SCM轮询停摆、其余Job正常、手动构建无异常且无报错日志的情况，核心原因都是轮询调度链路出现了无报错的静默阻塞，常见触发场景如下：

• 该Job的轮询线程在上次执行（即日志记录的2022年6月9日19:31:00那次轮询）时僵死：比如遇到Git仓库目录锁未释放、网络半连接无超时、工作区文件句柄泄漏，线程会一直卡在等待状态且不抛出异常，占死该Job唯一的轮询任务槽位，后续所有轮询调度信号都会被直接丢弃，不会产生新的日志。由于手动构建走独立的构建线程池，不受轮询线程僵死影响，所以可以正常拉取代码完成构建。
• Job轮询触发器的内存注册信息失效：如果在问题出现前做过Git插件、调度相关插件的热重载，或者通过REST API、脚本批量修改过Job配置，可能出现磁盘上存储的cron配置仍然是* * * * *，但内存里的调度器已经把该Job的轮询任务标记为失效，扫描轮询任务时直接跳过，全程不会输出错误日志。
• 存在僵死的构建记录：如果该Job有历史构建状态异常卡在“进行中”，Git轮询逻辑默认会跳过正在构建的Job避免重复触发，这个判断逻辑不会输出任何提示日志，也会导致轮询看起来完全停摆。

按操作成本从低到高依次执行，每做完一步等待1分钟观察Git Polling日志是否有新记录，恢复即可停止后续操作：

• 清理僵死构建
  进入该Job的构建历史列表，查找是否存在状态一直显示“进行中”但实际早就停止输出日志的构建项，点进对应构建页点击「强制终止构建」即可。
• 重新注册轮询触发器
  进入该Job的配置页面，不需要修改任何配置项，直接点击底部的「保存」按钮。这个操作会强制调度器清除该Job旧的轮询任务实例，按照当前配置重新注册新的轮询任务，90%以上的这类静默故障都可以通过这一步解决。
• 中断僵死轮询线程
  如果上一步操作无效，进入Jenkins管理后台的「系统监控」-「线程Dump」页面，搜索包含该Job名称、关键词为SCMTrigger或Poll SCM的线程，若线程状态显示为BLOCKED或WAITING，且栈信息卡在文件锁、网络IO等待位置，直接通过页面的中断功能终止该僵死线程即可。
• 清理本地轮询锁文件
  如果以上操作都无效，登录Jenkins服务器，进入Jenkins主目录下的jobs/<对应Job的名称>路径，删除目录下的.pollingLock锁文件和旧的scm-polling.log文件，回到Jenkins页面对该Job执行「从磁盘重载配置」操作即可。

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