服务器没有重启，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区别

生产环境中：

正常停止服务：

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--since"2026-05-20 06:10:00"--until"2026-05-20 06:20:00"

发现：

May 20 06:15:58 systemd[1]: Stopping supervisor.service

关键点：

不是Supervisor自己退出。

而是：

systemd主动停止了Supervisor。

继续追查是谁触发systemd停止服务

继续查看系统日志：

journalctl\--since"2026-05-20 06:14:00"\--until"2026-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.service

Ubuntu自动更新任务。

定位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 Kernel

glibc属于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
• 自动更新
• 定时任务
• 云初始化
• 系统维护任务

都有可能影响业务运行。

作为运维人员，需要建立：

从应用层 → 服务管理层 → 系统层 → 操作系统维护机制

的完整排查思路。

只有这样，才能快速定位真正原因。