文章目錄服務器沒有重啟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自動更新定時任務云初始化系統維護任務都有可能影響業務運行。作為運維人員需要建立從應用層 → 服務管理層 → 系統層 → 操作系統維護機制的完整排查思路。只有這樣才能快速定位真正原因。