Classic Unix daemons double-forked and wrote a PID file, while a modern service manager supervises the process directly as its own child. What concrete failure modes does the PID-file model have that direct supervision removes?

## What double-forking was actually for On a classic Unix system, a program started from a shell inherits that shell's session and controlling terminal. If the terminal goes away, the process group gets `SIGHUP`. A long-running daemon must escape that, so the traditional daemonisation dance is: `fork()`, let the parent exit so the shell's prompt returns; call `setsid()` in the child to become a session leader with no controlling terminal; `fork()` a second time so the final process is not a session leader and can therefore never acquire a terminal; then `chdir("/")`, reset the umask, and close or redirect the standard file descriptors. The surviving process is orphaned and reparented to PID 1. This is a perfectly sensible answer to the terminal problem. The trouble is what it does to *management*. ## The PID-file contract Because the daemon has run away from whoever launched it, some other channel is needed to identify it. The convention became a file, typically under `/run` (historically `/var/run`), containing the decimal PID and a newline. The init script writes or reads it; `stop` means read the number and send a signal to it. Notice what this contract is: the process reports its own identity, at a time of its own choosing, into a mutable file, and everyone else trusts it. ## Failure mode 1 — the start race The daemon writes the PID file at some point after it starts; nothing defines when. A start script that returns immediately may report success before the service is listening, and a health check that reads the file may find it absent or half-written. There is also no way to distinguish "still starting" from "failed during startup", because the only signal is the presence of a file. ## Failure mode 2 — staleness and PID reuse If the daemon is killed with `SIGKILL`, or the machine loses power, the file survives with a dead PID in it. Two bad outcomes follow. The benign one: the start path sees the file, concludes the service is already running, and refuses to start — the service stays down while the tooling insists it is up. The dangerous one: PIDs are recycled, so by the time anyone reads that file the number may belong to a completely unrelated process. A stop path that blindly signals it kills the wrong thing. Careful scripts try to mitigate this by comparing `/proc/<pid>/comm` or the cmdline against an expected name, but that is a heuristic bolted onto a broken premise, and it is still racy. ## Failure mode 3 — the forgotten children Only one PID is recorded. A daemon that forks worker processes, or spawns helpers, leaves those entirely outside the model. Stopping the service signals the recorded PID and leaves the workers running — holding ports, holding file locks, still writing to the database. The next start then fails with an address-already-in-use error whose cause is invisible from the PID file alone. ## Failure mode 4 — no exit status This is the deepest one. In Unix, only a process's parent can reap it and learn its exit status via `wait()`. Because the daemon deliberately made itself an orphan, the manager is not its parent, so it cannot be told when the service dies, cannot learn whether it exited cleanly or was killed, and cannot see which signal killed it. All it can do is poll: check periodically whether the PID still exists. Polling is late by construction and blind to the reason. ## How direct supervision fixes each one A modern service manager inverts the arrangement. The service is asked *not* to daemonise — it stays in the foreground, and the manager keeps it as a direct child. - Being the parent, the manager receives `SIGCHLD` the instant the process dies and can `wait()` for the exact status, distinguishing exit code 1 from death by `SIGKILL`. Restart policies become meaningful because the trigger is exact and immediate. - Every process of the service is placed in a per-service cgroup, so membership is a kernel fact rather than a self-report. Stopping the service means signalling the whole cgroup, which catches forked children no matter how they were spawned, and no PID-reuse mistake is possible because the cgroup, not a recycled number, defines membership. - Readiness gets a real channel. Under systemd, a service can call `sd_notify(3)` to send `READY=1` when it is genuinely serving, so "started" means started rather than "the file appeared". Socket activation goes further: the manager holds the listening socket, so it is ready before the service is. - Standard output and error are captured by the manager instead of the daemon inventing its own log handling. ## Where PID files still appear Compatibility remains: systemd supports `Type=forking` together with `PIDFile=`, for software that genuinely cannot run in the foreground. It is explicitly the fallback — the manager has to guess which process is the main one, and everything above still applies to that guess. Cgroup tracking still catches the strays, which is why even a badly behaved legacy daemon is more manageable under systemd than under an rc script. But when you control the software, running in the foreground and letting the supervisor be the parent is strictly better. ## Interview framing This question is a good discriminator because both models are simple to describe and the difference only becomes vivid if you have been burned. Concrete war stories — a stale PID file that made a restart script kill an unrelated process, or worker processes surviving a stop and blocking the next start — are worth more than a taxonomy.