no space left on device 但 df -i inode 还有的 tmpfs / dev/shm 问题

9次阅读

/dev/shm 被写满会导致“No space left on device”错误,因其基于 tmpfs,空间受限于内存而非磁盘或 inode;可用 df -h /dev/shm 确认,清理可 rm -f /dev/shm/* 或用 ipcs/ipcrm 安全释放,也可 remount 增大 size。

no space left on device 但 df -i inode 还有的 tmpfs / dev/shm 问题

你遇到的 no space left on device 错误,但 df -h 显示磁盘空间充足、df -i 显示 inode 也未耗尽,而 /dev/shm(基于 tmpfs)又在其中——这大概率是 /dev/shm 本身被写满,且其大小受限于内存+swap,而非磁盘空间或inode数量。

为什么 /dev/shm 满了会导致 “No space left on device”

/dev/shm 是一个 tmpfs 文件系统,默认挂载在内存中(可交换到 swap),用于 POSIX 共享内存(如 shm_open())、某些数据库临时段、容器运行时(如 docker 的 shm)、甚至某些 python 多进程(multiprocessing.shared_memory)也会用到它。它的“空间”不是磁盘块,而是内存页;它的限制不是 inode,而是 size= 挂载参数(默认通常为 64MB 或半内存)。一旦写满,任何尝试向它写入(比如创建共享内存对象、启动新容器、运行多进程程序)都会直接报 No space left on device,即使磁盘和 inode 宽裕。

快速确认 /dev/shm 是否已满

运行以下命令:

df -h /dev/shm
ls -l /dev/shm/ | wc -l
find /dev/shm -type f -ls 2>/dev/null | head -10

  • df -h /dev/shm 查看已用/可用大小(注意不是 %Used,而是 Available 列是否为 0)
  • ls -l /dev/shm/ | wc -l 看有多少个共享内存文件(常有大量 sem.*shmem_*CoreDump_* 等)
  • find 命令列出大文件或残留对象(有些不会显示在 ls 中,需用 ipcs -m 配合)

清理 /dev/shm 的常用方法

  • 清空当前所有 shm 对象(谨慎!会中断依赖它的进程):
    sudo rm -f /dev/shm/*
    ⚠️ 注意:如果正在运行 redispostgresql、Docker 容器或 Python 多进程程序,此举可能导致它们崩溃或异常退出
  • 释放无引用的 POSIX 共享内存(更安全):
    sudo ipcs -m | awk 'NR>3 {print $2}' | xargs -r -I{} sudo ipcrm -M {}
    (清理共享内存段)
    sudo ipcs -q | awk 'NR>3 {print $2}' | xargs -r -I{} sudo ipcrm -Q {}
    (清理消息队列,有时也占 shm)
  • 重启占用 shm 的服务(推荐):例如:sudo systemctl restart dockersudo systemctl restart redis。多数服务会在重启时自动清理自己创建的 shm 资源
  • 临时增大 /dev/shm 容量(治标):
    sudo mount -o remount,size=2G /dev/shm
    该设置重启后失效;若要永久生效,修改 /etc/fstab 中对应行:
    tmpfs /dev/shm tmpfs defaults,size=2G 0 0

预防再次填满

  • 检查是否有程序反复创建但不销毁共享内存(常见于未正确调用 shm_unlink()close() 的 C/Python 程序)
  • Docker 用户:避免使用 --shm-size=auto 或过小值;必要时显式指定,如 --shm-size=1g
  • 监控脚本可加入:df -B1 /dev/shm | awk 'NR==2 {if ($4+0
  • 对长期运行的服务(如数据库),定期检查 ipcs -m 输出,确认段数是否持续增长

text=ZqhQzanResources