问题一 ：运行时常见的进程崩溃原因 内存不足）
**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）
