== The good and bad of the System V init system The good of System V init is that it gave us several big improvements over [[what came before InitHistoricalRoles]] in V7 and BSD Unix. First and largest, it modularized the boot process; instead of a monolithic shell script (or two, if you counted _/etc/rc.local_) you had a collection of little ones, one for each separate service. This alone is a massive win and enabled all sorts of things that we take for granted today (for example, casually stopping or starting a service). The other big change is that System V init turned the entire work of init from a collection of hacks into a systematic and generalized thing. It formally defined runlevels and runlevel transitions and created in _/etc/inittab_ a general mechanism for specifying all of the work init did, from booting to running _getty_s on serial lines (or running anything) to how to reboot the system. System V init removed the magic and hardcoding in favour of transparency. Things like _reboot_ stopped killing processes and making special system calls and turned into 'tell init to go into runlevel ...', and then _/etc/inittab_ and runlevel transitions said what to do so that this actually rebooted the machine. In the process it added a way to specify how services shut down. (Simply defining runlevels formally meant that other systems could now tell what state the system was in and behave differently between eg single user mode and multiuser mode.) The very general and high level view of the bad of the System V init system is that fundamentally all it does is blindly run shell scripts (and that only when the runlevel changes). This creates all sorts of lower-level consequences: * SysV init doesn't know what services are even theoretically running right now, much less which ones of them might have failed since they were started. * It doesn't know what processes are associated with what services. Even individual init scripts don't know this reliably, especially for modern multi-process services. * Even init scripts themselves can't be certain what the state of their service is. They must resort to ad hoc approaches like PID files, flag files for 'did someone run