Linux 中使用 ipcrm 删除共享内存
我正在使用共享内存应用程序，并使用以下命令删除段：
ipcrm -M 0x0000162e (this is the key)
但我不知道我是否在做正确的事情，因为当我运行 ipcs 时，我看到了相同的内容段，但密钥为 0x0000000。 那么内存段真的被删除了吗？ 当我多次运行应用程序时，我会看到不同的内存段，其键为 0x000000，如下所示：
key shmid owner perms bytes nattch status
0x00000000 65538 me 666 27 2 dest
0x00000000 98307 me 666 5 2 dest
0x00000000 131076 me 666 5 1 dest
0x00000000 163845 me 666 5 0
到底发生了什么？ 内存段真的被删除了吗？
编辑：问题是 - 正如下面接受的答案中所述 - 有两个进程使用共享内存，直到所有进程都关闭为止，内存段不会消失。
I am working with a shared memory application, and to delete the segments I use the following command:
ipcrm -M 0x0000162e (this is the key)
But I do not know if I'm doing the right things, because when I run ipcs I see the same segment but with the key 0x0000000. So is the memory segment really deleted? When I run my application several times I see different memory segments with the key 0x000000, like this:
key shmid owner perms bytes nattch status
0x00000000 65538 me 666 27 2 dest
0x00000000 98307 me 666 5 2 dest
0x00000000 131076 me 666 5 1 dest
0x00000000 163845 me 666 5 0
What is actually happening? Is the memory segment really deleted?
Edit: The problem was - as said below in the accepted answer - that there were two processes using the shared memory, until all the process were closed, the memory segment is not going to disappear.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我依稀记得在我使用 UNIX（AIX 和 HPUX，我承认我从未在 Linux 中使用过共享内存）的日子里，删除只是将该块标记为新客户端不再可附加。
只有在没有更多进程附加到它之后，它才会在某个时刻被物理删除。
这与删除的常规文件相同，它们的目录信息被删除，但文件的内容仅在最后一个进程关闭后消失。 这有时会导致日志文件占用文件系统上越来越多的空间，即使它们被删除，因为进程仍在写入它们，这是文件指针（指向的零个或多个目录条目）之间“分离”的结果索引节点）和文件内容（索引节点本身）。
您可以从
ipcs输出中看到，4 个进程中的 3 个仍然具有附加进程，因此在这些进程与共享内存块分离之前它们不会去任何地方。 另一个可能正在等待一些“清除”函数来清理它，但这当然取决于共享内存的实现。编写良好的共享内存（或日志文件）客户端应定期重新连接（或翻转），以确保这种情况是暂时的并且不会影响软件的操作。
I vaguely remember from my UNIX (AIX and HPUX, I'll admit I've never used shared memory in Linux) days that deletion simply marks the block as no longer attachable by new clients.
It will only be physically deleted at some point after there are no more processes attached to it.
This is the same as with regular files that are deleted, their directory information is removed but the contents of the file only disappear after the last process closes it. This sometimes leads to log files that take up more and more space on the file system even after they're deleted as processes are still writing to them, a consequence of the "detachment" between a file pointer (the zero or more directory entries pointing to an inode) and the file content (the inode itself).
You can see from your
ipcsoutput that 3 of the 4 still have attached processes so they won't be going anywhere until those processes detach from the shared memory blocks. The other's probably waiting for some 'sweep' function to clean it up but that would, of course, depend on the shared memory implementation.A well-written client of shared memory (or log files for that matter) should periodically re-attach (or roll over) to ensure this situation is transient and doesn't affect the operation of the software.
你说你使用了以下命令
来自 ipcrm 的手册页
因此 -M 选项的行为与您所观察到的完全一致，即将段设置为仅在最后一次分离后才被销毁。
You said that you used the following command
From the man page for ipcrm
So the behaviour of -M options does exactly what you observed, ie set the segment to be destroyed only after the last detach.