FreeBSD System V IPC Operations: Inventory, Limits, and Cleanup

System V interprocess communication (IPC) remains important to some databases, compatibility workloads, and older software. FreeBSD exposes three related object families: shared-memory segments, semaphore sets, and message queues. They are kernel-managed objects with lifecycles that may outlast one process, so a restart can fix an application while leaving the resource that caused the failure behind.

The safe response to an IPC allocation error is not to remove every object or raise every limit. First identify the failing facility, owner, creator/last operator processes, and the application that owns the object. Then distinguish a genuinely stale object from a live object that is still attached or serving as a synchronization primitive. This guide covers host-level inventory, careful cleanup, kernel capability checks, and jail namespaces without attempting a security audit.

Recognize the three object types

Shared memory lets cooperating processes attach a region to their address spaces. It is often used for large data exchange or database buffer pools. A message queue stores typed messages for processes to send and receive; queued data consumes kernel accounting until the application drains or removes it. A semaphore set provides counters used to coordinate access and process ordering. A process may use one type or several, and the visible object count alone does not identify whether the application is healthy.

These objects are distinct from POSIX shared memory, POSIX named semaphores, pipes, sockets, and ordinary files. A Linux runbook that uses /dev/shm, ipcs, or ipcrm may describe different implementation details or flags. Use the local FreeBSD manual pages and record the operating-system release before changing anything.

freebsd-version -kru
ipcs
ipcs -m
ipcs -q
ipcs -s

With no selection flags, ipcs reports all active System V IPC facilities. -m, -q, and -s restrict the display to shared memory, queues, and semaphores. ipcs -a requests the maximum set of details supported by the utility, including owner/creator, process, and time information. Output is a snapshot of kernel structures and is not guaranteed to be transactionally consistent while objects are changing.

Diagnose allocation failures with evidence

Start from the application’s exact error and the relevant system calls or logs. ENOSPC-like resource exhaustion can indicate a count limit, per-object size, per-process attachment limit, message-size limit, or a leak. It does not prove that physical RAM is exhausted. Compare the application’s requested dimensions with the ipcs -b limits and the active counts, then inspect the corresponding kern.ipc values available on that release.

ipcs -a
ipcs -b
sysctl -a | grep '^kern\.ipc\.'

ipcs -b prints maximum allowed sizes for active objects as described by its manual; it is not a complete inventory of every kernel tunable. The kern.ipc tree varies by IPC family and release, and some limits are compile-time kernel options rather than writable runtime sysctls. Enumerate the live names before proposing a change. For compile-time option definitions, review the installed kernel configuration and the matching source tree’s sys/conf/NOTES; do not copy obsolete constants from a different FreeBSD release.

When an application reports a missing IPC facility or “function not implemented,” first verify that the relevant subsystem is present in the running kernel. FreeBSD kernel configuration distinguishes SYSVSHM, SYSVMSG, and SYSVSEM. Check the actual kernel config, available module state, release documentation, and boot messages before changing limits. A larger maximum cannot enable a subsystem absent from the running kernel.

Correlate ipcs -p output with process state and service restart time. A PID shown in an IPC listing may be a creator or last-operation process, not necessarily a complete ownership record or proof that the process still exists. Check the process table and service supervisor, review application logs, and ask the service owner whether the object is expected. Capture repeated snapshots during the failure; a single list can miss a rapidly created and removed queue.

Interpret object lifetimes before cleanup

An IPC identifier is not a temporary file name. Removing a live queue can discard queued messages. Removing a semaphore set can break a process that expects its coordination state to persist. Marking a shared-memory segment for removal does not necessarily free it immediately; it is destroyed after the last process detaches. The application’s own shutdown procedure is the safest cleanup mechanism because it can coordinate detach, flush, and restart behavior.

Use ipcrm only with an identifier independently verified in the current ipcs output. The type-specific forms are:

# Examples only; replace IDs only after owner and liveness verification.
ipcrm -m 12345
ipcrm -q 23456
ipcrm -s 34567

These commands are examples, not a cleanup script. The -m operation marks a shared-memory segment for removal and frees it after its final detach; the queue and semaphore operations remove their selected kernel objects. Do not use broad wipe options during incident response. Object identifiers can be reused after removal, so do not paste an old incident’s ID into a later cleanup.

Before removing anything, capture the ipcs record, current service state, owner, creator PID, last-operation PID, and corresponding application logs. Ask whether any process is expected to attach later or holds state across a restart. Stop the relevant service through its supported supervisor only after confirming blast radius, then check whether clean shutdown removes the object. If the object remains and all participants are stopped, a targeted ipcrm action may be justified. Re-list afterward and validate the application’s normal initialization path.

Understand limits without speculative tuning

