Linux tmpfiles.d 怎样为运行时目录设置保留策略

Linux 服务经常需要一个短生命周期目录：套接字放在 /run，临时状态放在某个运行时路径，旧缓存则希望按年龄清掉。把这些动作散落在启动脚本里，容易出现目录不存在、权限被改坏、重启后残留或清理范围过大的问题。tmpfiles.d 的作用，就是把“路径应该是什么状态”写成规则，再交给 systemd-tmpfiles 统一创建、修复和清理。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html

最小思路是：用 d 声明目录，用字段写明 mode、属主和清理年龄；先用 systemd-tmpfiles --create --boot 或 --clean 预览规则，再把确认过的动作交给系统服务。tmpfiles.d 不是备份工具，也不应该用宽泛路径替代明确的应用目录。

先把“创建”和“清理”拆成两件事

我在处理运行时目录时，先问两个问题：这个路径在启动后必须存在吗？里面的旧内容是否有明确的生命周期？前一个问题对应创建或权限状态，后一个问题才对应清理年龄。两者可以写在同一条规则里，但判断依据不同。

用 d 规则声明 /run 下的目录

目录规则的核心是类型、路径、权限、属主、属组和年龄字段。下面以一个应用缓存目录为例，路径故意保持具体，避免使用 /run/* 之类难以审查的通配范围：

# /etc/tmpfiles.d/app-cache.conf
# d 表示：目标是目录；0750、app、app 是目录的期望状态
d /run/app-cache 0750 app app 7d

这行的含义不是“每次都删除并重建目录”，而是声明一个目录状态：目录不存在时可以创建，状态需要维护时由 tmpfiles 处理，7d 则为该路径下可参与清理的内容提供年龄条件。运行用户、组名和权限要与应用实际访问模型一致，不能因为目录位于 /run 就默认所有服务都能写入。

规则文件通常放在 /etc/tmpfiles.d/，用于管理员或本机配置；发行版提供的规则常见于 /usr/lib/tmpfiles.d/，本机运行时生成或临时覆盖的规则可能位于 /run/tmpfiles.d/。同名文件存在时，优先级和覆盖关系要按官方规则确认，避免直接修改包管理器维护的文件。

v、d 和 Z：不要把类型字母当成装饰

不同类型代表不同的维护语义。日常配置中最容易混淆的是目录、易失文件和权限恢复：d 面向目录，v 面向易失文件或目录并带有清理语义，Z 主要用于恢复文件上下文而不是替代目录创建。

如果目标只是创建一个目录，优先用最小的 d 规则；如果目标是让应用的缓存文件按年龄清理，才考虑带清理字段的类型或规则组合。把 Z 当成“创建目录”的替代写法，会让排查方向偏离真正的问题。

先预览，再分别执行 create 和 clean

systemd-tmpfiles 提供了按动作处理规则的入口。我的习惯是先以 dry-run 方式观察目标，再决定是否在测试主机上执行：

# 只查看规则会匹配哪些创建动作，不立即修改文件系统
sudo systemd-tmpfiles --create --boot --prefix=/run/app-cache --dry-run

# 确认输出只涉及应用目录后，再执行创建和状态维护
sudo systemd-tmpfiles --create --boot --prefix=/run/app-cache

# 单独执行清理；--prefix 把范围限制在明确的应用路径
sudo systemd-tmpfiles --clean --prefix=/run/app-cache

不同 systemd 版本对可选参数和输出细节可能有所差异，部署前应以本机的 systemd-tmpfiles --help 和对应 man page 为准。这里最重要的边界是把 --create 与 --clean 分开理解：前者让声明的目录状态落地，后者按规则年龄处理已有内容。

如果不使用 --prefix，就要更加谨慎地审阅规则来源。系统级 clean 可能包含许多发行版自带路径；对单个应用调试时，把范围缩窄到明确目录更容易判断风险。

怎样判断清理年龄是否真的适合

年龄字段不是“文件创建时间超过七天就一定删除”的简单承诺。tmpfiles 的清理判断与规则类型、目录递归方式、文件时间戳和本机实现有关，因此应该把它理解为“符合该规则的旧内容进入清理候选”。持久化数据、上传文件和用户生成内容，不应只依赖 tmpfiles 的 age 作为保护措施。

# 先列出目标目录的内容与时间，再决定 age 是否合适
target=/run/app-cache

# -a 保留隐藏项，--time-style 让人工记录更容易比较
find "$target" -mindepth 1 -maxdepth 2 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# 规则只用于短生命周期内容；持久数据应交给应用或备份系统管理
sudo systemd-tmpfiles --clean --prefix="$target"

如果应用会重新打开旧文件并更新访问时间，清理结果还会受这些时间变化影响。反过来，应用若把重要数据放在运行时目录，clean 可能在你没有设计恢复路径时删除它。更稳妥的分层是：/run 放可重建状态，缓存可被重新生成，真正需要留存的数据放到持久化目录并由专门的备份和保留策略管理。

规则不生效时，按来源和范围排查

遇到“目录没有创建”或“旧文件没有清掉”，先确认系统真正读取了哪一个规则文件。不要一开始就重复执行同一个命令；先分清文件路径、类型、权限、属主和 age 是否写在了预期字段。

# 展示系统已安装的 tmpfiles 规则，先确认同名覆盖和目录来源
systemd-tmpfiles --cat-config

# 只用指定规则文件做一次局部预览，避免把全局规则混进判断
sudo systemd-tmpfiles --create --dry-run /etc/tmpfiles.d/app-cache.conf

# 查看目标的实际权限、属主和内容，核对规则写入的期望状态
stat -c '%A %U:%G %n' /run/app-cache
find /run/app-cache -mindepth 1 -maxdepth 1 -print

排查顺序可以固定为：规则文件是否被读取、路径是否被更具体的规则覆盖、目录的 mode 和属主是否匹配、clean 的年龄是否有可比较的内容、最后才看服务启动时机。若目录由服务自己的 RuntimeDirectory= 创建，应该先明确它与 tmpfiles 规则的职责边界，不要让两个机制同时管理同一组权限。

我的落地清单

• 只为一个应用写一个明确路径，优先从 d 规则开始。
• 把 mode、user、group 写清楚，并用测试用户验证最小访问权限。
• 把短生命周期内容和持久数据分开放置，不把 clean 当备份。
• 先用 --dry-run 和 --prefix 观察，再分别执行 --create、--clean。
• 系统规则优先查看来源和覆盖关系，不直接改动包管理器维护的文件。

常见问题

tmpfiles.d 会在每次启动时删除整个目录吗？

不会因为目录规则本身就删除整个目录。创建和清理是不同动作，清理还要结合规则类型、年龄和匹配范围。没有明确设计清理语义时，不要把 --clean 当成“重置目录”。

为什么目录已经存在，权限还是没有按规则变化？

可能是规则类型不承担你期待的权限恢复，或者有同名、更高优先级规则覆盖了当前文件。先用 --cat-config 查看最终配置，再对照实际 mode、属主和服务自己的目录管理机制。

可以用 tmpfiles.d 清理应用的数据库目录吗？

除非应用明确把其中内容定义为可丢弃缓存，否则不建议。数据库、上传文件和业务记录需要自己的保留、备份与恢复策略；tmpfiles 更适合运行时目录和可重建的临时内容。