一次掉线以后, 我开始认真留退路

那次掉线, 最后留下的是日志中间的一段空白.

上一轮记录在早上八点三十二分停住, 下一次启动已经是九点零六分. 按主机当地时间算, 中间隔了大约三十四分钟.

这个数字是后来翻日志才知道的. 它能说明那段时间没有留下记录, 不能精确告诉我服务从哪一秒开始不可用. 至于机器旁边发生了什么, 日志里没有答案.

我当时想弄清的事情很简单: Mini 为什么又掉线了? 是断电, 还是系统自己重启?

在上一篇里, 我写过这台机器承担的工作. 知识库的副本、远程开发环境、住宅网络出口, 一件件放上去时, 总觉得只是多加一点. 真到它失去回应, 才发现自己已经习惯了那么多东西在那里等着.

先别急着替它找一个原因

我们重新连上 Mini 后, 没有马上改配置, 也没有再重启一遍.

先看它什么时候启动, 再往前翻, 找上一次运行结束的位置. 正常关机通常会留下收尾的痕迹, 那一次却没有. 日志末尾还在记录网络活动, 接着便断了, 像一页写到半行就被收走的纸.

新的启动记录里, 系统提示日志文件可能损坏或经历了非正常关闭. 再去找内核崩溃、内存耗尽、过热等线索, 当时也没有找到相应的记录, 没有可用的崩溃转储.

这些证据放在一起, 很像供电被突然截断, 或者一次硬关机、强制复位. 至少, 它没有正常重启应有的过程.

但到这里, 还不能顺手写下一句: 原来是停电了.

电网断电、有人拔了电源、长按电源键, 留给操作系统的痕迹可能很接近. 日志能带我们走到机器停止记录的地方, 却不能越过去, 看见插座旁边的事. 没查到崩溃记录, 也不等于已经证明所有硬件都没问题.

最后留下的结论, 因而并不圆满: 一次非正常关机, 更符合供电中断或硬复位一类情况, 具体外因未能确认.

我现在反而愿意保留这样的句子. 以后真有新的线索, 还能接着查. 若当时为了心里痛快, 把一个可能写成了确定, 下一次排查便会从一个未经证实的前提出发.

能连上了, 事情还没查完

重新得到终端回应, 总会让人松一口气.

那次检查时, systemd 没有列出失败的服务单元. 这是个好消息, 但它只回答了一个有限的问题. 页面是否打开、请求有没有经过预期的出口、知识库能不能从手机上查到, 仍然是各自的事.

机器回来以后, 并不会替每一种使用方式逐个报平安.

我后来越来越留意这种区别. SSH 能连接, 说明可以进入主机; 一个服务显示运行中, 说明进程处在相应状态. 真正要用它完成的事情, 还得沿着那条路走一次. 否则关掉终端时觉得都好了, 到下一次需要用, 才发现还有一处没接上.

这次记录里确认过的检查, 就停在它实际覆盖的地方. 我没有再替它补上一段所有服务都恢复正常的结尾.

写下未确认, 有时比写下完成更有用. 下一次接手, 至少知道还欠哪一眼.

退路, 得在动手之前留下

这次掉线并没有让我一夜之间重新设计所有东西. 有些习惯原本就在做, 有些也仍然做得不够周全. 只是回头整理这些经历时, 我开始更认真地看待那些平时不怎么起眼的准备.

比如改配置之前, 把旧文件留一份.

这件事简单得几乎不值得提. 可真正改坏的时候, 记得原来大概是什么样, 和手里确实有一份旧文件, 差别很大. 尤其几处改动连在一起, 人很容易把上一个失败方案的参数, 记成最初能用的那一版.

再比如, 停掉一项不用的服务时, 顺手记下它为什么停, 要恢复时从哪里开始. 过几个月看到一个 disabled, 就不用猜是故障残留, 还是自己曾经认真作出的决定.

我也希望这些准备尽量简单. 一份位置明确的旧配置, 一条能读懂的记录, 一个确实知道怎么执行的恢复步骤. 如果退路比原来的部署还难懂, 真要着急的时候, 它多半也帮不上忙.

留下来之前最好再想一遍: 明天换一个没参与今天过程的人, 能不能照着接手?

