VPS上的程序突然退出并显示Segmentation fault，通常表示进程访问了无效的内存地址，内核向它发送了SIGSEGV。这不是“内存不够”的同义词，也不能仅靠增加Swap解决。
最有价值的处理不是马上无限重启，而是保留崩溃时间、程序版本、启动参数、内核日志和coredump。有了同一现场的证据，才能区分代码缺陷、二进制与库不兼容、输入触发、内存破坏，还是更少见的硬件或宿主异常。
先确认真的是SIGSEGV
Shell可能直接打印Segmentation fault，systemd服务则可能显示进程以信号终止。先记录服务和进程状态：
systemctl status your-service --no-pager
journalctl -u your-service --since "30 minutes ago"
journalctl -k --since "30 minutes ago"关注退出信号、PID、可执行文件、崩溃时间和之前的异常。不要把killed、OOM、非法指令、总线错误和普通非零退出码都归为段错误；它们对应不同诊断路径。
在重启前保存这张现场卡
| 字段 | 为什么重要 |
|---|---|
| 准确时间与时区 | 对齐应用、systemd、内核和监控日志 |
| 程序版本与构建ID | 保证调试符号和崩溃二进制匹配 |
| 命令行、环境与工作目录 | 复现真实启动条件，注意脱敏 |
| 输入或请求标识 | 判断是否由特定数据路径触发 |
| 近期部署和库更新 | 识别版本、ABI或配置变化 |
| coredump与内核日志 | 还原线程和崩溃栈 |
账号令牌、数据库密码、完整请求体和个人数据不应直接放进公开工单。核心转储本身也可能包含敏感内存，复制和共享前必须控制权限。
用coredumpctl查看系统是否保存了核心转储
采用systemd-coredump的发行版常可使用：
coredumpctl list
coredumpctl info PID
coredumpctl debug PIDlist用于找到崩溃记录，info查看可执行文件、信号、时间和存储状态，debug可调用调试器。不同发行版和系统配置可能没有systemd-coredump，或者因存储、大小和安全策略不保存转储；不能看到记录就断言“程序没有崩溃”。
如果需要导出转储，应保存到权限受控的位置，并同时保留与之匹配的二进制和调试符号。升级软件后再拿旧core配新二进制，堆栈容易失真。
没有coredump时检查哪些限制
先查看当前Shell的核心转储限制和systemd服务配置。ulimit -c为0时，当前环境通常不会生成普通core文件；systemd服务还可能受LimitCORE和系统coredump策略影响。
不要在生产机上为了“多留证据”无限放开core大小。大型进程崩溃可能迅速占满磁盘，转储也可能包含密钥、用户内容和连接数据。应设置容量、保留周期、权限和清理策略，并在变更后用受控测试验证。
GDB先看崩溃栈，不急着猜哪一行
进入调试器后常用：
bt
thread apply all bt
info registers
frame 0bt显示当前线程调用栈；多线程程序应查看所有线程。若堆栈只有地址或显示??，通常需要与构建完全匹配的调试符号。编译器优化、内联、内存破坏和栈损坏也可能让回溯不完整，因此“第一帧出现某个库名”不等于该库一定是根因。
按触发模式区分三类问题
固定输入稳定复现
同一个请求、文件或命令稳定触发时，优先在隔离环境保留最小复现输入，检查边界条件、解析器、空指针、越界和并发状态。不要在生产环境重复提交可能破坏数据的写请求。
升级后立即出现
核对应用、动态库、插件、驱动和配置版本。使用ldd可辅助查看动态依赖，但不要从不可信目录替换系统库。回滚应同时考虑数据库迁移和数据格式，不能只替换一个二进制文件。
随机、跨程序出现
如果多个无关程序在不同位置随机崩溃，同时伴随MCE、EDAC、I/O或文件校验异常，应扩大到内存、磁盘、文件系统和宿主平台调查。单个应用的一次SIGSEGV不能证明VPS硬件有故障；需要跨程序、跨时间的证据和平台日志。
别把OOM当成Segmentation fault
内存压力可能让进程分配失败，也可能触发OOM Killer，但典型证据与SIGSEGV不同。检查：
journalctl -k | grep -i -E "oom|out of memory|killed process"
free -h
cat /proc/meminfo应用没有正确处理内存分配失败，后续确实可能发生段错误；但这仍需要调用栈和日志证明，不能看到内存使用高就直接定因。关于Swap与OOM的关系，可参考VPS是否需要Swap的判断方法。
生产环境怎么先止损
- 把崩溃实例从负载均衡摘除，保留至少一个未经反复重启的现场；
- 对相同输入设置隔离或熔断，避免重启循环持续触发；
- 若有已验证的上一版本，按变更记录回滚并观察；
- 数据库写操作使用幂等与对账，防止崩溃重试造成重复；
- 设置systemd重启间隔和上限，避免短时间反复拉起。
服务若已经进入重启风暴，可结合systemd start-limit-hit排查处理恢复节奏，但重启策略不能替代段错误根因修复。
哪些“修复”容易误导
- 只重启：可能恢复可用，但丢失复现窗口；
- 只加内存或Swap：无法修复越界、野指针和库不兼容；
- 随意升级全部依赖：同时改变太多变量，难以定位和回滚；
- 下载陌生调试脚本：可能暴露core、密钥和业务数据；
- 仅看崩溃函数名：内存破坏常在更早位置发生。
修复后怎样验收
- 在隔离环境用最小复现输入确认旧版本能够触发；
- 部署修复后重复相同路径，确认不再产生SIGSEGV；
- 运行单元、集成和压力边界测试，尤其覆盖并发与异常输入；
- 观察完整业务周期内的崩溃数、错误率、内存和重启次数；
- 确认coredump保留、权限、容量和告警策略有效；
- 记录根因、修复提交、版本和回滚点。
结论
Segmentation fault是进程无效内存访问的结果信号，不是一个可以用“重启”或“加Swap”统一解决的原因。先保存匹配的二进制、日志和coredump，再用调用栈、复现输入与版本变更缩小范围；只有跨程序的随机异常和硬件日志同时出现时，才把调查扩大到VPS宿主与硬件层。
