shmget(2)

✨ shmget(2) — allocating System V shared memory segments, bestie ✨

Okay so before we even start: this is the man page for shmget, living in section 2 of the manual (aka the system calls section — the main character section, honestly 👑). It comes to you courtesy of the Standard C library (libc, link it with -lc). Buckle up, we're doing shared memory today and it's gonna be cute. 🎀

---

🌸 NAME 🌸

shmget — allocates a System V shared memory segment. That's it, that's the whole job. 💅

---

📚 LIBRARY 📚

Standard C library (libc, -lc).

---

🦋 SYNOPSIS 🦋

#include <sys/shm.h>

int shmget(key_t key, size_t size, int shmflg);

---

💖 DESCRIPTION 💖

So like. shmget() hands you back the identifier of the System V shared memory segment that's associated with whatever value key has. Think of it like a little name tag 🏷️ for a chunk of memory that multiple processes can vibe with at the same time.

You can use it in two directions, no cap:

• to grab the identifier of a shared memory segment that already exists — this happens when shmflg is zero and key does not have the value IPC_PRIVATE
• or to create a whole new set. ✨

Here's the tea on creation: a brand new shared memory segment gets created — with a size equal to the value of size rounded up to a multiple of PAGE_SIZE — if:

• key has the value IPC_PRIVATE, or
• key isn't IPC_PRIVATE, and no shared memory segment corresponding to key exists, and IPC_CREAT is specified in shmflg.

And now the spicy one: if shmflg specifies both IPC_CREAT and IPC_EXCL, and a shared memory segment already exists for key, then shmget() fails and sets errno to EEXIST. It's giving very much the same energy as O_CREAT | O_EXCL for open(2). 🫶

The value of shmflg is composed of all this:

• IPC_CREAT — creates a new segment. If you don't use this flag, then shmget() will go find the segment associated with key and check whether the user actually has permission to access that segment. (Vibe check at the door 🚪)
• IPC_EXCL — this flag is used with IPC_CREAT to make sure this call is the one that creates the segment. If the segment already exists, the call fails. Periodt.
• SHM_HUGETLB (since Linux 2.6) — allocate the segment using "huge" pages. For further info, go peek at the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst.
• SHM_HUGE_2MB, SHM_HUGE_1GB (since Linux 3.8) — used together with SHM_HUGETLB to pick alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset SHM_HUGE_SHIFT. So the two constants above are literally defined as:

#define SHM_HUGE_2MB    (21 << SHM_HUGE_SHIFT)
#define SHM_HUGE_1GB    (30 << SHM_HUGE_SHIFT)

For a few extra details, check the discussion of the similarly named constants in mmap(2).

• SHM_NORESERVE (since Linux 2.6.15) — this flag does the exact same job as the MAP_NORESERVE flag from mmap(2). It says: do not reserve swap space for this segment. Here's why that matters — when swap space is reserved, you have a guarantee that it's possible to modify the segment. When swap space is not reserved, you might get a SIGSEGV upon a write if no physical memory is available. 😭 Also see the discussion of the file /proc/sys/vm/overcommit_memory in proc_sys_vm(5).

On top of all those flags, the least significant 9 bits of shmflg specify the permissions granted to the owner, group, and others. These bits have the same format and the same meaning as the mode argument of open(2). Presently, execute permissions are not used by the system. (So those bits are just out here being decorative ngl 🙈)

When a new shared memory segment gets created, its contents are initialized to zero values, and its associated data structure, shmid_ds (see shmctl(2)), is initialized like this:

• shm_perm.cuid and shm_perm.uid are set to the effective user ID of the calling process.
• shm_perm.cgid and shm_perm.gid are set to the effective group ID of the calling process.
• The least significant 9 bits of shm_perm.mode are set to the least significant 9 bit of shmflg.
• shm_segsz is set to the value of size.
• shm_lpid, shm_nattch, shm_atime, and shm_dtime are set to 0.
• shm_ctime is set to the current time.

If the shared memory segment already exists, the permissions get verified, and a check is made to see whether it's marked for destruction. 👀

---

🎀 RETURN VALUE 🎀

• On success: a valid shared memory identifier is returned. Slay. ✨
• On error: -1 is returned, and errno is set to indicate the error. 💀

---

💀 ERRORS 💀