System V IPC has distinct limits for object counts, per-object sizes, aggregate shared-memory pages, operations per semaphore call, and messages/bytes in queues. Increasing one value cannot resolve exhaustion in another. For example, a database that requests one large shared-memory segment can fail at a per-segment ceiling even when the total shared-memory pool has headroom; a semaphore-heavy application can exhaust set/element counts without large memory use.

Build a resource table from actual application requirements: facility, number of expected instances, object count per instance, maximum segment/queue size, concurrency, and lifecycle after restart. Compare measured peak counts and sizes to the live limits. Include temporary rolling-upgrade overlap if two instances may run simultaneously. Use vendor-supported FreeBSD guidance for any proposed limit change, and test in staging against the same kernel release and workload.

Do not paste Linux kernel.shmmax, kernel.shmall, or kernel.sem instructions into /etc/sysctl.conf and assume FreeBSD understands them. FreeBSD names and control mechanisms differ. sysctl -a is a discovery aid, not a promise that each listed variable is writable. If the matching release exposes a runtime tunable, record the existing value, test the proposed value, and define how it is persisted. If a build-time option is required, use the custom-kernel process and preserve a known-good kernel for boot recovery.

Measure host memory separately from IPC accounting. Shared-memory size may be reserved/attached in ways that do not correspond one-to-one with resident physical RAM, and message queue usage is not a process RSS number. Inspect vmstat, top, and the subsystem-specific counters along with ipcs; avoid summing shared mappings as if each process owned a separate full copy.

Account for jail IPC namespaces

System V IPC behavior inside a jail is controlled by per-facility jail parameters: sysvmsg, sysvsem, and sysvshm can be inherit, new, or disable. inherit exposes the host’s IPC namespace to that jail; new gives it a separate key namespace; disable makes the related system calls fail. The older allow.sysvipc setting is deprecated and equivalent to inheriting the host-wide IPC facilities. For a database or other workload that needs IPC isolation, use the current per-family settings documented by jail(8) and the Handbook, not a legacy flag copied from an old jail recipe.

Keep the namespace model in the diagnosis. A host-level ipcs inventory may not present every jail’s objects in the same way an in-jail process sees them. Record the jail name, parameters, host release, and commands run from the host or jail. If a service works on the host but fails in a jail, verify that the necessary facility is enabled in the intended namespace before changing global kernel capacities.

Changing jail IPC policy affects visibility and lifecycle, not merely a numeric limit. Existing objects may belong to a shared namespace or be invisible from the new namespace; changing inherit to new can alter what an application finds at startup. Plan a controlled service restart and validate that the correct objects are created in the correct namespace. Avoid widening jail capabilities or changing unrelated jail settings as a substitute for identifying the required IPC family.

Operational monitoring and recurring failure patterns

Record active object counts, maximum sizes, owner, creator and last-operation processes, and service restart timestamps. Alert on sustained proximity to a documented limit, unexpected growth across successive samples, objects owned by an account with no corresponding service, and a failed service initialization. A single count threshold is not enough: one large shared segment and hundreds of small queues have different implications.

Object count grows after each restart. Compare identifiers and timestamps across snapshots. The application may be creating new objects while old shared-memory segments remain attached or marked for removal. Verify the documented application shutdown behavior and do not delete objects just because their creator PID is gone.

Only a jailed service fails. Compare jail parameters and namespace visibility, confirm that the relevant system calls exist in the running kernel, and inspect from both host and jail contexts. Changing a host-wide limit does not necessarily repair a disabled jail facility.

Capacity appears sufficient but creation still fails. Identify the specific facility and error, inspect per-object versus aggregate limits, and compare request size/count to the exact live value. Do not infer from total ipcs memory alone.

Objects seem stale but belong to a database. Check the database’s own status and recovery guide. An IPC object can be part of an active shared-memory architecture even if its name is opaque. Use the service’s supported shutdown/recovery path and obtain an application-consistent backup before destructive action.

For long-running systems, collect a time series rather than relying on periodic manual commands. A lightweight monitoring script can parse a stable machine-readable format if the installed utility supports one; validate parser behavior across upgrades and do not scrape human-oriented columns without pinning locale and release assumptions. Keep raw samples for incident review and rotate them appropriately.

Close the loop with an acceptance test

After a tuning or cleanup change, verify that the application starts, allocates the expected IPC objects, serves its health check, and shuts down cleanly. Compare the new ipcs inventory against the baseline and confirm object counts plateau under representative load rather than increasing indefinitely. If limits changed, test the failure boundary in staging or a controlled workload rather than waiting for production exhaustion.

Document the application’s IPC dependencies, the matching kernel capability, any release-specific tunables, jail namespace settings, owner, expected steady-state object count, and cleanup procedure. Define who may approve ipcrm, which service commands safely remove each object, and what logs prove a successful restart. System V IPC is operationally manageable when object identity and lifetime are observable; the right fix follows the failing resource and its owner, not a blanket cleanup command.

Related:

Sources: