On a traditional SysV-init system, how did init decide which services to run when it entered runlevel 3, and what determined the order they ran in?

## The dispatch: inittab `/etc/inittab` was init's only configuration file. Beyond the `initdefault` line naming the default runlevel, it contained lines associating each runlevel with a command to run — conventionally an `rc` script invoked with the runlevel number, such as `/etc/rc.d/rc 3` on Red Hat systems or `/etc/init.d/rc 3` on Debian. Init itself contained no knowledge whatsoever about services; it merely ran that one script and let shell take over. ## The rc directories For each runlevel N there was a directory `/etc/rcN.d/` (or `/etc/rc.d/rcN.d/`). It held nothing but symlinks, each pointing back at a real script in `/etc/init.d/`. A typical entry looked like: ``` /etc/rc3.d/S20nginx -> ../init.d/nginx /etc/rc3.d/K80nginx -> ../init.d/nginx ``` The first character encoded the verb and the two digits encoded the order. ## Kill first, then start The rc script processed the directory in two passes. First it took every link whose name began with `K`, in ascending numeric order, and invoked the target script with the argument `stop`. Then it took every `S` link, again in ascending order, and invoked the script with `start`. The two passes are why the same daemon appears twice in the tree with different prefixes and different numbers: it must be stopped early when leaving a level and started at a particular point when entering one. ## The scripts themselves An init script was a plain shell script implementing a small command-line contract: ```bash case "$1" in start) start_daemon ;; stop) stop_daemon ;; restart) stop_daemon; start_daemon ;; status) report_status ;; esac ``` Because it was shell, it could do absolutely anything, and in practice it did: creating directories, setting ulimits, sourcing distribution-specific helper libraries, writing PID files, and finally launching a daemon that detached itself. Every distribution had its own helper functions, which is a large part of why init scripts were not portable. ## Ordering by number, and its limits The numbers were the ordering mechanism, and they were assigned by convention. If your database needed to be up before your application, you gave the database a lower `S` number. Nothing in the system verified or even understood that relationship, so a package installed with the wrong number produced a boot-order bug that appeared only intermittently. The Linux Standard Base later addressed this with a comment block at the top of the script: ``` ### BEGIN INIT INFO # Provides: myapp # Required-Start: $network $remote_fs # Default-Start: 2 3 4 5 ### END INIT INFO ``` Tools such as `insserv` on Debian and `chkconfig` on Red Hat parsed those headers and computed the symlink numbers from them. This was a genuine improvement, but it was still a compilation step producing numbers, not a runtime dependency graph. ## Enabling a service meant managing links There was no separate enablement database. `chkconfig nginx on` or `update-rc.d nginx defaults` created the `S`/`K` links; the corresponding `off`/`remove` deleted them. `service nginx start` invoked the script directly for the running system. That is precisely the enable-versus-start split that systemd later expressed with install symlinks under a target. ## What the model could not do Three limitations drove the move away from it: - **Strictly sequential.** Scripts ran one at a time. On a server with fifty services, boot took as long as the sum of them, and one script that blocked on an unreachable NFS mount or a DNS lookup stalled the entire boot indefinitely. - **No supervision.** Once a script returned, init had no relationship with the daemon at all. The daemon had detached and been reparented to init as an anonymous child. If it crashed a minute later, nothing noticed and nothing restarted it. - **No reliable process tracking.** State lived in a PID file the daemon wrote itself, with all the staleness and race problems that implies, and any children the daemon forked were invisible to the stop path. ## What survives today systemd still runs legacy init scripts: a generator reads `/etc/init.d/` at boot and synthesises service units from what it finds, honouring LSB headers where present. The `service` command is usually redirected to `systemctl`. So the model persists as a compatibility layer, and encountering a genuine init script on a modern host usually means a vendor package that was never converted.