你盯着服务器上越堆越满的/tmp，手动执行rm -rf /tmp/*也不是没干过，但治标不治本。这不是个例。做 Linux 运维久了，几乎每个人都遇到过/tmp被某个失控进程写满，或者某些临时文件残留几个月没人管，把磁盘空间吃得干干净净。现代 Linux 系统管理早就把这块收编成了标准化的机制，核心就是systemd-tmpfiles。这篇文章我就把 tmp 目录的标准管理方式完整梳理一遍，从原理到配置、从实操到踩坑，一次性讲透。
无论你是刚接触 Linux 的运维新人，还是想把服务器管得更稳的老手，都应该认真了解这套机制。它解决的不只是"临时文件清理"这一个问题，还包括临时目录的权限初始化、运行时目录的创建、以及系统启动时对特定路径的预置。搞清楚 systemd-tmpfiles，你调服务器会顺手很多。
1. tmp 目录的本质与历史问题
1.1 tmp 目录到底在存什么
Linux 下的/tmp和/var/tmp是表面相似、实则不同的两个目录。按照文件系统层级标准（FHS），/tmp里的文件是"允许被清理的临时数据"，一般系统重启后内容会被清空；而/var/tmp里的文件则假设可以“跨重启”存活，用于存储一些需要在重启之间保留的临时数据，比如编辑器备份、安装程序中间产物等。
但在实际使用中，很多人根本不去纠结这个区别。各种程序只要想写临时文件，抬手就丢到/tmp下面。而且/tmp的权限通常是 1777（即 sticky bit 置位），意味着任何用户都能在里面创建文件，但只有文件属主、目录属主或者 root 才能删除别人的文件。这种设计方便了共享，也带来了垃圾堆积和空间被恶意占满的风险。
/tmp里常见的东西包括：X 11 的 socket 文件、systemd 的运行时 socket、浏览器下载临时块、解压工具的中间缓存、各种服务的 pid 文件、以及大量用户自己生成的临时脚本。它们中很多在程序正常退出后会自行清理，但也总有程序崩溃、异常退出、或者干脆是没写清理逻辑，导致文件一直残留。
1.2 历史上怎么清理 tmp：tmpwatch、cron 与手动删除
早年间，多数发行版靠一个叫tmpwatch的工具定时清理/tmp。它由 cron 驱动，默认每天执行一次，按照文件最后的访问时间（atime）或者修改时间（mtime）把超过一定期限的文件删掉，默认阈值一般是 10 天或 30 天。CentOS 6 时代，/etc/cron.daily/tmpwatch就是干这个的。
这套方案看起来简单，实际问题不少。首先，tmpwatch默认按atime判断，而很多系统为了省 IO 开启了relatime挂载选项，文件的访问时间更新并不及时，就会导致一些明明正在被占用的文件也被扫进删除名单；反过来，如果一个死文件刚好还在被人打开，删掉它并不会释放空间（inode 还挂在进程上），但路径已经消失了，这就会引发踩坑。
其次，cron 任务默认每天跑一次，清理频率很低。如果某个写入程序很猛，一天之内就能把/tmp撑爆。我见过不少业务环境里/tmp被一些解压操作写满，cron 还没到点，机器先挂了。
还有更原始的做法：干脆写一个 shell 脚本用find配合-mtime参数来找旧文件然后删除。这么说吧，脚本本身不复杂，难的是把它做得像样。你得处理软链接、排排除在用的文件、处理文件属主权限、避免误删运行中的 socket…… 这些边界情况用 shell 脚本写起来又长又折腾，而且每个运维的写法都不一样，换个人来维护就是噩梦。
1.3 手动删除 tmp 有多危险
这里我必须重点提一下手动删除的问题。很多人在磁盘报警时直接敲rm -rf /tmp/*，而且是在没有任何防护的情况下这么干。第一个风险是并发问题：在你执行rm的同时，可能有程序正在向/tmp写入临时文件，删除操作和写入操作交错，轻则程序报错，重则把 socket 文件删掉导致服务通信中断。第二个风险是权限误判：如果你用了错误的路径变量，比如脚本里tmpdir没赋值成功，直接执行了rm -rf "$tmpdir/*"，结果就是把/下的东西删了一部分，这种事故在运维圈不是没发生过。第三个风险是你删掉了正在使用的文件，文件句柄不会立即消失，但新的访问者找不到路径，业务就直接异常。
所以现代 Linux 系统早就把临时目录的管理收编到标准机制里了。这就是 systemd 生态里的systemd-tmpfiles。它不是简单的一个清理工具，而是一整套“定义-创建-清理-恢复”的文件生命周期管理体系。
2. systemd-tmpfiles 的设计与工作机制
2.1 它到底是什么
systemd-tmpfiles是 systemd 自带的一个工具，用于管理/tmp、/var/tmp、/run等易变目录的创建、权限设置和定期清理。通过编写特定的配置文件，你可以声明“这个目录在开机时应当存在，权限是什么，文件超过多少天就删掉”。systemd 会在系统启动时自动执行一次（通过systemd-tmpfiles-setup.service），之后由systemd-tmpfiles-clean.timer按指定周期执行清理逻辑。
这套机制把管理员从“手写清理脚本”里解放出来，也把行为统一到了声明式配置里。你能用一套规则应对多台机器，还能把规则放进版本管理。配合 systemd 的依赖关系，甚至能保证 tmp 目录的存在和干净状态发生在某些服务启动之前，这是 cron 脚本很难做到的。
2.2 配置文件与优先级
systemd-tmpfiles的配置路径有几个目录，从上到下优先级递减：
/etc/tmpfiles.d/：管理员自定义，优先级最高；/run/tmpfiles.d/：运行时生成，优先级第二；/usr/lib/tmpfiles.d/：软件包自带的默认规则，优先级最低。
systemd 启动时会扫描所有目录，同名的配置文件后者覆盖前者，不同目录下同名文件也有覆盖关系，优先级则是上面列出的顺序。这就意味着你在/etc/tmpfiles.d/里写的规则可以覆盖发行版默认的清理行为，比如把某类文件的保留时间改长、改短，或者干脆添加一个自己的规则。
我建议你查看规则时，用systemd-tmpfiles --list或者直接查看/usr/lib/tmpfiles.d/下的文件，比如发行版默认会带一个tmp.conf，里面就是针对/tmp和/var/tmp的清理规则。不同发行版默认值可能不同，比如有的默认清理/tmp超过 10 天，/var/tmp超过 30 天。你要做任何定制前，先搞清楚默认值是什么。
2.3 规则行的格式
systemd-tmpfiles的每一行规则由"类型 路径 权限 属主 属组 存活时间 参数" 七个字段组成，以空格或制表符分隔。看懂这一行，基本上就掌握了它的一半。
类型 路径 模式 属主 属组 年龄 参数举个例子，发行版tmp.conf里常见的一行：
d /tmp 1777 root root 10d拆开来解释：d表示"确保这个目录存在，如果不存在就创建它，并且设置权限和属主"，路径是/tmp，权限1777，属主和属组都是root，存活时间10d表示“内容超过 10 天就删”。注意，这里的“存活时间”只对清理操作有意义，对创建操作不生效。
3. 规则类型详解：不只是 d 和 e
3.1 常用类型逐个拆
systemd-tmpfiles支持很多类型，每个类型解决一个具体的需求。我把最常用的几个列出来：
d：目录存在性管理。如果路径不存在，就创建它；如果存在，则校正权限、属主。配合年龄参数时，还会清理目录内过期的文件。D：和d类似，但更霸道——它会递归清理目录内的所有内容，适合用于“空壳临时目录”需要被彻底清空的场景。注意用D会把目录内部结构直接清掉，如果还有其他规则依赖子目录，要谨慎。f：创建文件。如果文件不存在则创建一个，存在则仅校正权限属主，不覆盖内容。F：创建或清空文件。如果文件存在就直接清空，适合处理一些 socket 文件的残留。L：创建符号链接。没什么特别，就是管理软链接路径。v：如果路径不存在就创建文件，但不管权限。适合用来声明"可能存在的文件"。r：回收一个路径。如果有内容存在，整个递归删除。可以用来清理指定目录下所有内容。R：递归回收。比r多一层含义：如果路径本身不存在，则忽略。R /tmp/foo会把/tmp/foo里所有东西删掉，但是不创建它。X：排除规则。配合其他规则，可以指定某些路径不参与清理，这是一个非常有用的“白名单”能力。x：排除模式，和X差不多，但作用于 glob 模式。
举几个实际场景。比如你想确保/run/myservice目录存在且权限是 0700，管理员是myservice，可以写：
d /run/myservice 0700 myservice myservice -年龄字段用-表示不清理。
再比如，你想清理/var/tmp下超过 7 天的缓存子目录，但是保留keep.txt这个文件，可以这样：
d /var/tmp/cache 1777 root root 7d x /var/tmp/cache/keep.txt注意x规则要放在d规则之后，因为规则是按顺序处理的。x本身是排除模式，它匹配到的路径会被后面的清理跳过。
3.2 年龄字段支持的写法
年龄（age）这个字段非常关键，它决定了清理的“及时性”。它的写法很灵活：
s表示秒，m表示分钟，h表示小时，d表示天，w表示周。- 如果写
10m就是 10 分钟，写2h就是 2 小时，写1d就是 1 天。 - 默认情况下，判断基于文件的修改时间（mtime）。要想基于访问时间（atime），可以在年龄前面加一个
+号？其实不是，这里我澄清一下：在systemd-tmpfiles中，年龄字段默认是基于 mtime 的，但你也可以通过给年龄参数加+前缀来切换为 atime？不，这在 man 手册里并没有这种写法。真实情况是：systemd-tmpfiles 的 age 参数可以通过--atime全局选项改变清理的时间基准，而不是在配置里额外标记。系统中默认的 clean timer 没有开启 atime 模式，所以你通常只需要关心 mtime。 - 也支持多个时间单位组合，比如
1d12h表示 1 天 12 小时。虽然没必要，但你真的可以这么写。
对于/tmp目录，常见的项目实践是：/tmp内的临时文件保留 10 天，/var/tmp保留 30 天。不过很多生产环境会把这些值调得更短，比如/tmp只保留 3 天，因为现代程序基本都能容忍/tmp内容在短时间内被清空。但也有例外，比如某些程序把下载的临时文件放在/tmp下，下载时间横跨清理周期，就必须小心。所以配置前先评估业务对临时文件的依赖，再决定清理阀值。
3.3 新版本支持的其他类型
systemd 版本持续演进，systemd-tmpfiles里也增加了更多能力。比如：
t类型：可以对指定的子目录做清理，而不影响父目录的规则。e类型：确保路径存在，但不会在缺失时自动创建，而只是确保“如果父目录存在，那么子目录存在”。C类型：复制文件或目录树，用来把模板文件复制到暂存区。q和Q：支持 SELinux 上下文调整。
这些不常用，但知道它们存在，你就能在遇到特殊需求时想起这个工具，而不是立刻去写 Python 脚本。
4. 实操配置 systemd-tmpfiles 清理规则
4.1 第一步：看现状，确认默认规则
先别急着改，看清楚现在系统在做什么。用下面的命令列出所有生效的 tmpfiles 规则：
systemd-tmpfiles --list这个命令的输出会很长，重点是看/usr/lib/tmpfiles.d/里那些自带的规则文件。你可以单独查看某一个：
cat /usr/lib/tmpfiles.d/tmp.conf以某发行版为例，默认的tmp.conf内容大致是：
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d有的发行版还加了一些排除规则，比如保留/tmp/.X11-unix、/tmp/.ICE-unix等。这些 socket 目录不能被清除，否则图形会话会乱掉。这正是为什么不能光靠rm -rf去莽——你需要保护保留项。
4.2 第二步：编写自定义规则
假设我的需求是：/tmp下超过 3 天的内容全部清理；/var/tmp下超过 7 天的内容全部清理；同时创建一个只属于临时构建任务的目录/tmp/build，权限 0777，但在构建任务结束后该目录要被清空；我还要确保/tmp/remove-me里不属于当前进程使用的内容全部删掉。
那我就在/etc/tmpfiles.d/my-tmp.conf里写：
d /tmp 1777 root root 3d d /var/tmp 1777 root root 7d d /tmp/build 1777 root root - R /tmp/remove-me 1777 root root -这里解释一下：第三行d /tmp/build的年龄是-，意味着"不清理内容，只保证目录存在和权限正确"。第四行R /tmp/remove-me的作用比较危险，它会把整个目录递归清理掉，不管里面文件有多新。使用R前必须确认这个目录就是用来放置一次性废料的。
写完后，重载规则：
systemd-tmpfiles --create /etc/tmpfiles.d/my-tmp.conf systemd-tmpfiles --clean /etc/tmpfiles.d/my-tmp.conf--create会立即执行目录/文件的创建与权限设置，--clean则会根据年龄参数执行清理。如果你想看看到底会做什么，可以加--dry-run参数，这个参数非常实用：
systemd-tmpfiles --clean --dry-run /etc/tmpfiles.d/my-tmp.conf输出里会显示哪些文件会被清理，但并不会真的删除。上线前务必先跑一次 dry-run。
4.3 第三步：触发清理服务与定时器
规则文件写好后，下次开机时会自动执行systemd-tmpfiles-setup.service。但清理动作依赖systemd-tmpfiles-clean.timer，这个 timer 默认由 systemd 启用吗？不一定，不同发行版可能默认启用或需要手动 enable。
我建议你检查一下：
systemctl status systemd-tmpfiles-clean.timer发现状态不是 active 的话，立即启用：
systemctl enable --now systemd-tmpfiles-clean.timer这个 timer 的默认触发周期是每隔一段时间运行一次，具体要看/usr/lib/systemd/system/systemd-tmpfiles-clean.timer里的配置。有的发行版是每天运行，有的则是基于触发器和固定延迟。我承认默认值未必符合所有人的需求，想更频繁地清理，你可以再叠加一个自定义 timer。比如你希望每小时清理一次/tmp/build，可以写一个自己的 service+timer 单元。
顺便说一句，systemd-tmpfiles-clean.service不是由 timer 直接调用吗？是的。它内部会执行systemd-tmpfiles --clean，并且会扫描所有配置目录，最终汇聚所有规则统一清理。所以我之前手动执行systemd-tmpfiles --clean其实和 timer 做的事一样，只不过手动执行能立即看到效果，更直观。
4.4 通过 systemd-tmpfiles 管理运行时目录
除了 tmp 目录，/run也是 systemd-tmpfiles 的主场。/run是 tmpfs，重启后丢失，但很多服务的 pid 文件和 socket 都放在这。你可以在自己的规则里声明一个/run/myapp目录，确保服务启动时目录已经就绪：
d /run/myapp 0755 myuser myuser -只要写了这条规则，并在服务单元里加上After=systemd-tmpfiles-setup.service，就能保证目录先于服务创建。这个能力比老式 init 脚本里手动mkdir -p优雅很多，而且权限和属主都通过配置声明，不会因脚本顺序问题导致权限不对。
5. 常见问题与排查技巧实录
5.1 清理规则没生效？从这几处查
第一个检查点：配置文件语法。systemd-tmpfiles对字段数量要求严格，少一个字段就可能整行被忽略。你用--create或--clean跑一遍，如果语法有问题，stderr 会直接报错。比如少了年龄字段，有的版本会报 "Invalid line"，有的会静默跳过，所以一定要用--dry-run观察输出。
第二个检查点：规则同名覆盖。如果发行版自带的配置里也有一个my-tmp.conf存在于/usr/lib/tmpfiles.d/，那么你的/etc/tmpfiles.d/my-tmp.conf会完全覆盖它。如果你在/usr/lib里已经有同名文件，最好换个名字，否则你会有两套内容，容易造成理解混乱。
第三个检查点：timer 是否在跑。使用systemctl list-timers | grep tmpfiles来确认。如果 timer 没启用，你之前手动跑过清理，看起来正常，但下次开机后可能就没人清理了。这个坑特别隐蔽，因为你在测试时手动执行了--clean，一切正常，结果过了一个月发现/tmp又满了。
第四个检查点：进程占用导致无法删除。systemd-tmpfiles清理文件时，如果文件正被进程打开，它并不会强制删除？其实它可以删除未链接的文件，因为删除操作只是解除路径链接，进程仍持有 inode。但如果文件所属目录被占用，或者文件处于特殊挂载点（如 mount namespace 里），删除可能失败。你可以用lsof +D /tmp看看哪些文件被谁占用，来理解清理时的异常。
5.2 误删保护：volatile 文件的坑
systemd-tmpfiles的清理规则默认是按 mtime判断，但tmpfs本身就是内存文件系统，重启即清空。如果你把/tmp挂载为 tmpfs，那么systemd-tmpfiles里针对/tmp的年龄规则意义不大——因为每次重启都会清空。但如果你没有配置开机自动清理，只靠 tmpfs 的"重启即干净"特性，那如果系统长期不重启，/tmp还是会越积越多。
我见过一个案例：有人把/tmp挂成 tmpfs，觉得爽，结果一个下载程序在/tmp里写了几十 GB 的临时文件，因为 tmpfs 消耗的是内存，内存被吃光后，swap 疯狂使用，最后系统卡死。解决方案很简单：在 tmpfs 上依然要配置systemd-tmpfiles的清理规则，让它在运行期间定期清理，不能让 tmpfs 无限增长。
如果你确实需要非常激进地清空目录，可以在规则里用D或R，但要先确认这个目录里没有任何需要长期运行的服务依赖。比如/tmp/.X11-unix绝对不能清理，否则图形界面会崩。我建议在你的自定义规则里把这些特殊目录都排除掉，或者干脆沿用发行版默认规则里的排除项。
下面是一个常见的排除示例，来自不少发行版默认的tmp.conf：
X /tmp/.X11-unix X /tmp/.ICE-unixX类型会排除整个目录树。当然你也可以用x排除某个具体文件。要特别注意，x和X的规则顺序要在清理规则之后，因为systemd-tmpfiles是按顺序处理的，先定义清理规则，后定义排除规则，处理时看到匹配到排除项就会停止清理。
5.3 dry-run 模式真的要多用
我在任何生产环境操作前，都强烈建议先跑 dry-run：
systemd-tmpfiles --clean --dry-run --verbose /etc/tmpfiles.d/my-tmp.conf--verbose会显示每个文件的状态，--dry-run不会真正修改文件系统。输出中会出现类似 "Cleanup of /tmp/xxx" 的行，这就是最后会被删掉的文件。拿这个列表和业务脚本确认一下，没有问题了再实际执行。
我踩过一个坑：有一次我把d类型的年龄参数设成了3d，没想到某个临时目录里有几个文件是 4 天前创建的，结果一下全没了。用 dry-run 就能提前发现这种局面，不至于等业务崩了才追悔莫及。所以，这条建议真的不是废话——多花十秒钟跑一遍，能省掉一整天的救火时间。
5.4 文件属性和清理的相互作用
还有一个经常被忽略的细节：temp_file的权限与属主。systemd-tmpfiles清理时是以 root 身份执行，所以基本上没有权限障碍。但如果你的应用创建的临时文件属于别的用户，而你用普通用户身份手动执行清理命令，就会出现权限不够导致删除失败。因此在生产环境中，清理最好交给 systemd 的 timer（root 权限），不要自己在 crontab 里用普通用户跑。
另外，/tmp目录本身必须是sticky bit，也就是权限为1777。如果sticky bit丢了，比如手滑执行了chmod 777 /tmp，那么任何用户都能删除别的用户创建的文件，安全性会大打折扣。我在检查用户体验问题时遇到过：某个用户运行程序因为临时目录权限异常而报错，最后发现就是/tmp的权限少了一个 sticky bit。用这条命令修正：
chmod 1777 /tmp同样的道理，/var/tmp也是 1777。
6. 设计一套契合的清理策略
6.1 选择合适的清理周期
每个环境的业务特点不同，清理周期需要掂量。对于绝大多数通用服务器，我推荐：
/tmp：3~7 天都可以。/var/tmp：7~30 天，取决于是否有跨重启的临时需求。/run目录：通常不清理，因为它是 tmpfs，不会长期堆积。
如果你的服务器上跑着长时间运行的任务，比如数据处理程序，它会临时用/tmp存放中间结果，那清理周期至少要大于任务最长运行时间，否则任务会中途报“文件不存在”。这种场景下，宁可把周期调大，也不要冒失清理。
我习惯在与业务沟通后，明确列出所有/tmp的“白名单”路径。比如某些数据分析程序会在/tmp/spark-*下放 shuffle 数据，清理周期必须盖过任务时间。在规则里可以用排除项把这些目录单独保护起来：
x /tmp/spark-*x支持通配符，很好用。
6.2 把规则写进版本管理
运维应该像开发一样对待配置。我建议把/etc/tmpfiles.d/下的所有规则文件纳入 Git 仓库管理。这样当你在一台机器上验证过规则，可以直接同步到几十台机器上，避免大家各写各的、乱成一锅粥。
你可以写一个简单的脚本，把仓库里的 rules 文件同步到所有服务器，并触发一次校验：
#!/bin/bash git pull rsync -av tmpfiles.d/ /etc/tmpfiles.d/ systemd-tmpfiles --create --dry-run systemd-tmpfiles --clean --dry-run echo "Rules synced, verify manually before production."这类工具化思维能让你吃尽 systemd-tmpfiles 的版本化红利。
6.3 监控 tmp 目录水位
有了清理机制，还得有监控。最好的做法是设置磁盘水位告警，当/tmp（或/var/tmp）所在分区的使用率超过 80% 或 90% 时发送告警。你可以用df -h /tmp查看当前用量，用du -sh /tmp/*查看哪个文件占得多。如果发现垃圾清理不掉，排查原因时先用systemd-tmpfiles --clean --dry-run --verbose看能不能识别出明明该清却没清的文件。
有个比较隐藏的问题：如果你把/tmp挂载为 tmpfs，df会显示它的内存占用是动态的，无法用分区使用率来告警，此时要监控内存整体水位。反正不管哪种方式，忘记监控都是在裸奔。
7. 掌控 tmp 管理之后，还能做什么
掌握了 systemd-tmpfiles 的基本用法，你就理解了 systemd 生态的一个核心理念：任何系统状态的改变，最好用声明式的可复用配置来定义，而不是一堆手工命令。这个理念其实可以延伸得很远。
比如你可以用systemd-tmpfiles管理很多"半临时"的运行时数据：Jupyter 的 runtime 目录、Jenkins agent 的工作目录、Docker 的临时运行文件。只要这个路径下的数据处于"可丢失、可重建"的状态，就可以把它纳入 systemd-tmpfiles 的管辖范围。但注意，千万不要用 systemd-tmpfiles 管理真实业务数据目录，它的清理机制不是备份系统，误删不负责任。
从我多年的运维经验看，真正让系统更稳定的，不是哪一种“神级”命令，而是你把需要做的事情固化成了可重复、可验证的流程。systemd-tmpfiles恰恰就提供了这种标准化流程。你不再需要纠结tmpwatch的 atime 问题，不再需要手写一堆find -delete的脚本，只需要配置文件里写几行，剩下的交给 systemd 去执行。
最后说一个我个人的小巧思：如果你在管理一批发行版混杂的服务器，比如既有 Debian 又有 Ubuntu 还有衍生发行版，可以先写一套完全通用的 tmpfiles 规则，不依赖任何发行版特有路径。然后在各个发行版上跑一次systemd-tmpfiles --create，看有没有不兼容的警告，再针对具体差异做小范围 patch。这套兼容性打法，比盲目拿一个发行版的规则往另一个上面套要省心得多。系统管理这事儿，标准化的同时永远记得留一手灵活性。
