Deleting shared memory with ipcrm in Linux

Question

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.

Answer 1

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 ipcs output 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.