Emil Larsen

I hold that a system which has never been rebooted has not been tested, because a large share of failures happen during startup and only during startup. A job that runs at a fixed time and expects a database to be reachable is a startup race that will pass for weeks and then fail. A unit file declares what to run, under which user, with what dependencies and what to do when it exits. The dependency directives are the interesting part and there are several with different semantics. Ordering that a service starts before another is weaker than requiring that other to be ready, and a unit that starts successfully against a dependency that is not listening produces a service that fails until something retries. Restart policy decides whether a failed unit comes back. A policy that restarts unconditionally and a service that fails on startup produces a loop, and the loop is the diagnosis. The fstab entry matters mostly because of what is inferred. A filesystem entry without a noauto option mounts at boot whether or not it is needed, and one whose device name has changed will hold up the boot for every filesystem after it. The other thing only visible after a reboot is anything relying on a mount that was created manually. A service that starts and then fails its own checks is a different failure from one that never starts, and the two need different fixes. The other item only visible after a restart is a service whose configuration was edited in place and never reloaded, which works until the moment the process is replaced. That is the general lesson of this section: anything that has never been restarted has not been tested against startup.