15

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?

|improve this question
  • 1
    Are you sure that sysvinit was introduced as late as 2008? – Jonathon Reinhart Nov 16 '18 at 22:03
  • systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere) – pipe Nov 17 '18 at 10:13
  • 1
    @pipe the question is not about systemd, it's about other init systems which were used before systemd existed – Kidburla Nov 17 '18 at 18:58
  • @JonathonReinhart you are right, as @StephenKitt also pointed out. I have edited my question to match. I wasn't previously aware that sysvinit was so old, as the earliest references I could find to it were from 2008, but I have now been proven wrong... – Kidburla Nov 17 '18 at 19:00
25

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.

|improve this answer
  • 4
    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992. – Stephen Kitt Nov 16 '18 at 14:12
  • 1
    Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster. – Ross Ridge Nov 16 '18 at 19:08
  • 1
    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems. – JdeBP Nov 17 '18 at 1:31
  • 1
    There is more history in A history of modern init systems (1992–2015). – JdeBP Nov 17 '18 at 1:46
  • 1
    @JdeBP Regardless, faster boot times was and still is the most compelling reason to use systemd instead. – Ross Ridge Nov 17 '18 at 17:09
3

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.

|improve this answer
  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5. – JdeBP Nov 17 '18 at 1:38
  • 1
    Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added. – Gunter Ohrner Nov 17 '18 at 9:53
  • You can improve it further by including information about the various rcs that went along with van Smoorenburg init in the 1990s. There was van Smoorenburg's own, but there was also r2d2. The sad thing is that what was cloned was years out of date. By 1990, two years before the cloning, run-levels and a lot of inittab had already become obsolete. – JdeBP Nov 18 '18 at 8:59
2

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.

|improve this answer
  • 4
    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest. – Stephen Kitt Nov 16 '18 at 22:21
  • 1
    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal). – Jörg W Mittag Nov 16 '18 at 22:21
  • "There was no explicit connection between the thing started by a script, and the script itself." How is that any different from present-day systemd? – a CVn Nov 19 '18 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.