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?

Kidburla
  • 455
  • 4
  • 9
  • 2
    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
  • 3
    @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

3 Answers3

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.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit? – Kidburla Nov 16 '18 at 13:57
  • 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. –  Nov 16 '18 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 '18 at 01:31
  • 2
    There is more history in A history of modern init systems (1992–2015). – JdeBP Nov 17 '18 at 01:46
  • 1
    @JdeBP Regardless, faster boot times was and still is the most compelling reason to use systemd instead. –  Nov 17 '18 at 17:09
  • @Ross see, that’s why I said that part of the question is opinion-based. In my experience systemd isn’t necessarily faster than sysvinit. What I like about it is that it actually manages the services it starts, that it supports user services, and that it enables much more dynamic services: dæmons which start and stop according to the availability of certain hardware (and have proper lifecycle management in between), or certain networks, VPNs etc. – Stephen Kitt Nov 17 '18 at 18:30
  • @StephenKitt I don't really think there's actually much controversy about boot times, it's what I hear over and over when the benefits of systemd is discussed. On other the hand statements like "it actually managed the services it starts, etc.." are much less compelling because they only amount to a vague promise of a real improvement. Compare that to "I can plug this device in and it works much more reliably with less hassle", or "This VPN scenario was nearly impossible before, is but it's easy to set up with systemd". But I rarely hear statements like that. –  Nov 17 '18 at 19:10
  • @Ross I’m just giving my opinion on the topic (based on experience). “It actually manages the services” means for example that it can restart a service which fails, and that when told to stop a service, it know how to really stop it, regardless of how it dæmonised (if at all) and how many other processes were started to provide the service. But I’m not trying to debate the merits of systemd; I’m trying to point out that answers to that part of the question are opinion-based. You have your opinion, I have mine, that’s perfectly fine IMO. – Stephen Kitt Nov 18 '18 at 17:42
  • @StephenKitt I'm not debating the merits of systemd, just what people in fact actually find to be the most compelling, misguided or not. –  Nov 18 '18 at 19:55
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.

Toby Speight
  • 1,611
  • 14
  • 31
Gunter Ohrner
  • 69
  • 2
  • 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 01: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 09: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 08: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 07 '21 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.

AnoE
  • 1,549
  • 9
  • 13
  • 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 '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
  • 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 '18 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 '22 at 13:41