Differences between revisions 28 and 29
Revision 28 as of 2013-10-30 09:09:18
Size: 10208
Editor: ?SteveLangasek
Comment:
Revision 29 as of 2013-10-31 20:46:25
Size: 10208
Editor: ?SteveLangasek
Comment: wording tweak
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * Upstart is covered by a [[http://www.canonical.com/contributors|copyright license agreement]], which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the package itself; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.  * Upstart is covered by a [[http://www.canonical.com/contributors|copyright license agreement]], which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the Debian package; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.

This page documents the position statement of individuals who suggest that Debian should adopt upstart as the default init system. Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainer.

Upstart Position Statement

Upstart is a modern, well-tested, event-based init system. It is used on tens or hundreds of millions of servers, desktops, cloud instances and embedded systems throughout the world. Debian should adopt it as the default init system for the jessie release.

Pros

  • Upstart brings significant new functionality to init, using a simple, declarative job configuration format (described here) that removes the need to maintain init scripts written in shell as "configuration files". Changes to job configuration can be maintained in separate .override files, or as changes directly to .conf files that are straightforwardly diffable/mergeable on upgrades.

  • Upstart supports backwards-compatibility. It is straightforward to include an /etc/default/foo file in an upstart job if needed (though this is not the recommended configuration method where sysvinit compatibility is not required). Existing init scripts will continue to run. insserv dependency relationships between init scripts are respected, providing a smooth transition to upstart from sysvinit.

  • Upstart has been tested in battle. Two consecutive long-term supported releases of Ubuntu have shipped with native upstart job support, giving Ubuntu an opportunity to shake out all the bugs so that Debian doesn't have to. The work to integrate upstart support from Ubuntu into Debian is straightforward.
  • Upstart fixes bugs. There are many longstanding race conditions in the existing sysvinit startup sequence that cause problems in complex disk/network configuration scenarios. These problems have been solved in the upstart rollout on Ubuntu, Debian will not have to reinvent the wheel.
  • Upstart welcomes ports. Lack of support for non-Linux ports has been a concern in all of the discussions about changing Debian's default init system. Upstart upstream has expressed their interest in having ports to Hurd and kFreeBSD, so that a decision to adopt Upstart does not mean maintaining compatibility with two init systems in Debian indefinitely.
  • Upstart is elegant. The code is easy to read, making it easier to debug and modify. It uses libnih, the best C utility library around (beats the pants off of glib for code clarity by leveraging current C standards and relevant gcc extensions).
  • Upstart is tested code. There is a thorough upstream test suite that is run at package build time. The test suite is twice the size of the code itself.
  • Upstart is actively maintained. Canonical continues to develop upstart as an active upstream project, responding to the evolving needs of its users.

Cons

  • Upstart is covered by a copyright license agreement, which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the Debian package; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.

Upstart vs. SysV init

We've gotten a lot of mileage out of sysvinit in Debian, but its limits have been showing for a while - indeed, it was these limits that led to upstart being written in the first place.

  • Sysvinit lacks service supervision. While /etc/inittab provides this capability, management of /etc/inittab is quite restrictive. Upstart eliminates the need for complicated PID file handling for all services. There are bolt-ons that allow you to do service supervision on top of sysvinit, such as runit, but it's clear that these are bolt-ons.

  • Sysvinit does not track dependencies between services. Insserv/startpar provides this on top of sysvinit, but this is again very much a bolt-on, and only handles dependencies at boot/shutdown time (i.e., during runlevel changes) and can't handle any complicated service interdependencies at runtime. Upstart expresses this information in the native service configuration format, clearly and concisely.
  • Sysvinit requires complex shell scripts for each service. While some of the complexity has been abstracted out into common helpers (lsb-functions; start-stop-daemon), having to represent each service's start/stop handling as a program is a severe handicap. Upstart jobs are simple, declarative, easy to maintain, and easy to modify locally as needed. They also eliminate the longstanding nuisance of update-rc.d reactivating services behind the administrator's back on upgrade.
  • Sysvinit is linear. It stopped being a good fit for boot management on Debian the moment Debian adopted udev. There are many race conditions that persist in Debian today when booting with sysvinit, and although these may be fixable, the complexity for fixing them with sysvinit is very high. We're better off switching to an init system that's designed to work together with the event-based kernel and udev.

There is no reasonable justification for Debian continuing to inflict sysvinit's limitations on users today.

Upstart vs. SystemD

In terms of overall feature uplift of the init system itself, there is really rather little to distinguish upstart from systemd. Both would represent a huge step forward for Debian over sysvinit. If Debian did not adopt upstart, systemd would certainly be my second choice.

But despite the init systems being comparable at the feature level, there are reasons that I think upstart is a better fit for Debian than systemd.

  • SystemD is Linux-specific. Upstream has been very clear that they are not interested in accepting porting patches to enable systemd to be used with kernels other than the Linux kernel. If Debian wishes to continue to support non-Linux ports, this significantly reduces the benefit that maintainers would gain from having a simpler init format to support.
  • SystemD is hasty. Debian is late to the party when it comes to adopting a better init system, but systemd is evolving rapidly and does not have a long track record of backwards-compatibility that it can point to. While systemd is unlikely to break any interfaces that upstream has promised to maintain, I think there is a risk that newer dependencies will be driven by the version requirements in Fedora and RHEL, leaving Debian to fend for itself with respect to sorting out rocky transitions on upgrade - not unlike the problematic udev transitions of the past. Upstart is committed to maintaining compatibility across stable releases of Debian, just as it currently does between Ubuntu LTS releases. While upstart seeks to leverage newer kernel features where this makes sense, we are committed to having sane upgrade paths and not depend on such kernel features prematurely.
  • SystemD is "greedy". Most of the recent arguments about why it's dangerous to adopt upstart instead of systemd center around features that are being built into systemd in a manner that can't be separated out (e.g., cgroup management in PID 1). There is an advantage to the implementor to put these features in-process in init, because it ensures early availability with no concerns about startup ordering at boot, but it commits downstreams to a monolithic design with respect to parts of the system architecture which are not settled questions in the wider ecosystem. Debian should take a principled position regarding its future architecture, and not find itself at the mercy of other parties who wish to dictate design to us.

Rebuttals

  • The systemd position statement incorrectly identifies Ubuntu bug #406397 as a fundamental design issue due to the use of ptrace. This is a longstanding bug, but it is not fundamental to the use of ptrace. It would be a good idea to obsolete the use of ptrace in the future for its own sake, but this bug exists primarily because upstart provides more granular definitions of service readiness that are not available in systemd.

  • The systemd position statement cites a comment from the original author and former maintainer of upstart as evidence that upstart is hostile to non-Linux ports. Scott James Remnant is no longer involved in upstart development; this is self-evidently outdated information.
  • The systemd position statement asserts that you can't attach gdb to a process run by the init system. This is not true, and can only be speculation on the part of the systemd proponents: ptrace is only used during service startup, after which upstart detaches from the process (relying on ordinary waitpid() for notification of service exit). This means that for all intents and purposes, by the time you would actually be in a position to try to attach to the process with gdb, upstart will no longer be tracing it. For valgrind, it's true that this would be less straightforward to do as part of an upstart job. If there were widespread demand for solving this, it wouldn't be difficult; but this doesn't seem like something that has much practical impact. It's unlikely that someone using valgrind for debugging will need to debug via an upstart job or systemd unit, as opposed to running the service directly.

Position Statement Maintainers

  • ?SteveLangasek

Comments