Linux PrivateTmp 开启后 /tmp 文件去哪了：服务命名空间与排查边界

凌晨跑的临时文件处理任务突然报“找不到文件”，但你登录 SSH 进服务器，在 /tmp 里明明就躺着目标文件。翻服务自己的运行日志，记录里又完全没提过这个文件，好像它根本就不存在。这种情况基本不是清理脚本乱删东西，而是 systemd 给服务单独划分出了一套 /tmp 视图。

开启 PrivateTmp=yes 后，服务内部看到的 /tmp 与宿主机终端看到的 /tmp 不再共享同一个目录视图；先确认 unit 配置的实际生效值和进程的挂载命名空间，再决定是保留隔离特性，还是把需要跨方共享的文件迁移到指定的专用服务目录下。

为什么终端能看到文件，服务读却说不存在

我们假设待排查的服务名称是 image-worker.service，它的预期逻辑是在 /tmp/image-worker.ready 下写入一个就绪标记文件。管理员在 SSH 会话里运行 ls -l /tmp/image-worker.ready 命令，能清清楚楚看到这个文件；但服务下一步去读取完全相同路径的文件时，却直接返回 No such file or directory。

这两次操作的路径字符串完全一样，但它们对应的文件系统视图却是分开的。systemd 的 PrivateTmp=yes 会给服务进程创建全新的文件系统命名空间，让服务拥有独立的 /tmp 和 /var/tmp。所以“宿主机上能看到文件”只能证明宿主机所属命名空间里有这个文件，完全不能说明服务所在的命名空间也能访问到它。

先确认 PrivateTmp 是不是真的对当前 unit 生效

不要只对照代码仓库里存的 unit 文件下定论。系统里可能存在 drop-in 配置覆盖、模板实例、发行版自带的默认调整，最终的生效值必须以 systemd 重新加载配置后的实际查询结果为准：

sudo systemctl daemon-reload
systemctl show image-worker.service -p PrivateTmp -p MainPID
systemctl cat image-worker.service

重点盯两项结果：PrivateTmp=yes 说明隔离已经正常开启，MainPID 用来锁定正在运行的服务主进程。如果 MainPID=0，说明服务进程可能已经退出，这时候不要拿之前记录的旧 PID 往下查，很容易走偏。

systemctl cat 这个操作适合核对主 unit 和 drop-in 配置合并后的最终结果；如果修改的是 drop-in 配置，重新载入配置后必须重启服务，已经在运行的旧进程不会自动切换到新的命名空间。

用 mountinfo 把两个 /tmp 视图对应上

拿到服务主 PID 之后，就可以直接查看进程对应的挂载信息。下面给出的命令只筛选临时目录相关的行，不用对着整页 mountinfo 内容一点点猜：

pid=$(systemctl show -p MainPID --value image-worker.service)
sudo awk '$5 == "/tmp" || $5 == "/var/tmp" {print}' "/proc/$pid/mountinfo"
findmnt -T /tmp
sudo nsenter -t "$pid" -m -- findmnt -T /tmp

宿主机的 findmnt -T /tmp 和进入服务 mount namespace 之后查到的结果，很可能显示完全不同的挂载来源。nsenter 这类操作只是用来做观测定位，没搞清楚影响范围之前，绝对不要进到这个命名空间里随便修改挂载。对正在运行的生产服务，记录 PID、命名空间 inode 和挂载来源这三个信息，就足够完成第一次问题定位了。

临时文件为什么服务一停就不见了

PrivateTmp=yes 的作用不是单纯“把目录藏起来不让你看”。systemd 会给每一个开启该选项的服务分配专属的私有临时目录，服务停止之后，里面所有的临时文件都会跟着服务的生命周期一起被清理掉。你重启一次服务，再去读上一次运行时留下的旧标记文件，得到空结果完全是预期行为。

这个特性刚好适合缓存缩略图、一次性解压目录、处理中间产物这类短生命周期的数据。但它完全不适合下面这几种场景：

• 放在服务外部的定时任务负责写文件，写完之后服务进程要马上读取；
• 两个互不关联的 unit 靠固定 /tmp 路径下的文件传递运行结果；
• 服务重启之后仍然需要保留的队列数据、导入批次文件或是审计相关材料。

