問題一 ：運行時常見的進程崩潰原因 內存不足）
**0. 內存不足
內存不足（OOM Killer）
排查 OOM：free -h → dmesg → ps aux --sort=-%mem
預防 OOM：限制關鍵進程內存、調整 OOM Killer 策略、增加 swap
長期優化：監控內存使用、修復內存泄漏、合理分配資源
1. 段錯誤（Segmentation Fault, SIGSEGV）
原因：進程訪問了非法內存地址（如空指針解引用、數組越界、堆棧溢出）。
表現：進程崩潰，日志或終端輸出 Segmentation fault (core dumped)。
排查方法：
dmesg | grep segfault # 查看內核日志是否有段錯誤記錄
gdb /path/to/program /path/to/core # 用 GDB 分析 core dump
2. 資源限制（文件描述符、進程數、CPU 時間等）
原因：
- 文件描述符（FD）耗盡（
Too many open files） - 用戶進程數超限（
fork: retry: Resource temporarily unavailable） - CPU 或運行時間超限（
CPU time limit exceeded）
排查方法：
ulimit -a # 查看當前 shell 的資源限制
cat /proc/<PID>/limits # 查看某個進程的限制
cat /proc/sys/fs/file-nr # 查看系統文件描述符使用情況
3. 動態鏈接庫缺失或版本不匹配
原因：
- 程序依賴的
.so文件缺失（error while loading shared libraries） - 庫版本不兼容（
versionGLIBC_2.34’ not found`）
排查方法：
ldd /path/to/program # 檢查缺失的依賴庫
apt-file search libxxx.so # 查找缺失庫屬于哪個包（Debian/Ubuntu）
yum provides */libxxx.so # （RHEL/CentOS）
4. 配置錯誤（錯誤的配置文件、環境變量）
原因：
- 配置文件語法錯誤（如 JSON/XML/YAML 格式錯誤）
- 關鍵環境變量未設置（如
DATABASE_URL為空）
排查方法：
strace -f -e trace=file /path/to/program # 跟蹤程序讀取的配置文件
env | grep KEY # 檢查環境變量
journalctl -xe # 查看 systemd 服務的錯誤日志
5. 信號終止（SIGKILL、SIGTERM、SIGABRT）
原因：
- 被管理員
kill -9（SIGKILL） - 程序自身調用
abort()（SIGABRT） - 超時被監控工具殺死（如
systemd的TimeoutStopSec）
排查方法：
dmesg | grep -i "killed" # 檢查是否被 OOM Killer 或管理員殺死
journalctl -u service_name # 查看 systemd 服務的終止原因
問題2：Core Dump 的作用，以及 supervisor 和 systemctl 的區別
1. Core Dump 的作用
Core Dump 是進程崩潰時的內存快照，包含崩潰時的堆棧、變量值等信息，用于調試。
如何設置和查看？
# 檢查當前是否允許生成 core dump
ulimit -c # 如果是 0，則禁止生成# 臨時允許 core dump（當前會話有效）
ulimit -c unlimited# 永久生效（修改 /etc/security/limits.conf）
echo "* soft core unlimited" >> /etc/security/limits.conf# 指定 core dump 保存路徑
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern# 查看已生成的 core dump（systemd 系統）
coredumpctl list
coredumpctl info <PID>
2. supervisor vs systemctl
| 對比項 | systemctl (systemd) | supervisor |
|---|---|---|
| 用途 | 系統級服務管理（默認集成在 Linux） | 進程監控（適合 Python、Node.js 等應用） |
| 自動重啟 | 支持（Restart=on-failure） | 支持（autorestart=true） |
| 日志管理 | 通過 journalctl 查看 | 自定義日志文件 |
| 依賴管理 | 支持（After=network.target） | 不支持 |
| 適用場景 | 系統服務（如 nginx、MySQL） | 用戶級進程（如 Python 腳本、后臺任務） |
示例：supervisor 配置（/etc/supervisor/conf.d/myapp.conf）
[program:myapp]
command=/usr/bin/python3 /opt/myapp/main.py
autorestart=true
stderr_logfile=/var/log/myapp.err.log
stdout_logfile=/var/log/myapp.out.log
總結：
- Core Dump 用于調試崩潰原因，需手動開啟。
- systemctl 適合管理系統服務，supervisor 更適合監控用戶級進程（如開發環境）。
如果你的進程頻繁崩潰，建議：
- 開啟 core dump 分析崩潰原因
- 用
supervisor或systemd自動重啟 - 檢查日志（
journalctl、dmesg）定位問題
如何獲取掛掉的 PID？
方法 適用場景 命令示例
dmesg OOM Killer 殺死進程 dmesg | grep -i “killed”
journalctl systemd 托管服務崩潰 journalctl -xe | grep “exit”
coredumpctl 進程崩潰生成 core dump coredumpctl list
ps/pgrep 查找僵尸進程或最近運行的進程 ps aux | grep -w Z
auditd 審計進程退出事件 ausearch -k process_exit
supervisor 托管進程崩潰記錄 supervisorctl status
如果 PID 經常丟失，建議：
啟用 core dump（ulimit -c unlimited）
使用進程管理工具（如 systemd / supervisor）
部署監控告警（如 Prometheus + Alertmanager）
