tmpfs空间不足导致“No space left on device”错误，因其占用内存而非磁盘；需用df -h -t tmpfs定位满载挂载点，再用du排查大文件，最后安全清理或限制大小。
这通常是因为 tmpfs 挂载点（如 /run、/dev/shm、/sys/fs/cgroup 等）的内存配额被占满，而 df 显示的是其**配置大小**（比如 1G），并非实际磁盘空间 —— 它根本不使用磁盘，而是直接占用 RAM 和 swap。所以即使硬盘还有大量空间，tmpfs 仍会报 “No space left on device”。
检查哪个 tmpfs 挂载点满了
运行以下命令，重点关注 Use% 列和 Mounted on：
df -h -t tmpfs
常见易满的挂载点包括：
-
/run：存放运行时文件（如 socket、pid、systemd 日志缓冲） -
/dev/shm：POSIX 共享内存，默认通常 64M，小而敏感 -
/sys/fs/cgroup：cgroup v2 的挂载点，某些容器或服务可能泄漏 cgroup 目录
快速定位大文件或残留目录
进入疑似满载的 tmpfs 目录，用 du 查看占用（注意：tmpfs 中的文件不落地，du 统计的是内存占用）：
sudo du -sh /run/* 2>/dev/null | sort -hr | head -10
特别关注：
-
/run/user/1000下残留的 D-Bus 或 X11 socket（用户登出未清理） -
/run/docker.sock正常，但/run/containerd或/run/crio下异常子目录 -
/dev/shm中长期存在的大共享内存段（如未正确释放的 ML 训练进程、数据库临时缓存） -
/sys/fs/cgroup下成千上万个空但未销毁的 cgroup 目录（常见于频繁启停容器且 cgroup v2 + systemd 混用场景）
安全清理与预防措施
清理前确认无关键进程依赖：
- 清空
/dev/shm（无持久数据）：sudo rm -f /dev/shm/* - 重启 systemd-journald 释放
/run/log/journal缓冲：sudo systemctl kill --signal=SIGUSR1 systemd-journald - 清理已退出用户的 runtime 目录：
sudo systemd-run --scope --collect --property="MemoryMax=50M" loginctl cleanup-sessions - 限制 tmpfs 大小（永久生效）：在
/etc/fstab中修改对应行，例如：tmpfs /dev/shm tmpfs defaults,size=256M 0 0 - 对容器环境，启用 cgroup v2 的自动回收（确保内核参数
systemd.unified_cgroup_hierarchy=1，并设置DefaultLimitNOFILE和DefaultLimitMEM防止失控）
验证是否释放成功
清理后立即检查：
df -h -t tmpfs | grep -E "(shm|run|cgroup)"
同时观察错误是否消失。若问题反复出现，建议配合 inotifywait -m /run 或 auditd 追踪谁在持续写入。
