Process Lifecycle (fork/exec/wait)

A containerized Python app starts failing with "fork: Resource temporarily unavailable" after running for a few days. Inside the container, ps shows hundreds of zombie processes. The app spawns subprocesses that crash, but never calls wait() to reap them.

Inside a container's PID namespace, there is no systemd or init to clean up orphans. Zombies accumulate silently, each consuming a PID slot, until the namespace limit (default 4096 PIDs) is exhausted and fork() fails for every new request. The app itself appears healthy -- it is the invisible dead children that are consuming all the PIDs.

Fix: use Docker's --init flag, which injects tini as PID 1 inside the container. Tini catches SIGCHLD and calls waitpid(-1, WNOHANG) in a loop, reaping every orphaned zombie automatically. It also forwards SIGTERM to the actual application, so docker stop triggers graceful shutdown instead of a SIGKILL after the 10-second timeout.

A busy Nginx instance serving 50,000 requests per second loses a worker to an OOM kill. Without a supervisor, that worker's share of capacity is gone -- requests queue up and latency spikes within milliseconds. Nobody notices until users start complaining.

The master process monitors all workers with waitpid(). When a worker dies from any cause -- segfault, OOM, or manual kill -- the master detects it within one event loop iteration through SIGCHLD delivery and forks an immediate replacement. No manual intervention, no capacity gap.

During config reload via SIGHUP, the same lifecycle applies: the master forks new workers with the updated nginx.conf and signals old workers to drain. Old workers finish in-flight requests (up to worker_shutdown_timeout seconds), then exit and get reaped. The entire reload happens with zero dropped connections.

A PostgreSQL server has 300 connections and max_connections set to 300. A backend crashes mid-transaction, but the connection count still shows 300. New clients get "too many connections" errors even though one slot should be free. The dead backend is lingering as a zombie, its shared memory slot still allocated.

The postmaster must reap dead backends immediately, but standard signals do not queue. If 5 backends crash simultaneously, only one SIGCHLD may be delivered. A single waitpid() call per signal misses the other 4, leaving zombie backends that inflate the connection count and hold shared memory slots hostage.

The postmaster's SIGCHLD handler calls waitpid(-1, WNOHANG) in a loop to reap every exited backend, not just one. It recycles each shared memory slot and logs the cause. If a critical process like the checkpointer or autovacuum launcher crashes, the postmaster forks a replacement within seconds, ensuring background maintenance never stalls.

A single-threaded Redis server holds a 20 GB dataset. It needs to write it to disk for persistence, but even 100 ms of blocking would cascade latency spikes through every dependent service. A blocking snapshot is not an option.

Redis fork()s a child process that inherits the entire dataset through COW pages. The child writes the RDB dump sequentially while the parent continues serving reads and writes at full speed. The critical lifecycle detail: the parent cannot call a blocking waitpid() or it would stall the event loop. Instead, Redis checks waitpid(WNOHANG) on every event loop iteration, polling for child completion without blocking.

The fork itself takes 1-25 ms depending on dataset size (proportional to page table entries, not data). Monitor this as latest_fork_usec in INFO output. When the child finishes, the parent atomically renames the temp file to dump.rdb -- a complete snapshot with zero client-visible pause.

A Go program calls fork() to spawn a helper process. The child immediately deadlocks on its first malloc call. No error, no panic -- just a process that hangs forever. The same code works perfectly when run as a standalone binary.

Go is always multithreaded. Even a trivial program has garbage collector threads, network poller threads, and scheduler threads running. When fork() copies only the calling thread, every mutex held by those other threads remains permanently locked in the child. Any operation requiring an internal lock -- malloc, file open, logging -- deadlocks instantly.

Go's os/exec package solves this with a combined ForkExec: fork() and execve() happen in a single atomic sequence, so the child replaces itself with the new program before any Go runtime code runs. The only code between fork and exec is a minimal assembly stub that sets up file descriptors and calls execve. Never use raw fork() in Go -- always go through os/exec.

A Node.js HTTP server is pinned at 100% on one core while 7 other cores sit completely idle. Throughput plateaus at 15,000 req/s no matter how much hardware is thrown at the problem. The single-threaded event loop cannot use more than one core.

The cluster module calls fork() to create one worker process per core. All workers inherit the master's listening socket file descriptor, so the kernel distributes incoming TCP connections across workers automatically. The master monitors each worker through SIGCHLD and waitpid() -- when a worker crashes from OOM, uncaught exception, or segfault, the master detects it within one event loop tick and forks a replacement.

Total throughput scales from 15,000 req/s on one core to over 100,000 req/s across 8 cores, with automatic recovery from worker failures. The fork/wait lifecycle gives Node.js multi-core scaling without rewriting a single line of application code.

Clicking "New Tab" should feel instant. But a fresh renderer process needs to load V8, ICU data, Blink, and shared libraries -- about 150 MB of code. Loading this from disk for every tab would add 200-500 ms of startup latency, making Chrome feel sluggish.

Chrome's zygote process pre-loads all shared libraries and V8 at browser launch, then fork()s to create each new renderer. COW means the new process shares all 150 MB of pre-loaded code without copying a single page. The renderer only allocates private memory for the specific page's DOM, JavaScript heap, and rendering buffers.

The browser process monitors all renderers via waitpid(). If a tab crashes from a segfault or OOM, the browser detects it immediately through the child's exit status and shows the "Aw, Snap!" page without affecting other tabs. The zygote pattern gives Chrome instant tab creation with full process isolation.

A git fetch runs on a repository with 15 remotes. Each network round-trip takes 200-500 ms. Done sequentially, that is 3-8 seconds of pure waiting. With --jobs=N, it should be parallel -- but how does Git manage 15 concurrent network operations and detect individual failures?

Git uses fork()+exec() to launch each transport helper (git-remote-https, git-credential-store, git-diff) as a separate child process. Each helper runs in its own isolated address space, so a crash in a credential helper cannot corrupt Git's index or object database. The parent collects each exit code via waitpid() to determine per-remote success or failure.

A single failed remote (exit code non-zero) is reported without aborting the others. This same fork+exec+wait pattern powers git-difftool (forking an external diff viewer per file) and git-filter-branch (forking a shell per commit). Process isolation turns concurrent networking into a safe, fault-tolerant operation.