那个没参与的人, 很可能就是忘了细节的我自己.

这个博客, 也给旧版本留了位置

现在发布博客, 用的就是一种很朴素的安排.

新文章先在本地构建, 检查生成结果. 上传到服务器后, 放进一个新的版本目录, 核对传输包的校验值, 检查 Nginx 配置, 再把正在使用的入口切过去. 上一版仍然留在原处.

发布脚本随后会在服务器上检查 HTTPS 首页. 这一步失败, 就把入口切回之前的版本. 至于外面的人能不能访问、新文章是否出现在首页和 RSS、正文是不是刚才写的那份, 还要另行核对.

这里没有什么惊人的技术. 让我安心的只是, 发布不需要先把正在用的那一版擦掉.

当然, 这种退路也有自己的范围. 一次首页检查不会发现所有问题, 正文写错了也可能照样返回成功. 保留旧目录不等于在另一台机器上做好备份, 更不能抵御整块磁盘损坏. 它解决的是这一轮发布切换的问题, 不能替所有意外兜底.

把它的用处看清, 就已经足够值得保留.

备用的名字, 不能替我挡住故障

网络上的退路, 更容易让人产生错觉.

我曾经在代理配置里准备过不止一条候选路径. 独立隧道是一条, 另一种组网连接又是一条. 看着列表, 会觉得已经给自己留足了选择.

可如果两条路最终都经过同一台 Mini, 使用同一处住宅网络, 主机一断电, 它们就可能一起断. 连接方式不同, 并没有让它们摆脱共同依赖.

这也是为什么后来谈故障切换, 我更愿意先问: 这条备用路径究竟能替我避开哪一种故障?

一条隧道握手失效, 和整台主机停机, 需要的后路并不相同. 备用项有没有进入实际使用的选择逻辑, 检查的是哪一条线路, 切换以后有没有真正发出请求, 都得弄清楚. 多一个看着可靠的名字, 不会自动完成这些事情.

这些细节在代理网络那篇里写过. 到这次 Mini 的经历里, 它们又有了一点更具体的分量: 我需要知道故障会停在哪里, 以及它会不会顺着共同的依赖, 把别的路径一起带走.

还有一条退路, 是留给记性不好的自己

机器出了问题, 尚且可以翻日志. 自己忘了为什么这样配置, 往往连该翻哪份日志都不知道.

所以那次排查结束, 值得留下的并不只是一个原因判断. 从哪里进去, 查过什么, 哪些证据支持结论, 哪些事情仍然不知道, 都应当有几行记录.

这也是个人 Wiki 对我最实际的一种帮助. 下次再遇见掉线, 不必从一张白纸开始, 也不必把上一次的猜测重新猜一遍. 先读记录, 再检查这一次的现场, 看条件有没有变.

记录仍然需要更新. 某次正常, 不代表今天正常; 文件从 Mac 推送出去, 不代表 Mini 已经收到. 我们就遇到过前一端完成、后一端没连上的情况. 那时如实留下同步未确认, 比让一个笼统的成功把两端盖在一起好得多.

所谓留退路, 到这里也包括一种很平常的体谅: 不要求未来的自己记住今天的一切.

只要留下一点足够重新开始的东西.

下次仍然可能掉线

我没有因此觉得自己已经准备周全.

Mini 还可能失去连接, 某次更新也仍然可能带来问题. 那段日志里的三十四分钟, 至今没有一个能够指认到现场的答案. 我不打算为了文章收得漂亮, 替它补出来.

但以后动手之前, 我会多想一点: 旧版本还在不在? 改动失败时怎么退? 这条备用路径和主路径, 是不是其实拴在同一个地方?

这些问题不会让每次操作都顺利. 它们只是让出错之后, 手边还有几样可以用的东西.

一份旧配置, 一个保留下来的版本目录, 几行没有夸大结论的笔记.

下一次终端迟迟没有回应时, 我希望自己能先坐稳, 知道该从哪里看起.

本文依据 2026-09-07 Mini 掉线的只读排查记录, 以及截至 2026-09-19 的个人维护实践整理. 未为写作重演故障或重新巡检主机, 私有连接信息已省略.