文章目录服务器没有重启Java服务为什么自动重启一次Ubuntu自动更新导致Supervisor服务重启的排查实录故障背景故障现象exit status 143是什么意思SIGTERM和SIGKILL区别排查Supervisor是否异常继续追查是谁触发systemd停止服务定位Ubuntu自动更新任务完整故障链路分析为什么升级glibc会影响业务服务这次问题为什么不容易发现服务器没有重启Java没有崩溃Supervisor没有故障生产环境优化建议生产服务器关闭自动升级设置统一维护窗口完善服务监控总结服务器没有重启Java服务为什么自动重启一次Ubuntu自动更新导致Supervisor服务重启的排查实录故障背景在生产环境运维过程中经常会遇到这样的问题服务器看起来一切正常没有发生重启但是业务服务突然出现短暂中断然后自动恢复。这类问题往往比较隐蔽。如果只看应用日志很容易误判为Java应用异常退出JVM崩溃Supervisor异常服务器故障但实际生产环境中还有一种情况容易被忽略Linux系统自动维护任务可能会间接影响业务服务。本文记录一次真实生产环境问题排查过程Ubuntu服务器上的Java服务凌晨自动重启通过Supervisor、systemd、apt日志逐层分析最终定位到unattended-upgrades自动升级glibc组件导致systemd重新加载服务。故障现象业务反馈2026年5月20日 06:15左右业务接口出现短暂异常。查看服务器上的Supervisor日志tail-100/var/log/supervisor/supervisord.log发现2026-05-20 06:15:58,750 INFO waiting for filebeat, server, server2 to die 2026-05-20 06:15:58,883 WARN received SIGTERM indicating exit request 2026-05-20 06:16:00,193 WARN stopped: server2 (exit status 143) 2026-05-20 06:16:02,958 WARN stopped: server (exit status 143) 2026-05-20 06:16:03,983 INFO stopped: filebeat (exit status 0)从日志来看server停止server2停止filebeat停止随后服务重新启动初步判断业务进程不是崩溃而是被主动停止。图片说明Supervisor收到SIGTERM信号Java服务退出状态为143。exit status 143是什么意思很多运维人员看到exit status 143第一反应服务异常退出实际上并不是。Linux进程退出码规则退出码 128 信号编号其中SIGTERM信号编号15所以128 15 143因此exit status 143表示进程收到SIGTERM信号并进行了正常退出。也就是说这不是kill-9PID强制杀死。而是kill-15PID优雅终止。SIGTERM和SIGKILL区别信号编号说明SIGTERM15请求程序优雅退出SIGKILL9强制立即结束SIGINT2CtrlC中断生产环境中正常停止服务systemctl stop xxx通常发送SIGTERM给应用一个机会保存数据关闭连接提交事务排查Supervisor是否异常查看Supervisor状态systemctl status supervisor结果Active: active (running) Main PID: 917203 (supervisord) Active since: Tue 2026-05-20 06:16:04 UTC发现Supervisor刚刚启动。说明Supervisor不是一直运行。它在06:16:04重新启动。继续查看systemd日志journalctl-usupervisor--since2026-05-20 06:10:00--until2026-05-20 06:20:00发现May 20 06:15:58 systemd[1]: Stopping supervisor.service关键点不是Supervisor自己退出。而是systemd主动停止了Supervisor。继续追查是谁触发systemd停止服务继续查看系统日志journalctl\--since2026-05-20 06:14:00\--until2026-05-20 06:17:00发现关键日志May 20 06:15:49 cbf systemd[1]: Reexecuting requested from client PID 916314 (systemctl)同时发现May 20 06:15:32 cbf systemd[1]: Starting apt-daily-upgrade.service这里出现了重要线索apt-daily-upgrade.serviceUbuntu自动更新任务。定位Ubuntu自动更新任务Ubuntu默认开启unattended-upgrades用于自动安装安全补丁系统组件更新查看日志cat/var/log/unattended-upgrades/unattended-upgrades.log发现2026-05-20 06:15:33 INFO Starting unattended upgrades script 2026-05-20 06:15:45 INFO Packages that will be upgraded: libc-bin libc-dev-bin libc-devtools libc6 libc6-dev locales最终确认此次自动升级内容libc6 libc-bin locales其中libc6就是Linux系统核心运行库glibc。完整故障链路分析最终整个过程如下Ubuntu unattended-upgrades | | 自动升级glibc(libc6) | | systemctl触发systemd reexec | | systemd重新加载服务 | | supervisor.service停止 | | 执行ExecStop: supervisorctl shutdown | | Supervisor发送SIGTERM | | Java服务退出 (exit status 143) | | supervisor重新启动 | | Java服务重新运行为什么升级glibc会影响业务服务很多人可能会疑惑更新一个系统库为什么会影响Java服务原因Linux应用运行时依赖系统基础库。例如Java | JVM | 系统调用 | glibc | Linux Kernelglibc属于Linux最核心的基础组件之一。升级glibc后新启动进程使用新版本老进程仍然使用旧内存映射systemd可能执行重新加载为了保证系统状态一致部分服务可能被重新启动。这次问题为什么不容易发现因为几个现象很容易误判。服务器没有重启执行uptime-s发现服务器启动时间正常。所以排除服务器宕机云主机重启Java没有崩溃不是OutOfMemoryError也不是JVM crash而是SIGTERM正常退出。Supervisor没有故障Supervisor只是被systemd要求停止。属于被动退出生产环境优化建议生产服务器关闭自动升级生产环境不建议每天自动升级系统组件尤其是Java应用服务器数据库服务器中间件服务器查看cat/etc/apt/apt.conf.d/20auto-upgrades如果APT::Periodic::Unattended-Upgrade 1;修改APT::Periodic::Unattended-Upgrade 0;设置统一维护窗口推荐开发环境 自动更新 测试环境 定期更新 生产环境 人工审批 维护窗口例如每周周六凌晨02:00-04:00进行系统补丁软件升级服务重启完善服务监控监控不要只关注服务器存活还应该关注Java进程状态Supervisor状态HTTP接口JVM指标服务启动时间例如发现服务启动时间突然变化即可提前发现重启事件。总结本次故障最终定位Ubuntu服务器开启了unattended-upgrades自动更新机制在凌晨自动升级libc6等系统核心组件触发systemd重新加载服务导致Supervisor托管的Java服务收到SIGTERM信号并重新启动。整个排查过程业务异常 ↓ Supervisor日志 ↓ exit status 143 ↓ 确认SIGTERM ↓ systemd日志 ↓ 发现服务停止来源 ↓ apt日志 ↓ 定位unattended-upgrades ↓ 确认glibc升级这个案例说明生产环境出现服务重启时不要只关注应用本身。Linux系统层面的systemd自动更新定时任务云初始化系统维护任务都有可能影响业务运行。作为运维人员需要建立从应用层 → 服务管理层 → 系统层 → 操作系统维护机制的完整排查思路。只有这样才能快速定位真正原因。