Debian diskutiert wieder über Init-Systeme

Debian Swirl
Debian und das Init-System

Das Thema Init-Systeme hat Debian schon mehrfach erschüttert. Zuletzt 2014, als sich Debian nach zähem Ringen durch eine Entscheidung des Technischen Komitees für Systemd als künftigen Standard beim Init entschied. Damals verlor Debian viele Anwender, das Projekt wurde sogar geforkt. Seither versucht Devuan, mit alternativen Init-Systemen auszukommen. Debian dagegen versprach, alternative Init-Systeme weiter zu unterstützen und SysVinit möglichst lange parallel ko-installierbar zu halten.

Seit einigen Wochen deutet sich an, dass SysVinit und andere Alternativen anscheinend an Unterstützung im Projekt verlieren. Debians derzeitiger Projektleiter (DPL) Sam Hartman machte das Thema zum Hauptpunkt seiner monatlichen Zusammenfassung »Bits from the DPL« für August.

Elogind blockiert

Anlass war die Blockade einer neuen Version des Pakets elogind seitens eines Mitglieds des Release-Teams. Elogind ist eine bei Gentoo entwickelte Alternative zu logind, die aber ohne Systemd auskommt. Durch die Blockade wurde das Paket daran gehindert, in das Testing-Repository zu gelangen. Eine Diskussion im IRC und die Diskussion der Paketbetreuer von elogind und systemd verliefen zunächst fruchtlos.

Nicht trivial

Die alternative Nutzung von elogind greift tief ins System ein und der DPL und einige weitere Entwickler sehen dies skeptisch. Elogind versucht eine Reihe von Diensten bereitzustellen, die von Desktops beim Login benötigt werden. Um das unter Umgehung von Systemd zu erreichen, implementiert es Bibliotheken, die sowohl im Konflikt mit libsystemd0 und systemd stehen als auch diese ersetzen. Zusätzliche Komplexität entsteht dadurch, dass dazu Funktionen von APT und DPKG eingesetzt werden. Daraus unter Umständen entstehende Probleme beschreibt ein weiterer Bugreport.

Fehlende Kommunikation

Hartman stellt fest, dass die Kommunikation zwischen den beteiligten Teams zur Lösung dieses zunächst rein technischen Problems nicht funktioniert. Da er als DPL und nicht das Technische Komitee zur Lösung des Konflikts herangezogen wurde, fragt er sich, welche anderen, nicht-technischen Gründe hier hineinspielen.

Er macht dann im weiteren Verlauf die Belastung der Entwickler allgemein mit verantwortlich, die bei einigen bis zur emotionalen Erschöpfung reicht. Wenn nicht alle Beteiligten sich an einer Lösung beteiligen können oder wollen, kann niemand sie dazu zwingen.

General Resolution möglich

Hartman sieht eine Situation heraufziehen, in der das Einholen der Standpunkte aller Entwickler des Projekts zur Frage der Unterstützung von Init-Systemen nötig sein wird. Das Werkzeug dazu heißt bei Debian »General Resolution« (GR) oder auch »Allgemeine Abstimmung« und bittet die Entwickler, ihre Meinung zu einer Reihe von vordefinierten Fragen zu einem Thema zu sagen.

Die Bekräftigung der Unterstützung für SysVinit und Elogind wäre eine der möglichen Ergebnisse einer solchen GR . Es könnte allerdings auch in der Erkenntnis enden, dass Debian nicht mehr willens und in der Lage ist, alternative Init-Systeme neben Systemd weiterhin zu pflegen. Ein Indiz dafür, dass die Unterstützung für SysVinit abnimmt, sind die 1033 Pakete, die neben der systemd.service.unit kein init.d-Script für SysVinit mehr haben.

Das Ende der Pflege von SysVinit würde nicht nur den Beschluss des letzten GR zu Systemd negieren, sondern könnte auch zum Problem werden, falls Debian einmal Systemd den Rücken kehren wollte.

Kommentare

