文件删了，服务还活着

一台名叫 legacy01 的老服务器，跑了七年多。团队只有一条铁律：绝不重启。某个周五下午四点四十五分，它失联了，订单和结账大面积故障。工程师们排查时发现一件怪事：库存网关服务还在运行，可它的程序文件早就被人删掉了——服务活着，程序的尸体却不在磁盘上。

这是一个运维故事频道（BugX，2026 年 11 月 8 日发布）讲的事。故事细节无从独立核实——这类频道做的是戏剧化改编，我看不到原视频。但它最反直觉的那一幕，「文件删了、服务还活着」，不是编剧的想象力，是 Unix 的日常。我自己花一分钟测了一遍。

删除一个文件，删的是什么

大多数人理解的「删除文件」，是把文件从磁盘上抹掉。实际上不是。在 Unix/Linux 里，删除（unlink）只做一件事：把文件名从目录里摘掉。文件真正的身体——inode，里面存着内容、权限、在磁盘上的位置——只要还有人在用，就不释放。

「还有人在用」包括正在运行它的进程。进程启动时，操作系统把二进制文件读进内存，并握着这个 inode 的引用不放。只要你不停掉进程，就算目录里的文件名没了、磁盘上再也找不到它，程序照跑不误。

我把这个场景复现了一遍：编译一个叫 legacy_gw 的小程序，让它跑起来，然后 rm 掉它。rm 之后磁盘上确实查无此文件，但进程活得好好的；打开 /proc/进程号/exe 看一眼，链接还在，只是名字后面多了一个标记——(deleted)。操作系统自己都承认：这个程序的身体已经从文件系统里消失了，但进程还抱着它。

这个机制反过来还挡路：正在运行的二进制不允许被覆盖写入，内核会报 Text file busy。我试着往一个正在跑的同名程序上拷贝文件，就被这句话顶了回来。想替换一个还在跑的服务，必须先停它——而这条铁律说，不许停。

把这两条机制放回故事里，「文件早被删除但服务还在运行」就说通了：删除发生的那一刻，进程抱着 inode 继续跑，从内存里看一切正常；只要没人重启，它就永远不需要磁盘上那个文件。一台七年没重启的服务器，恰好是这种状态最好的温床。监控报警也帮不上忙——服务心跳正常，进程健康，谁能想到磁盘上早就查无此人。

216 和 261

再看失联的真正原因。故事里，一台虚拟机迁移时，端口组的 VLAN ID 被配错了：本该是 216，敲成了 261。三个数字，两个对调，服务失联。

数字转置是人类录入错误里最经典的一种。手指比脑子快，216 和 261 在屏幕上都「长得差不多」，校对的人扫一眼很容易放过。这类错误的麻烦在于：它不出现在任何日志里。机器没坏，配置命令执行成功，网络设备一切正常——只是这台机器被划到了另一个广播域，像一座被搬错了岛的房子，门牌还在，路已经不通了。直到有人把 261 改回 216，一切瞬间恢复。修复动作小到荒谬，定位过程大到离谱。

铁律的来历和下场

最后值得想想那条铁律本身。一台服务器七年不敢重启，不是因为它重要，而是因为没人敢赌「重启之后它还能不能起来」。铁律不是工程决策，是恐惧写进了规章：所有依赖它的系统都长在它上面，没人知道重启会带走什么，于是干脆不去知道。

故事里团队的收尾其实做对了三件事：重建库存网关（不再依赖一个抱着已删除 inode 的幽灵进程）、做故障转移测试（证明挂掉一台还有备份）、然后安全关机。七年不敢做的事，做完测试后一个小时里做完了。

但故事的最后一行是个讽刺：他们给另一台老服务器 legacy02 也贴上了「请勿重启」的标签。铁律没有死，只是换了台宿主。下一台机器的故障剧本，已经写好了开头。

信源：BugX《We Had One Rule...NEVER Restart This Server》（YouTube，2026-11-08）。原视频在本环境不可访问，叙事细节依据素材梗概（含章节时间戳），性质为戏剧化运维故事；文中两个技术机制为独立实测：①unlink 后 inode 由存活进程持有，/proc/PID/exe 标记 (deleted)，进程持续运行（自编译小程序复现）；②正在执行的二进制不可覆盖写入，内核报 Text file busy（实测复现）。VLAN 转置错配为人因工程常见模式，机制属标准网络知识。