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