查共享内存段用 ipcs -m，而非仅看磁盘空间；enospc 错误多因 system v 共享内存段数超限（默认 4096），需用 ipcrm -m 清理残留段，注意空格、权限及 nattch=0 不代表已释放。
查共享内存段用 ipcs -m，别只看磁盘空间
当你遇到 shmget 返回 ENOSPC、报错 “No space left on device”，第一反应别急着 df -h。这大概率不是磁盘满了，而是 System V 共享内存段数量超限——内核默认最多 4096 个段，压测或进程异常退出后残留的段会一直占着编号，直到手动清理或重启系统。
执行 ipcs -m 查当前所有段，重点关注三列：
-
shmid：段 ID，删除时要用 -
key：创建时传入的键值（如0x3fd8259c），可用于批量清理 -
nattch：当前连接数，为 0 不代表能自动释放；status显示dest表示已被标记删除但仍有进程未 detach
删单个段用 ipcrm -m <shmid></shmid>，注意空格和权限
ipcrm -m131072 这种写法在某些 shell 下会失败——-m 和 ID 之间必须有空格，否则会被当做一个参数解析失败。正确写法是 ipcrm -m 131072。
另外，ipcrm 默认只允许删除当前用户拥有的段。如果你看到 root 或 oracle 创建的段，得切到对应用户执行，或用 sudo（需确保该用户有对应权限）。
常见误操作：
- 直接
ipcrm -m不带 ID → 报错 “missing argument” - ID 输错（比如把
shmid看成key）→ 提示 “No such file or directory” - 段正被使用（
nattch > 0）→ 删除命令能执行成功，但段实际不会立即销毁，要等最后一个shmdt()后才真正释放
批量删用 ipcrm -M <key></key> 或管道组合，慎用 -a
如果多个段共用同一个 key（比如都用 ftok(".", 'a') 生成），可以用 ipcrm -M 0x12345678 一次性删掉所有匹配键值的段——比逐个记 ID 高效得多。
更灵活的方式是结合 ipcs -m 输出过滤后自动清理：
ipcs -m | awk '$2 ~ /^[0-9]+$/ && $3 == "your_user" {print $2}' | xargs -r ipcrm -m
这条命令只删指定用户创建的活跃段（排除 key 为 0x00000000 的匿名段，它们通常更难追溯来源）。
别轻易用 ipcrm -a（删除当前用户所有 IPC 对象）——它不区分类型，会连消息队列、信号量一起清掉，可能让其他正常运行的服务卡死。
程序里没调 shmctl(..., IPC_RMID, ...) 就退出？那就只能靠外部清理
System V 共享内存没有“作用域自动释放”机制。进程 crash、Ctrl+C 中断、甚至 exit() 前忘了调 shmctl(shmid, IPC_RMID, NULL)，段就永久滞留。POSIX 共享内存（shm_open+shm_unlink）好一点，但 shm_unlink 也只是删名字，映射仍存在，得等所有 munmap 完才真正释放。
所以最稳妥的做法是：
- 开发阶段加信号处理：捕获
SIGINT/SIGTERM后主动shmctl(..., IPC_RMID, ...) - 调试时养成习惯：每次改完代码，先
ipcs -m | grep your_key确认无残留 - 上线前检查内核限制：
cat /proc/sys/kernel/shmmni（段总数上限），必要时调高
真正麻烦的不是删不掉，而是删完发现另一个服务悄悄复用了刚释放的 shmid——因为 ID 是递增分配的，旧段一清，新段立刻顶上，日志对不上号。这时候得靠 key 而不是 shmid 来追踪归属。
