SysVinit
"We don't execute people just because they are old, and worship people just because they are new" "We shouldn't do so with technology"
Why can we not be afforded the choice to stay with sysvinit that we know and have no problem with? Sysvinit is a known quantity. It doesn't crash, it doesn't do too many things, it starts up the system and that is that. Very few people need the process tracking that is the main feature of these new init systems. It is an "enterprise" feature, and most of us do not need it at all. So why must we not in the enterprise be dragged along?
Debian once upon a time was the more unix like, less redhat like distro. It was for those who knew what they were doing or who wanted to learn. Will a new debian be needed once that which we knew is gone? Is it possible to take on such a project now that our choice is to be taken from us and those things which we have learnt over the past decades be paved over with some new flavor of the month or year? Is churn and change of process really a good thing? Should we build our machines on shifting sands.
RFA: a volunteer is sought to assume maintainership of this page, who may need to produce a position statement as detailed at 727708#305 and 727708#315 This has been drafted from arguments raised in debian-devel and elsewhere.
(Proposed introductory statement) This statement does not denounce claims that newer init systems provide useful features which makes them more suitable than ?SysVinit for many users. We still believe that ?SysVinit is the best init system for Debian users. We also believe that even if ?SysVinit is not the best init system for Debian users at this moment, it would be wrong to migrate to Upstart or systemd. The most natural successor for ?SysVinit is certainly OpenRC. For details see OpenRC statement. Although OpenRC is not yet in Sid, it could soon become available.
Pro
- It is integrated in the Debian ecosystem and this integration is well tested.
- It works on all supported architectures and kernels
- Has a long history (System V R4, 1988?), and so is widely used, well documented and understood by users of UNIX-like systems; /etc/rc.d initscripts are still used today by FreeBSD (since at least 1999), NetBSD since v1.5, OpenBSD uses something similar since v4.9; Red Hat from ??? up until RHEL6 and Debian since ???
Is the smallest and simplest initsystem available http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems#Size_and_complexity
- Init scripts can be improved using abstraction and addtional features can be implemented as suplemental software that could be used from shell scripts.
- Many of us using sysvinit know how to fix an unbootable system: boot with init=/bin/sh and you can edit or invoke the initscripts by hand.
- Init scripts are a standard interface for many other purposes. Things like heartbeat, pacemaker, ... can all call initscripts directly.
- Init scripts are most easy to understand and debug. All important logic is contained in them, code is very readable, intuitive and simple and debug outputs can be inserted everywhere.
Contra change to another initsystem
- Any change at all involves work, learning something new, and therefore should be a choice; this decision feels somewhat forced upon us by some who insist it is better for us.
- If GNOME requires logind which requires systemd, it is unreasonable to impose such a change on the whole distribution, and ought to find an alternative which doesn't.
Unless the new initsystem retains backward compatiblity, and packages continue to provide sysvinit-style initscripts:
Estimates are that up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.
- If packages remove their current initscripts, ports like kFreeBSD and Hurd may be unable to use software that was working before this. (Unless the new initsystem can be ported; this is most likely for OpenRC but completely ruled out for systemd).
- Much third-party software outside of the Debian archive, or in-house projects within business, may no longer work without taking effort to port them to a new initsystem.
- Some maintainers object to maintaining separate initscripts to support alternate systems.
- Declerative systems are nice to look at and might cause fewer problems, but if there is a problem, they are almost impossible to debug. Even more so if you only have a non-working system (as the problem would be in the init system).
- At least judging from their documentation they all support significant logging.
- Even given the disadvantages of editing init scripts (hard to merge with upgrades, ...) and the resulting reluctance of admins to edit them directly, almost every admin has used this ultima ratio at some time, which indicates the missing flexibility to do so might be a problem with other init systems.
Contra systemd, upstart
- Not all functionality can be controlled by configuration files and is instead contained in compiled code and if you need to change something it is difficult.
- (mainly systemd) Principle of all-mighty solutions is in its nature authoritarian. All-in-one "solutions" are a characteristic of big companies that want to seduce its users into a vicious circle of using their integrated software, while sacrificing other tools that would give them more benefit, thereby realizing abusive psychological advantage above the user.
- Init system supported by a big company may have better support but that support is influenced by interests of that company.
- They depend on DBus, which means that if DBus is not working system initialization cannot begin.
- Key feature of free software is forking, which saves the software from falling into hands of corrupted people. When a project is corrupted, good developers can fork it and make a new project. But if a software is too complex, then forked project is also too complex, and that could demotivate developers to work on such project.
- If makers of systemd and upstart really wanted to contribute to F/OSS community, they could just improve sysvinit, init scripts and add additional software that can be used from shell scripts to achieve the same features they provide. Which is basically what openrc did.
- Complex software has more bugs. Software requiring a complex SysV init script at the moment (e.g. Squid) may still need a complex Upstart or systemd definition.
- Features provided by these init systems are often compensations for lack of features in software that should have those features, and which should not be in init system; e.g. 'start daemons when they are first used' feature compensates lack of support for inetd in server software.
- Boot speed may not be important enough to justify a new init system; BIOS POST, option ROMs, EFI boot may take a long time already, and most server systems are rarely restarted anyway.
Contra systemd
- Not portable, by design; uses Linux-specific functionality not available on other platforms.
- Binds Debian to being a Linux distribution; even some Linux ports may have to be dropped if systemd stops supporting them.
- Violates traditional UNIX principles of simplicity and the separation of kernel/initsystem/userland duties such that components are interchangeable.
- Begins a precedent for disruptive change, which may happen again if systemd changes its APIs or deprecates some interfaces (has been described as resembling 'vendor lock-in'; really meaning we must continue to keep up with changes mandated by upstream).
- logind can no longer be used standalone, as of systemd v205
- plans to replace ifupdown scripts too
- conflicts with busybox-syslogd
- Questions over agenda / conspiracy theories surrounding GNOME, systemd, and Linux, particularly Red Hat's interest in them.
- We don't need the stress associated with ever changing to the newest thing and being lead by the nose down another "rabbit hole". Debian should be a rock amidst the sands, not dust blown by the wind.
- Attitudes expressed by those pushing systemd:
- disinterest in Debian's ports, in "choice" and the ability to "combine everything with everything else":
- misunderstanding of the 'modular' concept; having "some 80+ binaries around" is bloat, it is not modular if they depend on using systemd and its interfaces together as a whole
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
- Lennart Poettering: "The only thing we won't take is patches that make systemd portable to the BSDs or Hurd."
- Throwing POSIX completely out of the window: where does reinvention end?
- "Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl)."
- "unified" is a bad replacement for complying to standards (such as POSIX) and conventions and power must go along with responsibility
- "Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl)."
- Minimum system dependencies for systemd:
- acl dbus glib2 hwids kmod libcap libgcrypt pam attr glibc expat libcap openssl pam perl cracklib db libtirpc libgssglue
Contra upstart
- upstart is covered by the Contributor License Agreement; Canonical retains full BSD-like rights over its code and modifications shared back upstream, but the general public can use it only with GPL copyleft restrictions.
- Only available for Linux yet; anyone able and willing to port it would likely have to agree to the CLA, or otherwise fork a separate project.
- Questions over agenda of Canonical / Ubuntu project.
- Default 'reload' action is 'buggy' (Ubuntu 10.04)? Sends SIGHUP which the software may ignore.
- Can't set proper dependencies until everything has converted from SysV init files to Upstart jobs.
Contra OpenRC
- This initsystem is the least familiar to most of us yet (only recently packaged, and still in Debian's NEW queue).
Contra sysvinit
- Perhaps this section belongs on the other initsystems' pages?
- It is hard or at least non-obvious to support daemons starting on demand.
init scripts are not really user edit-able configuration. (https://lists.debian.org/debian-devel/2013/05/msg01787.html)
- Nor should they be; we have /etc/defaults and the rest of /etc for this
- No real process supervision, e.g. daemons are not automatically restarted when they crash.
- They shouldn't crash, but supervising parent process often handle this where needed; djb's daemontools and similar can be used more generally.
- No integration with udev, services cannot be started when specific hardware is discovered.
- This sounds like the specific goal of a desktop environment trying to be user-friendly, but isn't something everyone wants; tight integration between kernel, initsystem and userland is a high price to pay.