Read System V IPC Objects Safely from /proc/sysvipc

You will inspect the System V IPC objects currently visible to the kernel, identify whether they are message queues, semaphore arrays or shared memory segments, and compare the raw proc view with ipcs. The workflow is read-only: it does not remove an IPC object or change 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

The timestamps and ownership details are host-specific. The useful result is the presence of msg, sem and shm. Their apparent size is normally zero because these are proc pseudo-files, not ordinary files containing a stored report.

Checkpoint: verify the mount and the three names without changing anything:

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

$ 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 and make the columns self-describing. In the message view, for example, qnum is the number of messages and cbytes is the current byte count. In the shared memory view, size is the segment size, while nattch is the number of current attachments. Do not copy a column position from one file to another: the three formats are different.

A header with no following object 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 the live entries, subtract the one header line from the line count. This command 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

The sample result 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.

Checkpoint: if a count is negative, the file was not in the expected format or the header was absent. Stop and inspect the raw file rather than silently accepting the result.

4. Interpret a shared memory row carefully

Shared memory is often the first place 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. For example, nattch describes current attachments, while ownership, permissions and the creating process provide 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 is different. 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

Reading these files does not remove an IPC object. Conversely, commands that remove queues, semaphore arrays or shared memory can interrupt applications and may discard in-flight state. Do not add a removal command to an inventory script, and do not treat a stale-looking row as permission to delete it.

If an object must be removed, first record its identifier and owning service, check the service documentation, and arrange a recovery or maintenance window. The examples in this guide deliberately provide no destructive command. There is no undo operation 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 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 that it is not required for an incident or audit.