Gfrktyl

Nowadays there is quite some debate and controversy over whether Linux distributions should use systemd, GNU Shepherd etc. But all these systems are relatively new - for these examples dating back to 2010 and 2003 respectively.

Since the whole point of the term "GNU/Linux" is that GNU was (at that time) a complete operating system without a kernel, what init system was used in early distributions, for example in the 90s? It seems that init (or equivalent) is a pretty fundamental thing to have in any UNIX-based system. Also, what was wrong with the systems used at that time that led to the creation of systemd et al?

Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.

This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.

Also, what was wrong with the systems used at that time that led to the creation of systemd et al?

That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.

System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.

Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.

Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.

This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.

This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.

Also, what was wrong with the systems used at that time that led to the creation of systemd et al?

It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:

• Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...


• There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).


• Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.


• As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...

At the end of the day, it was just natural progression to look for more capable systems.