no space left on device 但 df 显示还有空间的 tmpfs 挂载点耗尽

5次阅读

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 防止失控）