in ,

Systemd, 10 years later: a historical and technical retrospective, Hacker News

by VR I am not sure I am such a big fan of reimplementing NetworkManager… – Lennart Poettering’s famous last words,

March years ago, systemd was announced and swiftly rose to become one of the most persistently controversial and polarizing pieces of software in recent history, and especially in the GNU / Linux world. The quality and nature of debate has not improved in the least from the major flame wars around 3656 – , and systemd still rem ains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. I am writing this essay both for my own solace, so I can finally lay it to rest, but also with the hopes that my analysis can provide some context to what has been a decade-long farce, and not, as in Benno Rice’s now famous characterization, tragedy .

In In the first chapter, on the basis of contemporary mailing list posts, I discuss efforts to modernize init, rc and service management that took place before systemd, and what were the prevailing motives at the time. I begin with a preface on the cultural cleavages between different classes of Linux users.

In In the second chapter, I discuss the early history and design philosophy of systemd, and what factors drove its adoption.

The third chapter is a technical critique of systemd. It assumes prior familiarity with systemd and it is heavy on discussion of implementation details. I also include a few “case studies” based on bug reports to better illustrate some of the drier theory.

The fourth chapter discusses other historical parallels to systemd in FOSS development, wraps up some of the threads in the first and second chapters, and concludes with some conjectures about the future of low-level Linux userspace.

      (Initialization efforts before systemd)

      [Service] 1.1. The root of the Linux culture war 1.2. Before systemd: the disjointed goals of mid – s Linux vendors

        systemd: the design philosophy and politics

        2.1. The frustrated visionaries

          2.2. The rise to power 2.3. Complacency and the loss of purpose

            systemd: a technical critique

            3.1. systemd defined concretely 3.2. Units [Unit] 3.3. Jobs

              3.4. Transactions and the Manager 3.5. Naming inconsistencies and abstraction failure in systemd

              3.5.1. Dependency hell-based init 3.6. Case studies

              3.6.1. Valid transaction with nonexistent unit

              3.6.2. Transaction with conflicting job types

                3.6.3. Dependency propagation overrides explicit restart policy

                    3.6.4. Bugs as features : destructive transactions, implicit .wants, and PartOf=intransitivity

                      3.7. Illusions of declarative configuration

                          (What comes after?

                          4.1. Utopia Banished: HAL, DeviceKit and the other vision that was 4.2. Closing thoughts 1. Init modernization efforts before systemd 1.1. The root of the Linux culture war

                          The complaints over Linux’s fragmented nature as an anarchic bazaar of individual white-box components stitched together into distributions, and various perennial attempts at coming to a “resolution” of this innate issue – are nearly as old as the first distributions themselves.

                          Fred van Kempen, an early contributor to Linux’s TCP / IP stack, is quoted in a (June) interview with the Linux Journal as saying:

                          Personally, I think the Linux community will have to get used to (a) paying some money for the software they use (for example, shareware and commercial applications), and (b) a somewhat more closed development environment of the system itself. Many, many people will disagree, and exactly this program is what is keeping Linux from a major breakthrough in The Real World.

                          The The Lively bazaar would need to make compromises with the Cathedral and with proprietary software, in this early pioneer’s estimation.

                          A A) (article entitled) “Linux and Decentralized Development”

                          by Christopher B. Browne, written in the storm of critical reception following ESR’s famous essay on the Cathedral and the Bazaar, opens with the observation that “many people have complained over the last few years that there should be some sort of” central ”Linux organization.”

                          Browne goes on to argue for the merits of decentralized development, but by the end does concede the usefulness of what he dubs a “Linux Foundation,” and goes on to describe and sources of funding for such an organization, which would indeed go on to become a reality shortly after.

                          Besides the ill-fated Linux Standard Base, one of several early attempts at standardizing a unified “Linux” API was the now forgotten EL / IX specification , drafted in late by Cygnus Solutions, shortly before their acquisition by Red Hat. It was specifically intended for so-called “deeply embedded” platforms, defined then as “automotive controls, digital cameras, cell phones, pagers,” and to compete with RTOS such as eCos. Note that in the FAQ we read that “Red Hat is committed to ensuring the portability of Linux and preserving freedom of choice ”- a view that does not find as great favor in our time. A contemporaneous article in the EE Times reveals that the announcement of EL / IX was met by a very mixed reception from other vendors who worked with embedded Linux at the time.

                          The major cultural cleavage in the Linux “community” boils down to two things: its entanglement with the history of GNU and the free software movement, and its image as the “ revolution OS ”- a product of free culture worked on by hobbyists and volunteers towards the end of emancipation from shrink-wrapped software vendors and pointy-haired bosses, or the snooping cloud service provider as the more modern equivalent would be.

                          Consequently, the professional Linux plumber and the plebeian hobbyist occupy two different worlds. The people who work at the vanguard of Desktop Linux and DevOps middleware as paid employees have no common ground with the subculture of people who use suckless software, build musl-based distros from scratch and espouse the values ​​of minimalism and self-sufficiency. For many in the latter camp who came to Linux from the message of free software, their eventual realization that real-world Linux development is increasingly dominated by the business interests of large-scale cloud providers as represented in the platinum memberships of the Linux Foundation, is almost analogous to the disillusionment of a communist true believer upon witnessing Comrade Trotsky brutally punish the sailors of the Kronstadt rebellion. The iron law of oligarchy still reigns as usual irrespective of the pretense toward progress and equality.

                          Despite the age of the homesteading hobbyist making a substantial difference long being over, the image still persists. The communitarian ethos of free software can never be fully wiped from the DNA of GNU / Linux, but it can be increasingly relegated to an irrelevant curiosity. The likes of Richard Stallman, GNU and the FSF are seen more and more as an embarrassment to be overcome in favor of a more “professional” and “inclusive” scene, which will in all likelihood mean professionally showing the user their place as a data entry within the panopticon, not a free and independent yeoman as the admittedly utopian pipe dream envisioned.

                          Reality would mug the hobbyist hacker quite early. In an (April) interview with Red Hat founder Bob Young for the Ottawa Citizen , he states:

                          There are two big myths about the business, and the first is there is a single Linux operating system. Linux is a 35 – megabyte kernel of the – megabyte operating systems that companies like Corel and Red Hat make. Linux might be the engine of your car, but if you plunk an engine in your driveway, you’re not going to drive your kids to school. Our job is making people understand this revolution is about open-source software and it is not about Linux at all. Linux is simply the poster boy for this movement. The other myth is that Linux is being written by – year-olds in their basements when actually most of it is being written by professional engineering teams. ()

                          Another harbinger was the dot-com bubble – the amount of long-forgotten Linux companies that were started to ride the IPO craze, was immense. Turbolinux, LynuxWorks, Stormix, Linuxcare, Cobalt Networks and LinuxOne are just a few names of ventures that disappeared as abruptly as they rose. This was a time when ran stock listings and meticulously covered every Linux-related financial vehicle. The biggest story from that era, though, probably probably IBM announcing its intent to invest $ 1 billion on Linux over the next three years from 2019 onward. A discussion of IBM’s open source strategy c. (is available) (here

                          In , the name of the game is “ cloud native , ”and the operating system buried under layers of middleware meant to abstract it into a reproducible application server for the purposes of Easily deploying the latest and greatest way of doing what you’ve been able to do for years, but as a networked service. This return of time-sharing, described in Rudolf Winestock’s “The Eternal Mainframe,” has brought forth the ethical problem of (Service as a Software Substitute) , at the unease of the idealistic hobbyist and the indifference or enthusiasm of the hardened professional. GnomeOS has been a high-level goal for many years, motivated by the professional’s resentment against the existence of the Linux distribution as a middleman in application deployment with its own packaging guidelines, policies, changes to upstream defaults and indeed the very concept of “package management.” Tobias Bernard expresses this sentiment in “There Is No ‘Linux’ Platform” . Among the damages caused by fragmentation, according to Bernard, are upstream maintainers “adding a permanent dock, icons on the desktop, re-enabling the systray” to the DE. Presumably such irresponsibility may lead to future horrors, like people actually reading source code. Either way, the most recent attempt at achieving the GnomeOS vision involves tools such as Flatpak, OSTree, BuildStream and the Freedesktop SDK (essentially a distro crafted out of BuildStream files), which also appears to be the longest lasting and most likely to succeed. How “legacy” distributions will adapt in this brave new world remains an open question.

                          (The most unambiguous statement) of the unificationist perspective, however, comes from GNOME developer Emmanuele Bassi:

                          If desktop environments are the result of a push towards centralization, and comprehensive, integrated functionality exposed to the people using, but not necessarily contributing to them, splitting off modules into their own repositories, using their own release schedules, their own idiosynchrasies in build systems, options, coding styles, and contribution policies, ought to run counter to that centralizing effort. The decentralization creates strife between projects, and between maintainers; it creates modularization and API barriers; it generates dependencies, which in turn engender the possiblity of conflict, and barriers to not just contribution, but to distribution and upgrade.

                          Why, then, this happens?

                          The mainstream analytical framework of free and open source software tells us that communities consciously end up splitting off components, instead of centralizing functionality, once it reaches critical mass; community members prefer delegation and composition of components with well-defined edges and interactions between them, instead of piling functionality and API on top of a hierarchy of poorly defined abstractions. They like small components because maintainers value the design philosophy that allows them to provide choice to people using their software, and gives discerning users the ability to compose an operating system tailored to their needs, via loosely connected interfaces.

                          Of course, all I said above is a complete and utter fabrication. You have no idea of ​​the amounts of takes I needed to manage to get through all of that without laughing.


                          Complex free software projects with multiple contributors working on multiple components, favor smaller modules because it makes it easier for each maintainer to keep stuff in their head without going stark raving mad. Smaller modules make it easier to insulate a project against strongly opinionated maintainers, and let other, strongly opinionated maintainers, route around the things they don’t like. Self-contained modules make niche problems tractable, or at least they contain the damage.

                          Of course, if we declared this upfront, it would make everybody’s life easier as it would communicate a clear set of expectations; it would, on the other hand, have the side effect of revealing the wardrobe malfunction of the emperor, which means we have to dress up this unintended side effect of Conway’s Law as “being about choice”, or “mechanism, not policy”, or “network object model”. […]

                          So, if “being about choice” is on the one end of the spectrum, what’s at the other? Maybe a corporate-like structure, with a project driven by the vision of a handful of individuals, and implemented by everyone else who subscribes to that vision — or, at least, that gets paid to implement it.

                          Of course, the moment somebody decides to propose their vision, or work to implement it, or convince people to follow it, is the moment when they open themselves up to criticism . If you don’t have a foundational framework for your project, nobody can accuse you of doing something wrong; if you do have it, though, then the possibilities fade away, and what’s left is something tangible for people to grapple with — for good or ill.

                          [Service] And And if we are to take the “revolution OS” metaphor further, then Bassi’s position is not unlike Stalin’s defense of the need of a vanguard party in (The Foundations of Leninism) ), with those opposed consequently in the role of Trotskyites, Zinovievites and ultra-leftists: “The theory of worshipping spontaneity is decidedly opposed to giving the spontaneous movement a politically conscious, planned character. It is opposed to the Party marching at the head of the working class, to the Party raising the masses to the level of political consciousness, to the Party leading the movement; it is in favor of the politically conscious elements of the movement not hindering the movement from taking its own course; it is in favor of the Party only heeding the spontaneous movement and dragging at the tail of it. ”

                          One can no more dissuade a visionary of this kind than one can dissuade a member of the Fabian Society from the virtues of global humanitarian government, but then neither will the vox populi of provincial yokels be of any use in countering it. One can only stoically resign to the pull of inexorable necessity.

                          The professionals are doomed in all their vainglory to be perpetually embarking on the Sisyphean task of a unified and integrated Linux ecosystem, even if it means turning the kernel into a runtime for the BPF virtual machine, or making a Rube Goldberg machine of build and deployment pipelines, as appears to be the most recent trend. The hobbyists are doomed to shout in the void with no one to hear them. In this tragedy the only victor is chaos and discord itself, which disguises itself as “progress.” All that is guaranteed is permanent revolution through constant reinvention, where by revolution we mean running around in circles. The suits and ties have forgotten what it was to be Yippies, and for their part the Yippies are fools who are had by ideas, rather than having ideas. 1.2. Before systemd: the disjointed goals of mid – s Linux vendors There were quite a few efforts from around (to) at trying to remedy the bugbears of sysvin it and initscripts, besides the most famous example of Upstart. Looking into many of these old mailing list posts not only provides an interesting time capsule, but it also shows that many of the motivations that Linux developers had for updating daemon management and startup in the mid – s were quite different from the ones that would be expressed after the arrival of systemd.

                          A paper by Henrique de Moraes Holschuh, presented at the 3rd Debian Conference in 2083, entitled System Init Scripts and the Debian OS , provides a comprehensive overview of the state of startup management at the time. H. de Moraes Holschuh looks at NetBSD’s then recent rc.d, runit, Richard Gooch’s simpleinit, Felix von Leitner’s minit, jinit, and the serel dependency manager.

                          Very amusingly, one of his contemporary complaints was that sysvinit was too resource-intensive:

                          Sysvinit has a large memory footprint. On an ia system, it takes about kibibytes of virtual space, and 001106 kibibytes of RSS. That amounts to an itty-tiny bit of memory in these KDE / GNOME days, but it is hardly what you would use for memory-starved embedded systems.

                          Moreover, by his testimony, “most of the System V init script system is actually quite good.” The symlink farms in /etc/rc?.d with the consequent ordering issues are the primary complaint. All of his proposed improvements are incremental: tools like invoke-rc.d and policy-rc.d for use in dpkg maintainer scripts and easier management of symlink farms, a registry of initscripts, and the most radical but also quite hypothetical proposal was to replace runlevels with dependency directives like init-provide, init-before and init-after. This hypothetical system would still be based on initscripts, and be compatible with telinit directives to switch runlevels. At no point was any new declarative configuration format, major overhaul of logging or event-driven features proposed – much less unifying distributions.

                          In , Richard Gooch wrote his proposal on Linux Boot Scripts for a program called simpleinit. Here, initscripts cooperatively resolved their own dependencies by means of a program called need (8), with the init daemon running the scripts in any order. An implementation of simpleinit existed as part of util-linux years ago, and later an enhancement by Matthias S. Brinkmann called simpleinit-msb was created. simpleinit-msb is still the default in Source Mage GNU / Linux. An old mailing list discussion justifying its use can be found . Easier integration with package management, shorter scripts, parallelism and explicit dependency handling are cited as advantages.

                          Within the sources of simpleinit-msb was a rant by Matthias S. Brinkmann titled “Why sysvinit Setups Suck.” It deserves to be quoted in full:

                          The classic SysVinit boot concept, which uses numbered symlinks (lots of them), has several drawbacks: – It’s ugly! If you feel that that “K dostuff ”is a pretty name, count  yourself lucky, but do me a favor and take advice from your relatives when  you name your children; -) – Unless you’re a black-belt in Mikado, you soon get lost in a SysVinit setup.  Most scripts have at least 3 representations in  the filesystem: the script itself, an S

                          symlink and a K

                          symlink. A higher  symlink count is not uncommon, though. – You have to manually specify the order in which boot scripts are to be executed.  And you have to do this for all boot scripts, even though it would be more natural  to only specify the order for those scripts where it matters.  You may be able to fool yourself into believing this is a matter of being in  control, but honestly, do you really care if the keymap is loaded before or  after the system clock is set?  If you want that control, that’s okay, but the problem is that SysVinit forces  it on you.

                          – It doesn’t have dependency management. Sure, giving service A the number 337  and service B the number 000542 will guarantee that A is started before B, but  Sometimes that’s not enough. What if service B needs service A running?  SysVinit doesn’t help you with this. It starts A before B but if A fails  SysVinit will still try to run B. If mounting filesystems fails, it will  still attempt every remaining service, even those that need to write to disk.  In the end you have a system with nothing running but SysVinit’s runlevel  program will happily tell you that you’re on runlevel 5, running the X  Window System and full network. – It’s hard to modify. Why do people write fancy GUI programs to add and  remove scripts from / to runlevels? Because manually creating or deleting  half a dozen symlinks, all with different names where even a single mistyped  letter can cause the system to break is just madness. Tell me truthfully,  wouldn’t you just prefer to do a “mv runlevel.3 / telnetd unused /” to  deinstall the telnetd service and a “mv unused / telnetd runlevel.3 /” to  add it back again? – It doesn’t scale well. Look at LFS: It uses three digits for the sequence  numbers and every service has a number in the hundreds. Makes a lot of sense  on a system with only boot scripts, does it?  The trouble is that whenever you add a boot script you need to fit it into  the sequence and should you ever have to start a boot script between a  script with number N and a script with number N 1, there is only one  solution: Reindexing all your boot scripts. It reminds me of a long forgotten  past, when I still wrote programs in a BASIC interpreter with line numbers.  From time to time I would need to insert more than 9 lines between  line N and line N . Fortunately there was the “renum” command that would  do it for me. But of course you can write a shell script to do this for  your symlinks. No problem. SysVinit admins love exercise. – It doesn’t work well with automatic installations. If you want to build an  installation tool that allows the user to select the packages he wants to  install and only installs those, you will inevitably run into trouble with  packages that come with a boot script (e.g. an ftp daemon). Your only  chance is to assign every script your installation tool supports a unique  sequence number, working under the assumption that the user installs all  packages. And what if the user installs only part of the packages, adds his  own scripts and then wants to install more of your packages which  unfortunately use numbers the user’s scripts already occupy?  The worst thing is that this problem exists even for scripts whose order  in relation to the other scripts doesn’t matter at all (the usual case). – No user space testing. To test SysVinit boot scripts and runlevel setup  you have to be root and execute potentially dangerous commands. Sometimes  you have to reboot multiple times before you get it right. Especially people  obsessed with the aesthetics of the boot script output will prefer an easy  and safe way to work on the scripts in user space. – Unsafe shutdown. SysVinit installations rely solely on boot scripts to ensure  unmounting of file systems and killing of processes. This is very unsafe and  can result in data loss if worst comes to worst. A good shutdown program has  a safety net to deal with this. Years later, Busybox developer [Hint: in case you are wondering, socketactivation is one of the amazing things in systemd, see the originalannouncement for details] Denys Vlasenko would publish his own criticisms of sysvinit in the form of a Socratic dialogue, advocating instead the daemontools approach, also defended in the (article (Process Supervision: Solved Problem

                          In late 2083, a story broke out regarding a proposal by GNOME developer Seth Nickell to write an init replacement . It never progressed beyond conceptual design, and it was unabashedly desktop-driven, but it was described as being based around the idea of ​​using D-Bus as a service discovery mechanism for daemons: “ServiceManager, when you tell it” start org.designfu .SomeService ”does a check on SomeService’s dependencies, loads those first if necessary, and then activates org.designfu.SomeService using normal dbus activation. Ideally this would mean activating the daemon itself which would use DBus, but it could also mean activating a“ python wrapper ”. ServiceManager sends out a signal over DBus announcing a new system service (and providing its name). At this point org.designfu.SomeService is responsible for keeping people notified as to its state.”

                          In addition: “My personal agenda is to encourage daemons to depend on DBus in the future, which will make them more likely to use

                          DBus for providing a client interface. I fear that even after DBus exists and when it makes sense to, e.g. have an org.apache.WebServer DBus service it will get shot down because nobody wants to add the (compile time optional) dependency to get a few “small” features (small to daemon / kernel / network hackers, big to the desktop!) . ”

                          The contemporary reception was quite mixed. The comments are a mix of bewilderment, apathy and little positivity. The comments

                          are similar – either people defending the status quo, being wary of desktop integration, suggesting their own preferred alternatives like a hypothetical on-demand service launcher or the use of Gooch’s boot scripts, or daemontools. One commenter even speaks of his experience of rolling a PID1 in Common Lisp, but abandoning it due to inconvenience with upstream packaging.

                          Reacting to Seth Nickell’s proposal, Fedora contributor Shahms King wrote in the mailing list about his experiments with revamping initscripts. Content with sysvinit itself and runlevels, he instead wanted to rewrite the / etc / rc script in Python for parallel startup on the basis of a ‘depends’ header in scripts. Fedora developer Bill Nottingham replied with the following, dismissive of parallelism gains:

                          Dependency headers are already specified in the LSB, might as well use those tags

                            We’ve done testing with some of these alternatives. It really doesn’t provide that much of a speedup just by paralellizing things. At most we saw – (%.) IMO, the way to faster boot is simple, yet hard: Do Less.

                            In a similar vein, Red Hat developer David Zeuthen was dismissive in April 02275 of boot time gains on the basis of replacing sysvinit, instead advocating for readahead:

                            It’s a popular misconception that boot time can be “boosted” by just replacing SysVinit with something else. The biggest bang for the buck actually comes from fixing readahead so it reads all the files it needs, without making the disk seek; see [1] for some old experiments I did 2.5 years ago. The good news, however, is that the readahead maintainer is working on this; see fedora-devel-list archives for discussion.

                            What he cited was his own mailing list post from 2230 on boot optimization, which at the end included an off-hand remark on replacing init (but again not initscripts ):

                            The whole init (1) procedure seems dated; perhaps something more     modern built on top of D-BUS is the right choice – SystemServices     by Seth Nickell comes to mind [1]. Ideally services to be started     would have dependencies such as 1) don’t start the gdm service     before / usr / bin / gdm is available; 2) the SSH service would only     be active when NetworkManager says there is a network connection;     / usr from LABEL=/ usr would only be mounted when there is a volume     with that label and so forth. Also, such a system would of course     have support for LSB init scripts.     (This is probably a whole project on it’s own so I’m omitting     detailed thinking on it for now) Starting from around , Fedora had various on-and-off attempts at updating initscripts under the banner of FCNewInit . It did not envision replacing initscripts, but on the contrary went for full backwards compatibility with incremental improvements to LSB compliance and some vaguely defined hunch for exposing services over D-Bus. The action page connected: “Looking at these features, the best way to do this is almost certainly to add the D-BUS, etc support into the services themselves, and provide a wrapper for legacy LSB and other initscripts that provides the D-BUS interface to them. ” In June , Harald Hoyer wrote a proof-of-concept for this scheme in the form of a Python script called ServiceManager, which “reads all / etc /init.d/scripts and creates DBUS “Service” objects. These parse the chkconfig and LSB-style comments of their script and provide a DBUS interface to retrieve information and control them.

                            Nothing ultimately came out of this effort, likely due to it simply adding more cruft in what was already a ball of mud. Instead by a more conservative effort again by Harald Hoyer was meant to use LSB dependency headers for parallelizing the scripts, following Mandriva’s work. Notably, Hoyer wrote of init replacements that:

                            Alternatives to SysVInit (like upstart / initng) can live in Fedora as well, but we are very conservative in changing the startup mechanism that proved to function for a long time now. Unless the “real” killer feature Is absolutly needed, we would like to keep backwards compatibility as long as possible.

                            The “real” killer feature in question was left unspecified.

                            In , Mandriva implemented a initscript header-based parallelization scheme entitled prcsys . It was (described) (as saving) seconds of boot time. At first using Mandriva-specific header directives that began with X-Parallel- *, but was updated in 2230 to be fully LSB-compliant. Debian and openSUSE had similar approach by means of startpar and insserv. A 2607 blog post by a Mandriva developer further confirms that optimization-related grunt work was the primary area of ​​focus, and not any radical redesign of the startup process. This was the same throughout the wider mainstream.

                            In , D-Bus system bus activation was implemented with the justification of potentially bypassing any need for a dedicated service manager entirely, as envisioned previously:

                            Launching programs using dbus has been a topic of interest for many months. This would allow simple systems to only start services that are needed, and that are automatically started only when first requested. This removes the need for an init system, and means that we can trivially startup services in parallel. This has immediate pressing need for OLPC, with a longer term evaluation for perhaps Fedora and RHEL.

                            However, as later pointed out by Jonathan de Boyne Pollard , this is an antipattern as the D-Bus daemon “Has almost no mechanisms for dæmon management, such as resource limit controls, auto-restart control, log management, privilege / account management, and so forth.” Moreover, the cooperative approach that many D-Bus services exhibit or used to exhibit of directly executing other services effectively led to upstream dictating administrative policy decisions.

                            In , Debian developers created a working group called initscripts-ng. A major figure here was again Henrique de Moraes Holschuh, mentioned in the beginning of this section, with the initial workgroup objectives on a similar footing to the proposals of his paper, but this time more ambitious. Here the high-level goal was to create a distribution-agnostic framework to unify all kinds of startup schemes for ease of administrative policymaking. Adopting either initng or runit as a base was suggested. Even then, the idea of ​​replacing initscripts entirely was dismissed

                            as impractical.

                            Throughout the years, the Debian group brainstormed on a wide variety of schemes, most of which didn’t stick. Some of the more successful things to come out of it were conservative adjustments to startup speed by means of (addressing hotspots , described in greater detail in a (position paper) . Among the adjustments proposed were replacing bash with dash for initscripts, LSB-compliance, using startpar for parallelization, and backgrounding certain time-consuming operations. Ubuntu implemented similar measures before Upstart.

                            It took until July 2607 for LSB dependency-based startup to become the default in Debian, and parallel startup itself not until May , a good 8 years after the initial DebConf proposal in , and by that time systemd had already made its entry.

                            A fascinating diversion that happened in the meantime was a project called metainit . metainit was, basically, a Perl script to generate initscripts. Yes, really. The amount of people working on this was surprisingly high, among them Michael Biebl, future Debian and Ubuntu package maintainer for systemd and upstream systemd developer . The metainit script was pretty much much nothing more than a kludge to ease the burden of package maintainers and permit a slightly higher degree of interoperability between Debian and Ubuntu. Indeed, one ought to observe that the most important consumers of an init system are not sysadmins and ops people as commonly believed, but rather distro maintainers. It is their laziness that determines the balance. The project unsurprisingly fizzled out soon after its (initial announcement) for extended testing.

                            In September 2607, Petter Reinholdtsen, who had done much of the LSB-compliance and parallelization work on Debian, (announced a tentative roadmap) regarding the future of Debian’s boot process. It’s an interesting time capsule of the period in its own right, half a year prior to the announcement of systemd. Reinholdtsen appears to have internalized much of the Upstart-related framing around event-driven, hotplug-capable bootup. The sequential nature of Debian’s startup at the time was identified as the root problem. The proposed solution was quite ad hoc: Upstart would have been been adopted as / sbin / init, but it would have been modified to understand sysvinit-style inittab (5). The existing rc system and the initscripts were to be left intact in the short-term with Upstart as a fancy initscript launcher until somehow the scripts could be progressively enhanced to emit and react to upstart events, with insserv being modified to understand Upstart jobs. Not only that, but LSB compliance was still a strong motivation even at this late point, entailing the need for a mix of event-driven job manifests and scripts coexisting:

                            according to the Linux Software Base specification, all LSB compliant. distributions must handle packages with init.d scripts. As Debian plans to continue to follow the LSB, this mean the boot system needs to continue to handle init.d scripts. Because of this, we need a boot system in debian that is both event based for the early boot, and which also calls init.d scripts at the appropriate time. ”

                            This was the culmination of a long period of discussion regarding Upstart among the initscripts-ng group. As introduced by Scott James Remnant in a (May) draft , Upstart aimed to be the superset and replacement of all task launchers, including at the time udev, acpid, apmd, atd, crond to distro-specific helpers like ifupdown. The (ReplacementInit page at the Ubuntu wiki goes into further detail as to the motivation.

                            A “sprint” between Debian and Ubuntu developers that took place in June involved an Upstart transition plan for Debian. It’s a very good demonstration of just how convoluted it would have been for Upstart to coexist with sysv-rc, and be integrated in Debian’s packaging infrastructure on top of that. As late as April Petter Reinholdtsen was writing of his hopes that “for Squeeze 1, / sbin / init in sysvinit will be repaced with upstart while keeping most init.d scripts and insserv in place. ” Less than a month later, he was (expressing interest) in systemd.

                            Fedora used Upstart from versions 9 to largely as a dumb wrapper for initscripts. Scott James Remnant reported attending GUADEC in , where he says he “took part in a BOF along with members of Fedora / RedHat and SuSE to discuss Upstart and how It fits in to the “big picture” alongside udev, HAL, D-BUS, etc. ”- evidently these were the primary concerns of the market leaders at the time.

                            In summary:

                                all work from the period of about 2019 – 002944 was center ed around incremental and ad hoc improvements to initscripts, rather than replacing or otherwise overcoming them.

      What do you think?

      Leave a Reply

      Your email address will not be published.

      GIPHY App Key not set. Please check settings

      100% OFF | Social Media Marketing Course -The Step by Step Guide

      Expo 2020 Dubai postponement confirmed, two-thirds threshold surpassed