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.

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
$ 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