Inspect Linux IPC Usage Safely with lsipc
A shared-memory segment nobody remembers creating, or a message queue creeping towards its limit, is a job for lsipc, not for ipcrm on a hunch. This guide covers inspecting System V and POSIX shared memory, message queues and semaphores, then narrowing the output to columns that are safe to use in a script. The examples describe util-linux 2.41.3, the version installed on this machine. Allow about ten minutes.
The route
Jump straight to the step you need, or tick off Done means at the end.
You need a shell and a readable IPC system; the normal checks are read-only and do not require sudo.
Checkpoint
This guide only observes IPC. It does not create, remove, attach to or alter an IPC object. Do not substitute ipcrm or an application command for any example here: those tools can change live inter-process communication.
1. Confirm the installed command
Start by checking the command and package version:
$ lsipc --version
lsipc from util-linux 2.41.3
Your version may differ. The manual warns that default output, including the output selected by resource options, can change between releases. That makes the version worth recording when you attach an lsipc result to an incident or change record.
2. See the system-wide limits and current usage
Run the global view without elevated privileges first:
$ lsipc --global
RESOURCE DESCRIPTION LIMIT USED USE%
MSGMNI Number of System V message queues 32000 0 0.00%
MQUMNI Number of POSIX message queues 256 0 0.00%
SHMMNI Shared memory segments 4096 1 0.02%
SEMMNI Number of semaphore identifiers 32000 0 0.00%
The complete output contains more rows. LIMIT is the system-wide limit and USED is the current usage where that comparison is meaningful. A dash in a limit or usage field is not a failure: some rows describe a limit rather than a count of allocated objects.
Checkpoint
Record the rows relevant to your problem, not just the largest percentage. A nearly full queue limit and a single large shared-memory segment are different investigations.
3. List one kind of System V resource
Select a resource with --shmems, --queues or --semaphores. For example, list active System V shared-memory segments:
$ lsipc --shmems
KEY ID PERMS OWNER SIZE NATTCH STATUS CTIME CPID LPID COMMAND
0x0d224dab 229391 rw------- postgres 56B 37 Sep22 3097710 3795197 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main
Values depend on the host. The output can expose owner names, process IDs and command lines, so treat a captured report as operational data rather than something to paste into a public issue without review. The command needs read access to the facilities it reports. If it fails with a permission error, investigate the account and host policy before reaching for sudo; elevated access is not required as a routine step.
4. Include POSIX IPC explicitly
System V and POSIX objects use different resource options. Use the uppercase forms for POSIX resources:
$ lsipc --posix-shmems
$ lsipc --posix-mqueues
$ lsipc --posix-semaphores
An empty result can be a valid result: it means the command found no readable objects of that type, not that System V IPC is also empty. Run the matching option for the implementation your application uses.
5. Make a stable report for scripts
Do not parse the default table in automation. The manual says that defaults may change, so name the columns with --output. This report asks for the generic key, identifier, owner and permissions plus shared-memory size and attachment count:
$ lsipc --shmems --output KEY,ID,OWNER,PERMS,SIZE,NATTCH
KEY ID OWNER PERMS SIZE NATTCH
0x0d224dab 229391 postgres rw------- 56B 37
- Use column names appropriate to the resource.
--helpprints the available generic, System V, POSIX and resource-specific columns. - Add
--byteswhen a size must be expressed in bytes rather than a human-readable unit:
$ lsipc --shmems --bytes --output ID,SIZE,NATTCH
For machine consumption, --json gives JSON and --export gives key/value pairs. With export output, --shell changes column names to characters allowed in shell variable identifiers. Neither format makes the data permanent: the IPC state can change while you read it.
6. Inspect one object without changing it
First list the relevant System V resource and copy its numeric ID. Then combine --id with exactly one of --shmems, --queues or --semaphores:
$ lsipc --shmems --id RESOURCE_ID
$ lsipc --shmems --id 229391
Replace RESOURCE_ID with an ID from your own output. The first command is a template, not a value to paste unchanged. The ID may disappear between the listing and the detail query if its owner removes the object; that is a normal race, not evidence that lsipc altered it.
For POSIX resources, use --name with --posix-shmems, --posix-mqueues or --posix-semaphores:
$ lsipc --posix-mqueues --name /QUEUE_NAME
Quote a name if it contains shell metacharacters. Do not invent a leading slash or name from an application configuration; copy the exact name reported by the listing.
7. Diagnose misleading or failed output
Use lsipc --help when an option or column is rejected. Its exit status is 0 for success, 1 for incorrect arguments and 2 for a serious error. A successful command does not promise a consistent snapshot: active programs can create, remove or update IPC objects during the query.
If a report is too wide, --notruncate prevents truncation, while --raw removes table columnation. --noheadings removes the header, and --newline puts each piece of information on a separate line. Use these deliberately: a format that is easier to read interactively may be harder to parse reliably.
To add operation times, use --time. The manual distinguishes permission changes, message sends and receives, shared-memory attaches and detaches, and semaphore operations. Select --time-format=iso when an unambiguous date representation is more useful than the compact default.
Done means
- You recorded the installed
lsipcversion when the result needed provenance. - You checked global limits separately from per-object listings.
- You queried both the relevant System V or POSIX resource family instead of assuming they are interchangeable.
- Scripts name their expected columns or use JSON/export output rather than parsing the default table.
- You treated IDs and names as short-lived observations and did not use
lsipcas a removal or repair tool.