非root用户执行ipcs -m默认仅显示自己创建的System V共享内存段，因内核权限隔离；需sudo ipcs -ma才可查看全部，且ipcs -m不显示POSIX共享内存（需ls -l /dev/shm/）。
ipcs -m 为什么没输出或只看到自己创建的段
非 root 用户执行 ipcs -m 默认只能看到自己创建的 System V 共享内存段，这是内核的权限隔离机制，不是命令出错。如果预期有其他用户或系统服务创建的段但看不到，直接加 -a 参数无效——必须用 sudo ipcs -ma 才能绕过用户过滤。
常见错误现象：Permission denied 或返回空；ipcs -m 输出里 nattch 全是 0 却找不到对应进程——说明这些段已被释放但未显式删除，属于残留资源。
- 普通用户查全部：必须用
sudo ipcs -ma，不能只靠-a -
key值为0x00000000表示该段用IPC_PRIVATE创建，无法被其他进程通过shmget()关联 - 看到大量
shmid且nattch == 0，基本可判定是程序崩溃后漏调shmctl(shmid, IPC_RMID, NULL)
怎么区分 System V 和 POSIX 共享内存
ipcs -m 只显示 System V 共享内存（即通过 shmget()/shmctl() 创建的），完全不感知 POSIX 共享内存（shm_open() + mmap() 映射 /dev/shm/ 下的文件）。如果你的程序用了后者，ipcs -m 必定为空，这不是遗漏，是体系不同。
验证方法很简单：检查代码是否含 shm_open() 或路径操作 /dev/shm/xxx；或者直接运行 ls -l /dev/shm/ 看有没有对应文件。
- POSIX 共享内存占用空间查法：
df -h /dev/shm看总用量，find /dev/shm -type f -exec ls -lh {} \;查单个对象大小 - System V 共享内存不会在
/dev/shm/下生成文件，反之亦然 - 两者可共存，但监控、清理、调试必须用不同命令
如何快速定位某个 key 或 shmid 对应的共享内存
已知键值（比如日志里报的 0xd201012b）或 ID（如 3080195），别用 grep 模糊匹配——容易误伤，直接用 ipcs 内置筛选更准。
注意参数组合：查 key 要用 -q（不是 -k），查 ID 要用 -i 并配合 -m；单独用 -i 不指定资源类型会报错。
- 按 key 查：
ipcs -m -q 0xd201012b（支持十六进制或十进制） - 按 shmid 查：
ipcs -m -i 3080195 - 想同时看权限和附加进程数？不用额外参数，默认就包含
perms和nattch字段
为什么 ipcs -l 显示的上限值很重要
ipcs -l 输出的是内核硬限制，比如 max number of shared memory segments 是整个系统最多允许多少个 System V 共享内存段。一旦达到这个数，即使内存充足，shmget() 也会直接失败并返回 ENOSPC。
很多“创建共享内存失败”的问题，查日志只看到 errno=28，却忽略这一步——其实不是内存不够，是段数量超限了。尤其在容器或长期运行的服务中，泄漏积累后很容易触顶。
- 关键字段重点关注：
max number of shared memory segments、max size of shared memory segment、max total shared memory (kbytes) - 修改需改内核参数：
sysctl -w kernel.shmmni=4096等，但重启失效，要持久化得写入/etc/sysctl.conf -
ipcs -l的值和实际ipcs -m列表长度无关，它管的是“未来还能建几个”，不是“现在用了几个”
shmctl(..., IPC_RMID, ...) 显式销毁，后者靠 shm_unlink() 或 rm /dev/shm/xxx。混用或只清一边，都会留下隐形资源。 
