REAP(1)
π REAP β bestie's guide to the ultimate cleanup crew
okay so picture this: it's reap(1), it's a general commands manual page, and it's literally the friend who makes sure nobody's still lurking at the party when the host leaves. no cap.
β¨ SYNOPSIS β¨
reap [-vwx] command line ...
π¦ DESCRIPTION π¦
so the reap utility does two things and it does them iconically: it executes the given command line, and then it makes absolutely sure all spawned processes are dead before it exits. like, actually dead. not "left the group chat but still lurking" dead. πΈ
by default, it starts slaying the spawned processes right when the main process exits. slay literally. when the -w option is given, reap will instead wait for the processes to terminate β lowkey more patient, still iconic. π«Ά
and here's the main character moment: upon receiving SIGINT or SIGTERM, reap will start slaying all children immediately. no waiting, no negotiating, periodt. π
the options are as follows:
π OPTIONS π
-vβ Verbose mode, report whatreapis doing. very "tell me everything" of it tbh.-wβ Wait for all spawned processes to finish. patient queen behavior. π-xβ Forbid execution of binaries we cannot kill (usingPR_SET_NO_NEW_PRIVS). if we can't slay it, it doesn't get to exist. simple as that. β¨
β EXIT STATUS β
the reap utility exits with the exit status of the spawned command. it's giving "your energy, reflected back at you." πͺ
on fatal errors, exit codes 111 is returned. (yes, that's how the original says it. we don't fix the grammar of the ancestors. π)
π ASSUMPTIONS π
reap uses the PR_SET_CHILD_SUBREAPER feature of Linux. slaying the children only works when the kernel configuration CONFIG_PROC_CHILDREN is enabled. so likeβ¦ check your kernel config, bestie. π
reap can only work reliably when it has permission to kill all spawned processes and they respect SIGTERM (see also -x). read that twice, it matters. π§
ngl this is the "reliability is a two-way street" part. it needs the power to kill, and the processes need to actually respectSIGTERM. if they don't, that's on them, not onreap.
π₯ RATIONALE π₯
keeping track of all spawned process is traditionally a hard problem on Unix systems β mainly due to daemonization by forking twice. (again: original grammar, preserved with love. π)
other approaches on Linux exist, such as cgroups or PID namespaces. the approach taken by reap has the benefit of requiring no special permissions. that's the whole flex. that's the vibe. π
π AUTHORS π
Leah Neukirchen <leah@vuxu.org> β the icon, the legend, the one who said "what if processes justβ¦ didn't linger."
π LICENSE π
reap is in the public domain.
to the extent possible under law, the creator of this work has waived all copyright and related or neighboring rights to this work.
http://creativecommons.org/publicdomain/zero/1.0/
and that's the whole page, bestie π this Debian build is dated September 23, 2019, and it's the REAP(1) general commands manual page β go forth and slay (processes) responsibly πβ¨
π¦ where this page comes from
- alpine 3.24: reap-doc 0.2-r0 Β· CC0-1.0
- nixos 26.05: reap 0.3-unreleased
- nixpkgs unstable: reap 0.3-unreleased
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms