ipcmk
Create System V inter-process communication (IPC) resources
TLDR
Create a shared memory segment
Create a semaphore
Create a message queue
Create a shared memory segment with specific permissions (default is 0644)
SYNOPSIS
ipcmk { -M shmkey | -Q msgkey | -S semkey } [-p mode]
ipcmk -P pathname { -M | -Q | -S } [-p mode]
PARAMETERS
-M shmkey
Create a shared memory segment using shmkey. If shmkey is 0 (IPC_PRIVATE), a new, unique key is generated.
-Q msgkey
Create a message queue using msgkey. If msgkey is 0 (IPC_PRIVATE), a new, unique key is generated.
-S semkey
Create a semaphore array using semkey. If semkey is 0 (IPC_PRIVATE), a new, unique key is generated.
-P pathname
Generate an IPC key using `ftok(3)` from the specified pathname. This option is mutually exclusive with directly providing shmkey, msgkey, or semkey (i.e., using a non-zero key directly with -M, -Q, or -S).
-p mode
Set the access permissions for the newly created IPC object. mode should be an octal number, similar to `chmod(1)`. The default permissions are typically 0600 (read/write for owner only).
DESCRIPTION
ipcmk is a command-line utility used to create new System V Inter-Process Communication (IPC) objects.
These objects include shared memory segments, message queues, and semaphore arrays. It serves as a low-level tool primarily for testing IPC mechanisms, debugging applications that rely on System V IPC, or for quickly setting up an IPC resource without the need to write custom C code. Users can specify the type of object to create, its unique key, and its access permissions. Creating IPC objects typically requires appropriate system permissions (e.g., root privileges or belonging to a specific user/group) as these are system-wide resources.
CAVEATS
Creation of IPC objects typically requires root privileges or appropriate permissions for the calling user/group.
System V IPC objects persist in the kernel even after the creating process exits. They are only removed explicitly (e.g., using `ipcrm(1)`) or upon system reboot. Unmanaged objects can lead to resource exhaustion.
When using `ftok(3)` via -P, the specified pathname must exist and be accessible to `ftok` to generate a valid key.
IPC keys are system-wide. Conflicts can occur if a key is chosen that is already in use by another application. Using IPC_PRIVATE (key 0) or `ftok(3)` helps to mitigate key conflicts.
<I>IPC KEYS EXPLAINED</I>
System V IPC objects are identified by a unique integer key. Processes use this key to gain access to or attach to the same IPC object. Keys can be explicitly specified (e.g., a specific integer), generated using `ftok(3)` from a pathname and a project ID, or automatically assigned by the system if `IPC_PRIVATE` (value 0) is used. Using `IPC_PRIVATE` is generally safer for temporary or single-instance objects as it guarantees a unique key and avoids potential conflicts.
<I>OBJECT PERSISTENCE</I>
A critical characteristic of System V IPC objects is their persistence. Unlike typical process-specific resources like file descriptors or stack memory, IPC objects reside in the kernel's memory and persist even after the creating process terminates. They remain available for other processes to use until explicitly removed using `ipcrm(1)` or until the system is rebooted. This persistence is fundamental for inter-process communication but also necessitates careful management to prevent resource leaks and potential system resource exhaustion.
HISTORY
ipcmk is an integral part of the System V Inter-Process Communication (IPC) suite, which originates from AT&T System V Unix, dating back to the early 1980s. Alongside `ipcs` (to display IPC status) and `ipcrm` (to remove IPC objects), it forms the basic set of utilities for managing System V IPC resources. These commands have been a standard feature on Unix-like operating systems for decades and are typically provided by the `util-linux` package on modern Linux distributions.