文章目錄服務(wù)器沒有重啟Java服務(wù)為什么自動重啟一次Ubuntu自動更新導(dǎo)致Supervisor服務(wù)重啟的排查實錄故障背景故障現(xiàn)象exit status 143是什么意思SIGTERM和SIGKILL區(qū)別排查Supervisor是否異常繼續(xù)追查是誰觸發(fā)systemd停止服務(wù)定位Ubuntu自動更新任務(wù)完整故障鏈路分析為什么升級glibc會影響業(yè)務(wù)服務(wù)這次問題為什么不容易發(fā)現(xiàn)服務(wù)器沒有重啟Java沒有崩潰Supervisor沒有故障生產(chǎn)環(huán)境優(yōu)化建議生產(chǎn)服務(wù)器關(guān)閉自動升級設(shè)置統(tǒng)一維護窗口完善服務(wù)監(jiān)控總結(jié)服務(wù)器沒有重啟Java服務(wù)為什么自動重啟一次Ubuntu自動更新導(dǎo)致Supervisor服務(wù)重啟的排查實錄故障背景在生產(chǎn)環(huán)境運維過程中經(jīng)常會遇到這樣的問題服務(wù)器看起來一切正常沒有發(fā)生重啟但是業(yè)務(wù)服務(wù)突然出現(xiàn)短暫中斷然后自動恢復(fù)。這類問題往往比較隱蔽。如果只看應(yīng)用日志很容易誤判為Java應(yīng)用異常退出JVM崩潰Supervisor異常服務(wù)器故障但實際生產(chǎn)環(huán)境中還有一種情況容易被忽略Linux系統(tǒng)自動維護任務(wù)可能會間接影響業(yè)務(wù)服務(wù)。本文記錄一次真實生產(chǎn)環(huán)境問題排查過程Ubuntu服務(wù)器上的Java服務(wù)凌晨自動重啟通過Supervisor、systemd、apt日志逐層分析最終定位到unattended-upgrades自動升級glibc組件導(dǎo)致systemd重新加載服務(wù)。故障現(xiàn)象業(yè)務(wù)反饋2026年5月20日 06:15左右業(yè)務(wù)接口出現(xiàn)短暫異常。查看服務(wù)器上的Supervisor日志tail-100/var/log/supervisor/supervisord.log發(fā)現(xiàn)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停止隨后服務(wù)重新啟動初步判斷業(yè)務(wù)進程不是崩潰而是被主動停止。圖片說明Supervisor收到SIGTERM信號Java服務(wù)退出狀態(tài)為143。exit status 143是什么意思很多運維人員看到exit status 143第一反應(yīng)服務(wù)異常退出實際上并不是。Linux進程退出碼規(guī)則退出碼 128 信號編號其中SIGTERM信號編號15所以128 15 143因此exit status 143表示進程收到SIGTERM信號并進行了正常退出。也就是說這不是kill-9PID強制殺死。而是kill-15PID優(yōu)雅終止。SIGTERM和SIGKILL區(qū)別信號編號說明SIGTERM15請求程序優(yōu)雅退出SIGKILL9強制立即結(jié)束SIGINT2CtrlC中斷生產(chǎn)環(huán)境中正常停止服務(wù)systemctl stop xxx通常發(fā)送SIGTERM給應(yīng)用一個機會保存數(shù)據(jù)關(guān)閉連接提交事務(wù)排查Supervisor是否異常查看Supervisor狀態(tài)systemctl status supervisor結(jié)果Active: active (running) Main PID: 917203 (supervisord) Active since: Tue 2026-05-20 06:16:04 UTC發(fā)現(xiàn)Supervisor剛剛啟動。說明Supervisor不是一直運行。它在06:16:04重新啟動。繼續(xù)查看systemd日志journalctl-usupervisor--since2026-05-20 06:10:00--until2026-05-20 06:20:00發(fā)現(xiàn)May 20 06:15:58 systemd[1]: Stopping supervisor.service關(guān)鍵點不是Supervisor自己退出。而是systemd主動停止了Supervisor。繼續(xù)追查是誰觸發(fā)systemd停止服務(wù)繼續(xù)查看系統(tǒng)日志journalctl\--since2026-05-20 06:14:00\--until2026-05-20 06:17:00發(fā)現(xiàn)關(guān)鍵日志May 20 06:15:49 cbf systemd[1]: Reexecuting requested from client PID 916314 (systemctl)同時發(fā)現(xiàn)May 20 06:15:32 cbf systemd[1]: Starting apt-daily-upgrade.service這里出現(xiàn)了重要線索apt-daily-upgrade.serviceUbuntu自動更新任務(wù)。定位Ubuntu自動更新任務(wù)Ubuntu默認開啟unattended-upgrades用于自動安裝安全補丁系統(tǒng)組件更新查看日志cat/var/log/unattended-upgrades/unattended-upgrades.log發(fā)現(xiàn)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最終確認此次自動升級內(nèi)容libc6 libc-bin locales其中l(wèi)ibc6就是Linux系統(tǒng)核心運行庫glibc。完整故障鏈路分析最終整個過程如下Ubuntu unattended-upgrades | | 自動升級glibc(libc6) | | systemctl觸發(fā)systemd reexec | | systemd重新加載服務(wù) | | supervisor.service停止 | | 執(zhí)行ExecStop: supervisorctl shutdown | | Supervisor發(fā)送SIGTERM | | Java服務(wù)退出 (exit status 143) | | supervisor重新啟動 | | Java服務(wù)重新運行為什么升級glibc會影響業(yè)務(wù)服務(wù)很多人可能會疑惑更新一個系統(tǒng)庫為什么會影響Java服務(wù)原因Linux應(yīng)用運行時依賴系統(tǒng)基礎(chǔ)庫。例如Java | JVM | 系統(tǒng)調(diào)用 | glibc | Linux Kernelglibc屬于Linux最核心的基礎(chǔ)組件之一。升級glibc后新啟動進程使用新版本老進程仍然使用舊內(nèi)存映射systemd可能執(zhí)行重新加載為了保證系統(tǒng)狀態(tài)一致部分服務(wù)可能被重新啟動。這次問題為什么不容易發(fā)現(xiàn)因為幾個現(xiàn)象很容易誤判。服務(wù)器沒有重啟執(zhí)行uptime-s發(fā)現(xiàn)服務(wù)器啟動時間正常。所以排除服務(wù)器宕機云主機重啟Java沒有崩潰不是OutOfMemoryError也不是JVM crash而是SIGTERM正常退出。Supervisor沒有故障Supervisor只是被systemd要求停止。屬于被動退出生產(chǎn)環(huán)境優(yōu)化建議生產(chǎn)服務(wù)器關(guān)閉自動升級生產(chǎn)環(huán)境不建議每天自動升級系統(tǒng)組件尤其是Java應(yīng)用服務(wù)器數(shù)據(jù)庫服務(wù)器中間件服務(wù)器查看cat/etc/apt/apt.conf.d/20auto-upgrades如果APT::Periodic::Unattended-Upgrade 1;修改APT::Periodic::Unattended-Upgrade 0;設(shè)置統(tǒng)一維護窗口推薦開發(fā)環(huán)境 自動更新 測試環(huán)境 定期更新 生產(chǎn)環(huán)境 人工審批 維護窗口例如每周周六凌晨02:00-04:00進行系統(tǒng)補丁軟件升級服務(wù)重啟完善服務(wù)監(jiān)控監(jiān)控不要只關(guān)注服務(wù)器存活還應(yīng)該關(guān)注Java進程狀態(tài)Supervisor狀態(tài)HTTP接口JVM指標服務(wù)啟動時間例如發(fā)現(xiàn)服務(wù)啟動時間突然變化即可提前發(fā)現(xiàn)重啟事件?？偨Y(jié)本次故障最終定位Ubuntu服務(wù)器開啟了unattended-upgrades自動更新機制在凌晨自動升級libc6等系統(tǒng)核心組件觸發(fā)systemd重新加載服務(wù)導(dǎo)致Supervisor托管的Java服務(wù)收到SIGTERM信號并重新啟動。整個排查過程業(yè)務(wù)異常 ↓ Supervisor日志 ↓ exit status 143 ↓ 確認SIGTERM ↓ systemd日志 ↓ 發(fā)現(xiàn)服務(wù)停止來源 ↓ apt日志 ↓ 定位unattended-upgrades ↓ 確認glibc升級這個案例說明生產(chǎn)環(huán)境出現(xiàn)服務(wù)重啟時不要只關(guān)注應(yīng)用本身。Linux系統(tǒng)層面的systemd自動更新定時任務(wù)云初始化系統(tǒng)維護任務(wù)都有可能影響業(yè)務(wù)運行。作為運維人員需要建立從應(yīng)用層 → 服務(wù)管理層 → 系統(tǒng)層 → 操作系統(tǒng)維護機制的完整排查思路。只有這樣才能快速定位真正原因。