exit(3)

💖 exit(3) — the manual page, but make it make sense 💖

okay bestie, welcome to exit(3) from the Library Functions Manual. yes that's the whole title. we're doing process termination today and we're doing it cutely. 🎀

---

✨ NAME ✨

exit — cause normal process termination

like. the vibe check that ends the whole program. periodt. 💅

---

📚 LIBRARY 📚

Standard C library (libc, -lc) 🫶

---

🌸 SYNOPSIS 🌸

#include <stdlib.h>

[[noreturn]] void exit(int status);

so you include <stdlib.h>, and you call it with an int status. that's it. that's the whole summoning ritual. ✨

---

🦋 DESCRIPTION 🦋

okay so exit() causes normal process termination, and the least significant byte of status (aka status & 0xFF) gets handed back to the parent process — check out wait(2) for the receiving end of that. 💌

Every function you registered with atexit(3) and on_exit(3) gets called, in reverse order of registration. yes, reverse. last one in, first one out, it's giving stack energy fr fr.

and here's the spicy part — it is literally possible for one of those functions to call atexit(3) or on_exit(3) and register yet another function to run during exit processing, and that new registration gets added to the front of the list of functions still waiting to be called. chaotic? yes. legal? also yes. 😭

but if one of those functions doesn't return (like, it calls _exit(3), or it just kills itself with a signal), then none of the remaining functions get called, and further exit processing — especially the flushing of stdio(3) streams — is abandoned. gone. not happening. 💀

oh and if a function was registered multiple times with atexit(3) or on_exit(3), it gets called as many times as it was registered. equal treatment. no favoritism. 👑

All open stdio(3) streams get flushed and closed. Files created by tmpfile(3) get removed. clean up after yourself queen. 🧹

The C standard specifies two constants — <mint>EXIT_SUCCESS</mint> and <mint>EXIT_FAILURE</mint> — and you can pass those to exit() to say "successful termination" or "unsuccessful termination" respectively. use them. they're iconic. 🌈

---

💫 RETURN VALUE 💫

The exit() function does not return.

not "returns 0". not "returns NULL". it does not return. no return value era. she's gone. 🦋✨

---

🔥 ATTRIBUTES 🔥

for an explanation of the terms used in this section, go see attributes(7) bestie.

• Interface: exit()
• Attribute: Thread safety
• Value: MT-Unsafe race:exit

so basically: the exit() function uses a global variable that is not protected, which means it is not thread-safe. heads up if you're in your multithreaded girlboss era. 💅

---

⭐ STANDARDS ⭐

C11, POSIX.1-2008. certified. ✨

---

🎀 HISTORY 🎀

C89, POSIX.1-2001, SVr4, 4.3BSD. she's been around. she's got lore. 👑

---

💜 NOTES 💜

okay important stuff, pay attention:

The behavior is undefined if one of the functions registered using atexit(3) and on_exit(3) calls either exit() or longjmp(3). undefined. like, technically anything can happen. do not do this. 🙈

Also note that a call to execve(2) removes registrations created using atexit(3) and on_exit(3). bye registrations. ✌️

The use of EXIT_SUCCESS and EXIT_FAILURE is slightly more portable (to non-UNIX environments) than using 0 and some nonzero value like 1 or -1. In particular, VMS uses a different convention. so like, if you wanna be a global traveler with your code, use the constants. 🌍

BSD has attempted to standardize exit codes (and some C libraries, such as the GNU C library, have adopted that too) — see the file <sysexits.h>. 📄

After exit(), the exit status must be transmitted to the parent process. There are three cases:

1. If the parent has set SA_NOCLDWAIT, or has set the SIGCHLD handler to SIG_IGN, the status is discarded and the child dies immediately.
2. If the parent was waiting on the child, it is notified of the exit status and the child dies immediately.
3. Otherwise, the child becomes a "zombie" process: most of the process resources are recycled, but a slot containing minimal information about the child process (termination status, resource usage statistics) is retained in the process table. This allows the parent to subsequently use waitpid(2) (or similar) to learn the termination status of the child; at that point the zombie process slot is released. 🧟

If the implementation supports the SIGCHLD signal, this signal is sent to the parent. If the parent has set SA_NOCLDWAIT, it is undefined whether a SIGCHLD signal is sent.

🌊 Signals sent to other processes 🌊

If the exiting process is a session leader and its controlling terminal is the controlling terminal of the session, then every process in the foreground process group of this controlling terminal gets a SIGHUP signal, and the terminal is disassociated from this session — which lets it be acquired by a new controlling process. handing off the aux cord, basically. 🎧

If the exit of the process causes a process group to become orphaned, and if any member of the newly orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal will be sent to each process in this process group. See setpgid(2) for an explanation of orphaned process groups. 🫶

Except in the above cases — where the signalled processes may be children of the terminating process — termination of a process does not in general cause a signal to be sent to children of that process. However, a process can use the prctl(2) PR_SET_PDEATHSIG operation to arrange that it receives a signal if its parent terminates. so if you wanna know when mom leaves, there's a way. 😭

---

👀 SEE ALSO 👀

get_robust_list(2), exit(2), setpgid(2), wait(2), _exit(3), atexit(3), on_exit(3), tmpfile(3)

go read them. do it. iykyk. 📚✨

---

and that's the whole page bestie!! 🎀💖

this whole thing is from Linux man-pages 6.20, dated 2026-06-05 — that's the exit(3) page, and honestly? she ate. 💅🦋✨