CODEWITHSUNDEEP
linuxshared-memory
Scott Hunter
Scott Hunter

Reputation: 49803

Technique to find shared memory names currently used

When one opens a shared memory object (using shm_open), you provide a name for that object. Each object must have a distinct name.

Is there a way to identify the names of all of the currently allocated shared objects? And if so, how?

Update: It would appear that, in my case, these are (as @HristoLliev calls them) System V shared memory segments. ipcs -m reports a list of segments similar to what I expect, but does not show the names.

Upvotes: 7

Views: 14575

Answers (1)

Hristo Iliev
Hristo Iliev

Reputation: 74355

shm_open(3) on Linux relies on tmpfs, usually mounted under /dev/shm. What shm_open() does is to convert the object name into a file path by prepending it with the mount point of the tmpfs filesystem. As long as the shared memory object is not unlinked, it will be visible in the filesystem and all you need to do is issue a simple ls command:

$ ls /dev/shm
pulse-shm-1   pulse-shm-2   pulse-shm-3
...

Some Linux distributions have tmpfs mounted under a different mountpoint. In order to find out where, issue:

$ mount -t tmpfs
tmpfs on /dev/shm type tmpfs (rw)

If you want to know which process(es) has/have mapped shared memory objects, the lsof command is your friend:

$ lsof /dev/shm
COMMAND     PID     USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
kded4     30657   hristo mem    REG   0,16 67108904 294877 /dev/shm/pulse-shm-1
kded4     30657   hristo mem    REG   0,16 67108904 294868 /dev/shm/pulse-shm-2
knotify4  30687   hristo mem    REG   0,16 67108904 294876 /dev/shm/pulse-shm-3
pulseaudi 30717   hristo mem    REG   0,16 67108904 294868 /dev/shm/pulse-shm-4
shm.x     31878   hristo DEL    REG   0,16          305893 /dev/shm/asd

Unlinked shared objects are no longer visible in the filesystem, though they might still persist if mapped in by some process as is the case with the last process in the list above - DEL in the FD field means that the corresponding file was deleted.

Note that System V shared memory segments (as obtained by ipcs -m) live in a different name space and do not have corresponding object names, just numeric keys.

Upvotes: 19

Related Questions