ipcs -m -p -t 是确认共享内存使用者的最直接方法，显示 cpid（创建者 PID）、lpid（最后操作者 PID）及时间戳；需配合 ps 或 /proc/*/maps 进一步定位进程，且必须同时使用 -m 和 -p。
ipcs -m -p -t 能看到谁在用共享内存
想确认哪个进程正在读写某块共享内存，ipcs -m -p -t 是最直接的入口。它会显示每段共享内存的 cpid（创建者 PID）和 lpid（最后操作者 PID），以及最后 shmat/shmdt 的时间戳。
常见错误是只跑 ipcs -m 就停了，看不到进程关联；或者误以为 ipcs -m -i shmid 也能带出进程 ID —— 实际上不加 -p 就不会输出 PID 列。
-
ipcs -m -p必须和-m同时出现，单独-p无效 - 输出中的
cpid和lpid是十进制整数，可直接传给ps -p <pid> -o pid,comm,args查进程名和命令行 - 如果
lpid是 0，说明近期无进程操作过该段（但可能仍被附加着）
grep shm /proc/*/maps 定位映射关系
System V 共享内存（shmget 创建的）在 /proc/<pid>/maps 中表现为 shmid=0xXXXX 格式；POSIX 共享内存（shm_open）则显示为 /dev/shm/xxx。这是绕过 ipcs、从进程侧反查的可靠方式。
容易忽略的是权限问题：grep 遍历 /proc/*/maps 时，非 root 用户会遇到 “Permission denied”，导致漏掉部分进程。建议用 sudo 执行，或限定范围如 grep shm /proc/[1-9]*/maps 2>/dev/null。
- 匹配到
shmid=0x1234后，可用ipcs -m | grep 0x1234反查对应shmid -
/dev/shm/下的文件属于 POSIX IPC，ipcs默认不显示，得用ls /dev/shm单独看 - 同一进程可能同时映射多个共享内存段，
maps文件里会有多行含shm
ipcs -q -p 查消息队列的收发方
消息队列的通信细节比共享内存更动态：ipcs -q -p 显示的是 cuid（创建者 UID）、lspid（最后 msgsnd 进程 PID）、lrpid（最后 msgrcv 进程 PID）。这三者能拼出“谁发、谁收”的基本链路。
注意 lspid 和 lrpid 是瞬时值，如果队列空闲，它们可能长期不变；而 ipcs -q -t 的时间戳字段更能反映活跃度——last-msgsnd 和 last-msgrcv 时间差过大，说明收发逻辑可能卡住或失配。
- 若
lspid或lrpid为 0，不代表没进程，只是该操作尚未发生 -
ipcs -q -i qid不显示收发 PID，必须加-p - 消息队列没有 “nattch” 类似字段，无法直接看出当前有多少进程在监听，得靠
ps结合业务逻辑推断
ipcs -l 和 ipcs -u 揭示资源瓶颈
很多 IPC 通信异常（如 shmget: No space left on device）不是进程 bug，而是内核限制触顶。ipcs -l 显示硬限制（如最大共享内存段数、单段最大字节数），ipcs -u 显示当前已用数量。两者一对照，立刻知道是真满还是假满。
一个典型陷阱：修改 /proc/sys/kernel/shmall 后忘了同步改 shmmax，结果 ipcs -l 里 “max size of shared memory segment” 还卡在旧值，新程序依然分配失败。
-
ipcs -l中的max number of shared memory segments对应/proc/sys/kernel/shmmni -
ipcs -u的 “segments allocated” 是当前活跃段数，不包括已标记删除但仍有进程 attached 的段 - 信号量集的
nsems总数要和ipcs -l的 “max semaphores per semaphore set” 对齐，超限会直接semget失败
