A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
Each process has an environment consisting of environment variables, working directory, file descriptors, and resource limits. When a process exits, it returns an exit code (0 for success, non-zero for failure) that parent processes can retrieve via wait(). The parent must reap terminated children to prevent zombie processes from accumulating.
From your study of the process concept, you know that a process is more than just running code — it is an execution context with its own address space, register state, and kernel data structures. The process environment extends this idea: beyond the code and data in memory, every process carries a collection of settings and resources that shape how it interacts with the system. Understanding what makes up this environment is essential for writing programs that behave correctly across different contexts.
The environment includes several components. Environment variables are key-value string pairs — like `PATH`, `HOME`, and `USER` — that provide configuration without hardcoding values into programs. The current working directory determines how relative file paths are resolved. Open file descriptors define which files, pipes, and sockets the process can read from and write to — by default, every process inherits descriptors 0 (stdin), 1 (stdout), and 2 (stderr). Resource limits (set via `ulimit` or `setrlimit`) cap how much memory, CPU time, or how many files a process can use. When a process calls `fork()`, the child inherits a copy of this entire environment, which is how shells propagate configuration to the programs they launch.
Exit codes are the mechanism by which a process reports its outcome to its parent. When a process calls `exit(n)` or returns from `main`, the integer `n` becomes its exit status. The universal convention is that 0 means success and any non-zero value means failure, with different non-zero values sometimes indicating different failure modes (e.g., 1 for general errors, 2 for misuse of a command, 127 for command not found). The parent process retrieves this status by calling `wait()` or `waitpid()`, which blocks until a child terminates and then returns the child's exit code. Shell scripts use `$?` to check the exit code of the last command, and constructs like `&&` and `||` chain commands based on success or failure.
There is a subtle but important lifecycle issue: when a process terminates, the kernel cannot immediately discard all of its information, because the parent might not have called `wait()` yet. The terminated process enters a zombie state — its memory is freed and it is no longer running, but its process table entry persists, holding the exit code. The zombie exists solely so the parent can retrieve the exit status. If the parent calls `wait()`, the zombie is cleaned up (reaped). If the parent never calls `wait()` — because it is buggy or because it exited first — zombies accumulate. In the case where the parent exits first, the orphaned child is adopted by the `init` process (PID 1), which periodically reaps its adopted children. Long-running server processes that spawn many children must be diligent about reaping to avoid exhausting the process table with zombies.