• EACCES — the user does not have permission to access the shared memory segment, and does not have the CAP_IPC_OWNER capability in the user namespace that governs its IPC namespace.
• EEXIST — IPC_CREAT and IPC_EXCL were specified in shmflg, but a shared memory segment already exists for key. (Tried to create, but she was already there. 😭)
• EINVAL — a new segment was to be created and size is less than SHMMIN or greater than SHMMAX.
• EINVAL — a segment for the given key exists, but size is greater than the size of that segment.
• ENFILE — the system-wide limit on the total number of open files has been reached.
• ENOENT — no segment exists for the given key, and IPC_CREAT was not specified.
• ENOMEM — no memory could be allocated for segment overhead.
• ENOSPC — all possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
• EPERM — the SHM_HUGETLB flag was specified, but the caller was not privileged (did not have the CAP_IPC_LOCK capability) and is not a member of the hugetlb_shm_group group; see the description of /proc/sys/vm/hugetlb_shm_group in proc_sys_vm(5).

---

🌈 STANDARDS 🌈

POSIX.1-2024.

SHM_HUGETLB and SHM_NORESERVE are Linux extensions. 🐧

---

🦕 HISTORY 🦕

POSIX.1-2001, SVr4. She's been around. An icon, honestly. 💅

---

📝 NOTES 📝

Plot twist bestie: IPC_PRIVATE isn't a flag field, it's a key_t type. If you use this special value for key, the system call ignores all but the least significant 9 bits of shmflg and creates a new shared memory segment. 🫶

🌸 Shared memory limits 🌸

These limits on shared memory segment resources affect the shmget() call:

• SHMALL — system-wide limit on the total amount of shared memory, measured in units of the system page size.

On Linux, this limit can be read and modified via /proc/sys/kernel/shmall. Since Linux 3.16, the default value for this limit is:

ULONG_MAX - 2^24

The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. This value, rather than ULONG_MAX, was chosen as the default to prevent some cases where historical applications simply raised the existing limit without first checking its current value. Such applications would cause the value to overflow if the limit was set at ULONG_MAX.

From Linux 2.4 up to Linux 3.15, the default value for this limit was:

SHMMAX / PAGE_SIZE * (SHMMNI / 16)

If SHMMAX and SHMMNI were not modified, then multiplying the result of this formula by the page size (to get a value in bytes) yielded a value of 8 GB as the limit on the total memory used by all shared memory segments.

• SHMMAX — maximum size in bytes for a shared memory segment.

On Linux, this limit can be read and modified via /proc/sys/kernel/shmmax. Since Linux 3.16, the default value for this limit is:

ULONG_MAX - 2^24

The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. See the description of SHMALL for a discussion of why this default value (rather than ULONG_MAX) is used.

From Linux 2.2 up to Linux 3.15, the default value of this limit was 0x2000000 (32 MiB).

Because it is not possible to map just part of a shared memory segment, the amount of virtual memory places another limit on the maximum size of a usable segment: for example, on i386 the largest segments that can be mapped have a size of around 2.8 GB, and on x86-64 the limit is around 127 TB. 🫠

• SHMMIN — minimum size in bytes for a shared memory segment: implementation dependent (currently 1 byte, though PAGE_SIZE is the effective minimum size).
• SHMMNI — system-wide limit on the number of shared memory segments. In Linux 2.2, the default value for this limit was 128; since Linux 2.4, the default value is 4096.

On Linux, this limit can be read and modified via /proc/sys/kernel/shmmni.

The implementation has no specific limits for the per-process maximum number of shared memory segments (SHMSEG).

🐧 Linux notes 🐧

Until Linux 2.3.30, Linux would return EIDRM for a shmget() on a shared memory segment scheduled for deletion. (Throwback behavior fr fr.)

---

🐛 BUGS 🐛

The name choice IPC_PRIVATE was perhaps unfortunate — IPC_NEW would more clearly show its function. Not me defending the naming committee... I can't. 💀

---

🍓 EXAMPLES 🍓

See shmop(2).

---

👀 SEE ALSO 👀

• memfd_create(2)
• shmat(2)
• shmctl(2)
• shmdt(2)
• ftok(3)
• capabilities(7)
• shm_overview(7)
• sysvipc(7)

---

Go forth and share your memory responsibly, bestie. Segments marked for destruction are not a vibe. 💖

Anyways that's the whole page!! This one's from Linux man-pages 6.20, dated 2026-02-08 — bookmark it, screenshot it, tell your group chat about it. Byeeeee 🦋✨🎀