On a Linux system, what is /run for, and why does a daemon whose installation script does `mkdir /run/myservice` stop working after the first reboot?

## What /run is `/run` holds *runtime variable data* — information about the running system that is valid only for the lifetime of this boot. Typical contents: - **PID files**: `/run/sshd.pid` and friends, recording the process ID of a running daemon. - **Unix domain sockets**: the control and IPC endpoints daemons expose to local clients. - **Lock files**: `/run/lock`, previously `/var/lock`. - **Per-user runtime directories**: `/run/user/<uid>`, created for each logged-in user and pointed to by `XDG_RUNTIME_DIR`, mode 0700, torn down when the user's last session ends. - **Early-boot and system state** written by the service manager and by `udev`. It is mounted as a memory-backed filesystem, and it is empty at every boot. ## Why it exists as a separate directory Before `/run`, this data lived in `/var/run` and `/var/lock`. That created a bootstrapping problem: `/var` may be a separate filesystem, mounted comparatively late, possibly after services that already need somewhere to put a socket. `/run` was introduced to be available almost immediately, independent of the disk layout, and independent of whether `/var` is even writable — which matters for systems with a read-only or network-mounted `/var`. The compatibility path was kept: on current distributions `/var/run` is a symlink to `/run` and `/var/lock` a symlink to `/run/lock`, so software that still writes the old paths lands in the right place. ```sh findmnt /run # a memory-backed mount, not part of the root filesystem readlink -f /var/run # resolves to /run ``` ## Why the emptiness is the point Because the filesystem lives in memory, its contents cannot survive a restart — and this is a correctness property, not just an efficiency one. A PID file is a claim: "process N is me". After an unclean shutdown, a stale PID file on persistent storage claims a process ID that either no longer exists or, worse, now belongs to something else entirely. Startup logic that reads it and concludes "already running", or that sends a signal to that PID, is now wrong in a way that ranges from an annoying refusal to start to signalling an innocent process. Because `/run` is wiped by construction, that entire family of stale-state bugs is designed out. The same holds for leftover socket files, which would otherwise cause a bind failure on restart. ## Why `mkdir /run/myservice` at install time fails The installation script creates the directory on a filesystem that exists only until the machine restarts. On the next boot, `/run` is fresh and empty; `/run/myservice` is not there. The daemon then tries to create its PID file or socket in a directory that does not exist and fails at startup — typically with a not-found error and, confusingly, only ever *after a reboot*, never during testing on the machine where it was installed. There are also two related failure modes worth naming. If the daemon runs as an unprivileged user, it cannot create a directory directly under `/run` itself, because `/run` is root-owned — so "just have the daemon mkdir it" only works if the daemon still has privilege at that moment. And if the directory *is* created by whatever runs first, its owner and mode must be right, or the daemon drops privileges and then cannot write into its own runtime directory. ## The correct approach The directory must be declared as something the system creates **at every boot**, with an explicit owner, group and mode. Two standard mechanisms exist on systemd-based distributions: 1. **Let the service manager own it.** A unit can declare a runtime directory, which the manager creates with the specified ownership before the service starts and removes when it stops. This is the cleanest option because the lifetime matches the service exactly. 2. **Declare it in a `systemd-tmpfiles` configuration.** Packages ship a file under `/usr/lib/tmpfiles.d/` (administrators override under `/etc/tmpfiles.d/`) describing directories to create at boot, with mode and ownership. This is the right choice when the directory must exist independently of one particular unit. Either way, the packaging rule is: **anything under `/run` is declared, never installed.** A path that is created once is a path that exists exactly until the next reboot. ## The generalisation worth stating `/run` is the clearest example of the FHS's organising idea that a directory carries a *contract about lifetime*. `/usr` changes only on upgrade; `/etc` changes when an administrator edits it; `/var` persists across reboots; `/run` is defined to vanish. Software that treats them as interchangeable folders eventually breaks, and it breaks at boot — the least convenient moment and the hardest to reproduce from a shell on a machine that is already up.