Supervisor exit status 143
文章目录
- 服务器没有重启，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区别
| 信号 | 编号 | 说明 |
|---|---|---|
| SIGTERM | 15 | 请求程序优雅退出 |
| SIGKILL | 9 | 强制立即结束 |
| SIGINT | 2 | Ctrl+C中断 |
生产环境中：
正常停止服务：
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.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
- 自动更新
- 定时任务
- 云初始化
- 系统维护任务
都有可能影响业务运行。
作为运维人员，需要建立：
从应用层 → 服务管理层 → 系统层 → 操作系统维护机制
的完整排查思路。
只有这样，才能快速定位真正原因。