21

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
4
  • 2
    Are you sure that sysvinit was introduced as late as 2008?
    – Jonathon Reinhart
    Nov 16, 2018 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, 2018 at 10:13
  • 3
    @pipe the question is not about systemd, it's about other init systems which were used before systemd existed
    – Kidburla
    Nov 17, 2018 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, 2018 at 19:00

3 Answers 3

Reset to default
30

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
10
  • 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, 2018 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.
    – user722
    Nov 16, 2018 at 19:08
  • 3
    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, 2018 at 1:31
  • 2
    There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    Nov 17, 2018 at 1:46
  • 1
    @JdeBP Regardless, faster boot times was and still is the most compelling reason to use systemd instead.
    – user722
    Nov 17, 2018 at 17:09
5

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 comparatively "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 today's battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged in and detached, systems are put into 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 led to the design of e.g. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.

Improve this answer
4
  • 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, 2018 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, 2018 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, 2018 at 8:59
  • If anyone wants a good overview of that pre-Linux phase of init's evolution, including what motivated its design, I'd suggest The Tragedy of systemd. (According to the URL for more info, it's a linux.conf.au talk from 2019 but Mozilla seems to have removed the "Make an exception for an expired TLS cert" button, so I can't check that right now.)
    – ssokolow
    Sep 7, 2021 at 15:16
3

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
  • 5
    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, 2018 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, 2018 at 22:21
  • 2
    "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?
    – user
    Nov 19, 2018 at 14:55
  • @user, ExecStart= in .service files provides that explicit connection; which executable is going to be exec'd is machine-readable metadata (and if that executable goes on to start other executables, exactly what they are is tracked, as each service is run in a distinct cgroup). If you wanted to write a program that scans active services and tells you which one starts executable A, you could do it without needing to try to parse shell scripts.
    – Charles Duffy
    Sep 18, 2022 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .