/run分区（tmpfs）占用无法缩减致满需重启的问题求助

你遇到的核心问题大概率是有进程持有已删除文件的文件句柄——tmpfs是内存文件系统，理论上文件删除后会立即释放内存，但如果进程还攥着已删除文件的句柄不放，这块空间就会一直被占用，直到进程重启或主动释放句柄。结合你给出的配置和进程信息，咱们一步步排查解决：

1. 定位占用已删除文件的进程 #

先执行这条命令，找出所有持有/run下已删除文件句柄的进程（重点看大文件）：

lsof | grep "(deleted)" | grep "/run"

你提到/run/log/journal大小稳定但整体占用没降，很大可能是systemd-journald或rsyslogd这类日志进程，拿着旧日志文件的句柄没松手。

2. 强制journald清理并释放句柄 #

虽然你已经配置了RuntimeMaxUse=400M和RuntimeKeepFree=2G，但journald可能没自动触发清理。手动执行以下命令强制轮转+压缩日志：

journalctl --rotate
journalctl --vacuum-size=400M

第一行是强制生成新的日志文件，第二行是把运行时日志压缩到400M以内。之后检查journald是否还抱着旧文件：

lsof -p $(pidof systemd-journald) | grep "(deleted)"

如果还有已删除的文件条目，直接重启journald服务（不用重启整个系统）：

systemctl restart systemd-journald

3. 检查并修复rsyslogd的占用 #

你的进程信息里提到了rsyslogd，它也可能持有/run下的日志文件句柄。执行这条命令查看它的打开文件：

lsof -p $(pidof rsyslogd) | grep "/run"

如果发现有已删除的大文件，重启rsyslogd就能释放空间：

systemctl restart rsyslogd

4. 验证空间回收效果 #

完成上述操作后，用df -h /run查看/run的占用情况，应该会回到你预期的408M左右。如果还是没降，就用这条命令按文件大小倒序排查所有持有已删除文件的进程：

lsof | grep "(deleted)" | sort -k7 -rn

找到占用最大的那个进程，重启对应的服务即可。

5. 优化journald配置防止复发 #

你已有的配置基础上，再加几个参数让journald更主动地管理资源：
编辑/etc/systemd/journald.conf，确保以下配置生效：

[Journal]
RuntimeMaxUse=400M
RuntimeKeepFree=2G
RuntimeMaxFileSize=50M  # 单个日志文件最大50M，避免单个文件过大
MaxRetentionSec=7day     # 日志最多保留7天，可按需调整
ForwardToSyslog=no       # 不需要转发日志给rsyslogd的话可以关闭，减少资源占用

修改后重启journald让配置生效：

systemctl restart systemd-journald

内容的提问来源于stack exchange，提问作者DBE