Read System V IPC Objects Safely from /proc/sysvipc

A leaked shared memory segment can sit around for months, and /proc/sysvipc shows exactly what IPC objects the kernel currently holds. This inspects message queues, semaphore arrays and shared memory segments, and compares the raw proc view with ipcs. The whole workflow is read-only: nothing here removes an object or touches a service.

Allow about ten minutes. You need a shell on Linux with the proc filesystem mounted. The examples use the local proc_sysvipc(5) from the Linux man-pages 6.7 package, installed here as package version 6.7-2. Object lists are live, so your output will differ from the examples.

1. Check that the proc directory is available

Start with ordinary, unprivileged inspection. The directory should contain three pseudo-files:

$ ls -l /proc/sysvipc
total 0
-r--r--r-- 1 root root 0 ... msg
-r--r--r-- 1 root root 0 ... sem
-r--r--r-- 1 root root 0 ... shm

Timestamps and ownership details are host-specific. What matters is the presence of msg, sem and shm. Their apparent size is normally zero because these are proc pseudo-files, not ordinary files holding a stored report.

$ test -r /proc/sysvipc/msg && test -r /proc/sysvipc/sem && test -r /proc/sysvipc/shm && echo 'proc sysvipc is readable'
proc sysvipc is readable

2. Read the message queue, semaphore and shared memory views

Each pseudo-file has a header followed by one line per object currently present. Read the first few lines from each:

$ for kind in msg sem shm; do
    echo "--- $kind ---"
    sed -n '1,6p' "/proc/sysvipc/$kind"
  done
--- msg ---
       key      msqid perms      cbytes       qnum lspid lrpid   uid   gid  cuid  cgid      stime      rtime      ctime
--- sem ---
       key      semid perms      nsems   uid   gid  cuid  cgid      otime      ctime
--- shm ---
       key      shmid perms                  size  cpid  lpid nattch   uid   gid  cuid  cgid      atime      dtime      ctime                   rss                  swap

• The headers are part of the interface. They make the columns self-describing, so use them rather than counting positions.
• qnum and cbytes describe the message view. qnum is the number of messages, cbytes the current byte count.
• size and nattch describe the shared memory view. size is the segment size, nattch the current attachment count.
• Never copy a column position between files. The three formats are different.

A header with no following line means that type is currently empty. That is a valid state, not a read failure.

3. Count objects without losing the header

To count live entries, subtract the one header line from the line count. This reads each pseudo-file once and keeps the calculation explicit:

$ for kind in msg sem shm; do
    lines=$(wc -l < "/proc/sysvipc/$kind")
    printf '%s objects: %s\n' "$kind" "$((lines - 1))"
  done
msg objects: 0
sem objects: 0
shm objects: 1

This sample reflects one moment on this machine. A process can create or remove an object between reads, so the three counts are not a transactionally consistent snapshot. Use them for a quick inventory, not for a race-free allocation decision.

4. Interpret a shared memory row carefully

Shared memory is often where a reader mistakes a live row for a configuration record. Show the header beside any rows:

$ { head -n 1 /proc/sysvipc/shm; tail -n +2 /proc/sysvipc/shm; }
       key      shmid perms                  size  cpid  lpid nattch   uid   gid  cuid  cgid      atime      dtime      ctime                   rss                  swap
 220351915     229391   600                    56 3097710 421401     36   113   114   113   114 1790433265 1790433265 1790054049                     0                  4096

Values such as shmid, process IDs, user and group IDs, attachment counts and timestamps describe the current object. They are not instructions for creating or editing it. The key can be zero or a numeric value, and an object identifier is not the same thing as a pathname.

Do not infer that an object is unused from one field alone: nattch describes current attachments, while ownership, permissions and the creating process add other context. If a row looks unexpected, identify the owning service before taking any administrative action.

5. Compare the proc view with ipcs

The manpage describes these files as providing information similar to ipcs(1). If ipcs is installed, compare its read-only report with the corresponding proc file:

$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0d224dab 229391     postgres   600        56         36

The presentation differs. ipcs translates some fields into labels and hexadecimal keys, while /proc/sysvipc/shm exposes a wider, column-oriented row. Compare the identifier, permissions, size, owner IDs and attachment count rather than expecting byte-for-byte identical output.

Use ipcs -q for message queues and ipcs -s for semaphore arrays. If ipcs is missing, the proc files remain the kernel-facing inspection point described by proc_sysvipc(5); do not install a package or change the system merely to make the display look familiar.

6. Keep inspection separate from removal

If an object genuinely must be removed, record its identifier and owning service first, check the service documentation, and arrange a recovery or maintenance window. The examples in this guide deliberately give no destructive command. There is no undo for a removal that has already disrupted a process, so preserve the raw output for diagnosis before escalating.

For a repeatable read-only capture, save to a new file rather than overwriting an existing report:

$ stamp=$(date +%Y%m%d-%H%M%S)
$ out="sysvipc-$stamp.txt"
$ {
    date --iso-8601=seconds
    for kind in msg sem shm; do
      echo "--- /proc/sysvipc/$kind ---"
      cat "/proc/sysvipc/$kind"
    done
  } > "$out"
$ test -s "$out" && echo "saved $out"
saved sysvipc-20260926-153300.txt

The timestamp in the sample is illustrative. Keep the capture's permissions appropriate for the host: these rows can reveal IDs, process relationships and resource use. Remove an unneeded report through your normal records-handling process, after checking it is not needed for an incident or audit.