如果确实需要几个关联服务共用同一个私有临时目录，systemd 支持通过 JoinsNamespaceOf= 配置让相关的 unit 加入同一个命名空间，但这么做会把所有关联服务的临时文件生命周期和隔离边界完全绑定到一起，必须提前把停止顺序、权限控制和异常清理逻辑一并设计好。

需要共享的文件应该迁到哪里

先按文件的生命周期选对应的存储目录，不要为了“两个地方都能看到”就直接把隔离功能关掉：

• 只在单次服务运行周期内使用的临时文件：继续放在服务自己的 /tmp 下，同时在应用层给这类文件设置明确的统一前缀。
• 服务重启之后还需要保留的文件：用 systemd 内置的 StateDirectory= 配置生成专属状态目录，在服务代码里直接引用对应的绝对路径。
• 多个 unit 共享、就算丢失也能重建的文件：单独创建专用共享目录，明确好属主、用户组权限和配套的定时清理任务。
• 需要外部定时任务投递数据的场景：让定时任务往专用队列目录里写，再由服务端按预设的文件权限和临时命名规则接收处理。

做迁移的时候别只改写入端的逻辑。可以先用一个小测试文件走完整的验收流程：外部创建文件、服务读取文件、服务生成结果、外部读取结果、服务重启后再重复读取，每一步都记录实际运行的 PID 和对应路径，避免把旧进程或者旧文件的状态误判成新配置的生效结果。

PrivateTmp 与安全加固的边界

PrivateTmp 能减少服务和宿主机通用临时目录之间的意外干扰，但它本身不是完整的权限沙箱。服务进程还是能访问其他所有有权限的可见路径，应用自身的目录权限控制、文件名校验、符号链接处理逻辑都得做好；如果服务本身是跑在容器里，内核是否允许创建挂载命名空间，也会直接影响这个配置项能不能正常生效。

因此安全加固可以按“确认生效—验证访问—观察回归”的步骤推进：

1. 核对 unit 的最终生效配置和服务的主 PID。
2. 在服务内部写入一份带时间戳的测试文件，分别从宿主机和服务所属命名空间下查询这个文件。
3. 排查服务有没有误把需要持久化的共享数据写入 /tmp，有问题的话及时迁移到专属状态目录。
4. 重启服务之后再重复一遍查询操作，确认清理行为完全符合业务的预期。

常见问题

PrivateTmp=yes 会把文件写到内存里吗？

不一定。常规 PrivateTmp=yes 生成的私有目录底层还是可以用主机的普通临时目录存储；它的核心作用是修改进程看到的挂载视图。只有使用完全断开的临时目录模式时，才会分配全新的 tmpfs 实例，具体行为要结合 unit 配置项和当前 systemd 版本核对。

为什么改完配置，服务还是看不到新文件？

最常见的原因是只重新载入了配置，没有重启正在运行的旧进程。重新查询 MainPID 的状态，确认它已经更新成预期值，再拿着新的 PID 去 /proc/PID/mountinfo 下做检查。

能不能直接关闭 PrivateTmp？

操作上完全可行，但关掉之前一定要先确认哪些业务逻辑在依赖共享临时文件、涉及的文件有没有敏感内容，以及有没有更合适的专用目录替代方案。如果需求只是跨 unit 传递结果，优先迁移文件存储目录或者让相关 unit 共享明确的命名空间，通常比全局关闭隔离要可控得多。

服务内外的 /tmp 文件名相同会互相覆盖吗？

开启私有临时目录之后一般不会出现这种情况，因为两边根本不在同一个目录视图下。为了避免误判，排查的时候要同时打印服务 PID、所属命名空间和文件创建时间，不能只靠文件名相同就下结论。

把临时目录当成生命周期设计的一部分

“文件找不到”背后其实藏着三个核心问题：谁有权限访问它、文件的存活周期有多长、谁负责清理它。PrivateTmp 解决了隔离和自动清理的问题，但也会让之前依赖宿主机 /tmp 路径的旧脚本冒出兼容问题。先确认 unit 配置的生效值，对比两个 mount namespace 的差异，再按文件的生命周期把共享文件迁到对应目录，通常比直接关掉隔离特性更容易后续维护。