6 Antworten zu „Debian diskutiert wieder über Init-Systeme“

  1. Avatar von Alf Gaida
    Alf Gaida

    > Das Ende der Pflege von SysVinit würde nicht nur den Beschluss des letzten GR zu Systemd negieren, sondern könnte auch zum Problem werden, falls Debian einmal Systemd den Rücken kehren wollte.

    .. unter der Voraussetzung, dass man dann wieder zu einem System welches kompatibel zu sysv wäre zurückkehrt. Erscheint mir recht unwahrscheinlich, aber nicht unmöglich. Ein weiterer Punkt sind Erweiterungen der sysv-scripte durch distributionsspezifiesche Anpassungen wie Runlevel-Steuerung und die Verwaltung von Abhängigkeiten – hier gingen in den letzten Jahren verschiedene Distributionen recht eigene Wege, was die Verwendung von RL betraf. Das würde also in jedem Fall witzig werden und am Besten durch einen wie auch immer gearteten Generator erledigt werden. Die Klarheit der Implementation der systemd-units würde das auch unbedingt vereinfachen.

  2. Avatar von anonym
    anonym

    IMHO sollte man die Sache pragmatisch angehen und feststellen, ob Debian überhaupt noch in nennenswertem Umfang ohne Systemd genutzt wird und ob es genug Freiwillige gibt, die die damit Verbundene Arbeit übernehmen wollen. Ist das nicht der Fall, sollte man SysVinit rauswerfen. Irgendwelche GAs kann man sich sparen, wenn nicht gleichzeitig geklärt wird, wer dann die Arbeit macht.

    Am Ende wird man sich aber wieder nicht entscheiden und das Thema weiter verschieben und irgendwann ist mit SysVinit dann doch Schluss, einfach weil es niemand mehr unterstützen will.

  3. Avatar von Klaus Meier
    Klaus Meier

    Da kann ich wieder nur lachen. Ja, ich nutze Gentoo und da gibt es so ein Problem nicht. Da kann man sich das System so konfigurieren, wie es einem passt. Liegt halt an der Flexibilität, die man durch die USE-Flags hat. So etwas gibt es ja bei Debian nicht.Aber warum hat man nicht schon damals beide Init-Systeme parallel gepflegt? Jetzt wieder zurück ist doch so gut wie unmöglich. Besonders, weil man sich ja auf Gnome als Standard-Desktop festgelegt hat. Und der läuft nur noch mit systemd. Außer man nutzt gentoo, die haben die Abhängigkeit von Systemd entfernt, so dass es auch ohne läuft. Aber da hat sich Debian zu tief in die Abhängigkeit von Systemd begeben, als das sie da noch mal rauskommen.

    1. Avatar von Ferdinand

      Die wollen ja auch jetzt nicht von Systemd weg. Es ist rein hypothetisch in eine mögliche Zukunft gedacht. Ist SysVinit dann noch vorhanden, geht der Umstieg leichter.

  4. Avatar von Klaus Meier
    Klaus Meier

    Aber diesen Weg haben sie sich doch selber verbaut. Sie haben auf Systemd gesetzt ohne irgend eine Alternative. Was zum Fork geführt hat. SysVinit wurde ja alternativlos entsorgt.

    Also nun erst mal keine Kritik an Systemd. Ich nutze es und ich liebe es, nur damit da kein Missverständnis aufkommt. Es ist nicht nur etwas, um das System zu starten, sondern auch, um es zu konfigurieren. Ok, hat bei Ubuntu noch keiner mitbekommen. Ich habe mir ein Scipt erstellt, mit dem die ganze Konfiguration automatisch passiert. Bei SysVinit musste man da dutzende Dateien editieren.

    Man hat sich in eine Einbahnstraße manövriert und fängt jetzt an zu jammern, weil man gemerkt hat, dass es eine Einbahnstraße ist. Warum ist man nicht ideologiefrei offen?

    1. Avatar von Ferdinand

      Da hast Du was falsch verstanden. Was Du da schreibst, wird von Systemd-Gegnern gerne kolportiert, stimmt aber so nicht.Ich zitiere mal das Debian-Wiki zu init:
      »The system initialization process is handled by the init daemon. In squeeze and earlier releases, that daemon is provided by the sysvinit package, and no alternatives are supported. In wheezy, the default init daemon is still sysvinit, but a „technology preview“ of systemd is available. In jessie and stretch, the default init system is systemd, but switching to sysvinit is supported.

      Since jessie, only systemd is fully supported; sysvinit is mostly supported, but Debian packages are not required to provide sysvinit start scripts. runit is also packaged, but has not received the same level of testing and support as the others, and is not currently supported as PID 1.«
      Und ein Umstieg ist so einfach wie: apt-get install sysvinit-core, gefolgt von einem Reboot. Dabei sollte man dann allerdings kein Gnome nutzen, wie Du bereits angemerkt hast Runit funktioniert derzeit leider nicht in Debian Stable, dafür aber in Sid.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert