getpid(2)

💖 getpid(2) — the system calls manual, but make it cute 💖

okay bestie, welcome to the System Calls Manual page for getpid and getppid, aka the two tiny little functions that tell a process who it is and who made it. it's giving "find your birth certificate but for your own PID" 🍼✨

---

🌸 NAME 🌸

getpid, getppid — get process identification 🆔

---

📚 LIBRARY 📚

Standard C library (libc, -lc). the classic. the icon. the one your linker already links against, no cap 💅

---

✨ SYNOPSIS ✨

#include <unistd.h>

pid_t getpid(void);
pid_t getppid(void);

that's it. two lines. no arguments. no drama. literally the least demanding functions in the whole syscall universe 🫶

---

🦋 DESCRIPTION 🦋

okay so, getpid() returns the process ID (PID) of the calling process. that's it, that's the whole thing. and just so you know, this is often used by routines that generate unique temporary filenames — so if you've ever written a temp file helper, this is basically your backbone, bestie. iykyk 🎀

and then getppid() returns the process ID of the parent of the calling process. and here's the tea: the "parent" here is either the ID of the process that created this process using fork(), or — and this is the part where things get a lil spicy 🌶️ — if that process has already terminated, it returns the ID of the process to which this process has been reparented. and that reparenting target is either init(1) or a "subreaper" process defined via the prctl(2) PR_SET_CHILD_SUBREAPER operation. so like, your parent can change and that's valid, we support reparenting in this house 👑✨

---

😭 ERRORS 😭

these functions are always successful. no errors. not even one. not even a little one. they simply cannot fail. the way that a syscall can just be perfect and unproblematic... obsessed 💀💖

---

🌈 VERSIONS 🌈

so on Alpha, instead of having a whole pair of getpid() and getppid() system calls, there's a single getxpid() system call that returns a pair of PID and parent PID. it's giving two-for-one deal 🎉

and the glibc getpid() and getppid() wrapper functions transparently deal with this — so you never even notice. if you wanna know about register mapping details, go peek at syscall(2). yes, register mapping. yes it's deeply nerdy. yes we love it 🧚

---

📜 STANDARDS 📜

POSIX.1-2024. certified. ratified. slay ⭐

---

💜 HISTORY 💜

4.3BSD, SVr4, POSIX.1-1988. ancient. legendary. still standing. periodt 💅

🧠 C library/kernel differences 🧠

okay so buckle up bestie, this is the ancestral drama section and it is juicy 🍓

from glibc 2.3.4 up to and including glibc 2.24, the glibc wrapper function for getpid() cached PIDs, with the goal of avoiding additional system calls when a process calls getpid() repeatedly. makes sense, right? efficiency girlie 💫

normally this caching was invisible. normally. but its correct operation relied on support in the wrapper functions for fork(2), vfork(2), and clone(2). so if an application bypassed the glibc wrappers for these system calls by using syscall(2), then a call to getpid() in the child would return the wrong value — to be precise: it would return the PID of the parent process 😭

and it gets worse. there were cases where getpid() could return the wrong value even when invoking clone(2) via the glibc wrapper function. (for a discussion of one such case, see BUGS in clone(2).) furthermore, the complexity of the caching code had been the source of a few bugs within glibc over the years. so like... the cache was lowkey a menace 💀

and because of the aforementioned problems, since glibc 2.25, the PID cache is removed: calls to getpid() always invoke the actual system call, rather than returning a cached value. the cache got cancelled. we do not miss her. main character behavior honestly 👑

bestie please internalise this one: if you're on old glibc (< 2.25) and you're raw-dogging syscall(2) for fork/vfork/clone, your child's getpid() might be lying to your face. that's not a vibe. that's a bug 🙈

---

📝 NOTES 📝

if the caller's parent is in a different PID namespace (see pid_namespaces(7)), getppid() returns 0. zero. nada. no parent for you in this namespace, bestie, go touch grass 🧚

also, from a kernel perspective, the PID (which is shared by all of the threads in a multithreaded process) is sometimes also known as the thread group ID (TGID). this contrasts with the kernel thread ID (TID), which is unique for each thread. for further details, see gettid(2) and the discussion of the CLONE_THREAD flag in clone(2). so like, PID = the whole group chat, TID = the individual member. TGID is literally the group chat name 🌸

---

👀 SEE ALSO 👀

clone(2), fork(2), gettid(2), kill(2), exec(3), mkstemp(3), tempnam(3), tmpfile(3), tmpnam(3), credentials(7), pid_namespaces(7)

go read them. not me being a bad influence and giving you eleven more manpages to read 📚✨

---

and that's the whole page, bestie!! this was Linux man-pages 6.20, dated 2026-02-08 🎀 thanks for reading all the way to the bottom, you're literally the best, go get your PID and feel something 🫶💖