SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?".
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
> why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?
Run levels. That's it, sysvinit is about run levels. Each run level starts or kills off its own specific list of runnable things like applications, daemons, capabilities, etc.
Run levels were a desirable feature back in the day amongst System V Unix vendors, so each run level required its own kill and start scripts for each item. Run levels, for example, could take a running system from single user (root admin) mode to multi-user, multi-login, NFS sharing, full X11 mode in one command immediately as the scripts ran. This allowed rapid reconfiguration of a system, such as from a GIS workstation to a headless file server, etc. etc. as needed. Each system could be configured to boot to a specific run level. Rather than duplicate some or all such scripts across some or all run levels, symlinks were the solution.
For example, Solaris had run levels 0 through 6. Zero was a blunt force system halt; 1 was single root user admin mode; 2 was multi-user headless mode with NFS; 3 was multi-user X11 windows mode with NFS; 4 was unspecified and therefore kept for purely local configuration as desired; 5 was a planned, orderly system shutdown; and 6 was a planned, orderly system reboot. The root user could implement their choice of run level directly with the init command.
Each run level had its own run control directory (rc.d) under /etc/rc.d for its appropriate kill and start scripts, which were run in order of their K or S number, so dependencies had to be kept in mind when numbering, and curing a dependency failure was as simple as changing a script's number to rearrange the list. So, why copy S04blahblah from rc2.d to rc3.d when a symlink is far better?
Its not hard to understand when you get the big picture, and it wasn't hard to administer if you had the proper overview of it all. Admittedly, admins coming in cold would have to sort through it all, which is partly why it gained a reputation for murkiness when not properly documented by/for local admins. Keep in mind it was the era of administering sendmail macros and NIS tables by hand and you get the picture.
NOTE: edited for clarity