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.
A process creates a shared memory segment using shmget(2). This call is also used to get the ID of an existing shared segment. The creating process sets the permissions and the size in bytes for the segment. The original owner of a shared memory segment can assign ownership to another user with shmctl(2).
Accessing shared memory objects via the filesystem On Linux, shared memory objects are created in a (tmpfs(5)) virtual filesystem, normally mounted under /dev/shm. Since kernel 2.6. 19, Linux supports the use of access control lists (ACLs) to control the permissions of objects in the virtual filesystem.
free displays the unused memory. shared displays the memory used by tmpfs(Shmen i.epresent in /proc/meminfo and displays zero in case not available). buffers displays the memory used by kernel buffers. cached displays the memory used by the page cache and slabs(Cached and Slab available in /proc/meminfo).
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With