土拨鼠日志：清理临时目录，为什么把三个服务一起弄挂了

今天想讲一件特别典型的运维翻车：一条看起来再安全不过的清理命令，把三个服务连着一起弄挂了，而我们排查了大半天才彻底锁定同一个根。它不是那种高深的 bug，恰恰因为太「日常」，才更容易踩进去。

一、症状看着像三个独立的问题，其实是同一个根

先是后台面板报数据库管理工具访问 502，修好之后登录又报「找不到文件」，然后是切到某个 PHP 版本时间歇性的 502。三个现象，三种报错，乍一看是三件事。

但一路查下来，真凶是同一天同一条命令：为了腾空间，我们跑了「清理超过 7 天的临时文件」。这条命令把 /tmp 里的几个 unix socket 文件 也当成过期临时文件一并删了。

为什么删了文件、服务还「活着」却连不上？关键在于：进程还在，它监听的其实是那个已删除文件的旧 inode；文件目录项没了，新连接找不到入口，于是 nginx 连不上 → 502，应用连库时找不到 socket → 报「没有这个文件或目录」。进程没死，服务坏得却一点不含糊。

二、socket 不是「文件」，是服务正在用的插座

这个坑的本质，是把两类东西混为一谈：

• 真正可以按时间清理的，是临时数据文件；
• 而 *.sock 是服务在运行时创建的通信插座，删掉它等于把插头拔了，服务自己还以为插座还在。

正确的清理姿势，是在清理前先看一圈：列出 /tmp 下现有的 socket，再决定哪些能碰。清理临时文件的命令也要明确排除 socket 后缀，而不是无脑全删。

我们还踩到一个细节：socket 的修改时间可能是很久以前（服务启动时建的），所以它天然符合「超过 7 天」的筛选条件——这正是它会被误伤的深层原因。

三、把一次教训变成一条护栏

这类错最怕的不是「知道错了」，而是下次换个目录、换个服务再犯一次。所以我们给自己立了条硬规矩：

• 清理前先取证：列出目录里的 socket、看看有哪些监听，再决定删什么；
• 清理命令明文排除 socket，不写那种一把梭的全删；
• 清理后必回验：数据库管理工具、依赖这些 socket 的站点，都要点一遍确认没事。

把「不能碰的东西」写进命令本身，比写进脑子靠谱得多——脑子会忘，命令不会。

四、这套习惯在土拨鼠里怎么落地

这类「看起来安全的操作里藏着坑」的事，恰恰是 AI 助手能帮你兜住的地方：

• 执行前，把破坏性命令的范围和影响先摊开看，而不是直接冲上去跑；
• 记录里保留失败证据，下次遇到同类症状能直接对号入座，不用从头猜；
• 长任务有进度卡，卡在哪一步一目了然，不用反复追问。

如果你也在拿它跑运维和长流程，建议先看 功能页 里关于长任务与工作区的部分；想先算一笔账，定价页 有按量与实际消耗的对照；直接上手就 下载 装一个，拿一件真事跑一遍，比看十篇介绍有用。

五、一个 30 秒自查

下次你在任何机器上做「清理/整理」之前，问自己三句：

• 这个目录里有没有服务正在用的 socket 或运行时文件？
• 我的命令是不是精确排除了不能碰的东西，而不是一把全删？
• 清理完之后，依赖它的服务我有没有逐个点一遍确认？

三个问题过一遍，能挡住大部分「清理清理着把服务清挂了」的事故。清理不难，难的是在不该动手的地方管住手。