Pi 上的 VPN 客户端段错误？先固定进程信息

你启动客户端，终端打印 Segmentation fault (core dumped)，接下来的一小时全花在重新刷写上。那条消息只描述了一个进程在某个瞬间怎么死的。它没有说板子坏了，也没有排除电源、存储或镜像的问题。

从 shell 打印的那一行往回追到它背后的进程。有用的事实是：哪个可执行文件失败了，在什么环境下，在连接的哪个阶段。

从 shell 打印的那一行开始

命令里的名字往往是一个包装脚本或启动器，它启动的是另一个二进制文件，所以要确认内核真正终止的是哪个可执行文件。记下完整路径、软件包与应用版本、架构、系统与内核版本、启动它的账号以及确切时间。一个以 VPN 命名的 shell 命令很容易启动辅助进程，而记录里写的会是那个辅助进程。直接抄上个月安装的包版本号，说明不了当时跑的到底是什么。

记下崩溃前发生了什么：启动、解析配置文件、认证，还是已经在转发流量的会话。这四个阶段比 segfault 这个词更能缩小范围。保留那段时间附近的短日志窗口；至于哪个近期改动导致的，先别猜，等记录说话。

先确认有没有内存镜像

core 文件参考手册把转储描述为进程终止时写下的内存镜像，也列出了阻止写入的条件。这些条件包括资源上限为零，以及 core 模式把转储送到工作目录以外的地方。因此，没有名为 core 的文件并不能证明没有发生崩溃。在断定系统没有留下证据之前，先检查配置的模式和上限。

在使用 systemd 收集器的系统上，受支持的视图会把一条留存记录与某个可执行文件和时间关联起来。日志条目和可读的内存镜像却是两种不同的产物：保留策略和权限可能让你只有其中一种。向发行版或应用维护者询问他们支持的诊断流程，因为用不同构建或不同库集合产生的追踪通常只会浪费他们的时间。

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

这些读取要在真正崩溃的那台机器上重复。在新装的系统上做，只是在回答没人提出的问题。

把转储当作携带秘密的材料

进程内存里可能有凭据、会话密钥和配置文件内容，所以转储比旁边的文本日志更敏感。对日志做遮盖对不透明的内存镜像毫无作用；普通的工单系统保存附件的时间也远长于一次支持讨论。请通过厂商或维护者提供的私密渠道传输文件。把原始转储贴到公开工单里，等于暴露进程死亡时内存里的一切，而在有人检查之前，你根本不知道那是什么。

如果维护者要追踪，先问清楚要哪个可执行文件、哪些库。帧与所报告的构建对不上的回溯很难让人信服，也很容易被误读。

换任何东西之前先核对来源

通过安装的归属方核对软件包来源和文件完整性，并在任何受控修复之前保留配置和身份材料。不要为了看干净安装能不能启动，就覆盖掉唯一的证据副本。新镜像能启动只说明新镜像能启动，并不说明旧镜像里是不是有损坏的包、故障的卡，或者一个在这个架构上注定要出错的二进制。

如果无关程序也在失败，或者系统记录了存储、电源或内核错误，把这些观察留给平台层面的调查。它们扩大了范围，并不能证明每次 segfault 都来自坏内存或损坏的镜像。

定向修复之后，在同一硬件上重复同样的授权启动和同样的 VPN 操作。说明哪个故障在哪个版本下停止了。仅凭一次干净启动，既不能确认哪个部件有问题，也不能预测下一次硬件故障。