Skip to content

Gründe für den Wechsel von upstart zu systemd?

Unsere Starforscher haben ihre Kaffeetanks geleert und täglich nach der Lösung gegraben, bis Marco die Lösung auf Gitea gefunden hat, also teilt er sie jetzt hier.

Lösung:

Laienbenutzer sollten nicht Änderungen bemerken, das ist so gewollt. Es ist ein Init-System, nicht etwas, mit dem die Benutzer traditionell interagieren. Es sollte die von Upstart bereitgestellte Funktionalität vollständig ersetzen - und ein paar zusätzliche Dinge tun - aber das einzige Mal, dass ein nicht-technischer Benutzer sehen. ist, wenn es schief geht.

Benutzer, Sysadmins und Entwickler, die Upstart aktiv nutzen und dafür entwickeln, sind die Leute, die sich um die Dinge kümmern müssen. Es gibt ein Migrationsdokument im Ubuntu-Wiki, das Entwicklern hilft, ihre Init-Skripte zu konvertieren, aber Benutzer und Systemadministratoren können Upstart weiter verwenden, indem sie bei 14.04 bleiben (das bis 2019 unterstützt wird).

Der Grund und die Begründung für die Änderung kamen nicht von Ubuntu selbst. Canonical war mit Upstart (ihrem Projekt) zufrieden, aber viele Debian-Benutzer wollten zu einer modernen Init-Engine wechseln, um eine bessere Gleichzeitigkeit beim Booten und eine bessere Überwachungsfunktion für alle Dienste zu erhalten.

Das bedeutete einen Kampf zwischen verschiedenen Optionen (die Begründungen) und systemd gewann schließlich.

Canonical hat sich für Debian entschieden, weil es am einfachsten und wahrscheinlich am besten ist. Sie können ein Projekt fallen lassen und müssen sich nicht mit dem Upstream herumschlagen. Es bringt uns auch auf eine Linie mit anderen Distributionen (Red Hat, Fedora, etc.), die ebenfalls auf systemd umsteigen. Mehr Fokus und weniger doppelter Aufwand.

tl;dr Für einen Nicht-Techniker sollte dies überhaupt keine Auswirkungen haben. Für Ubuntu sollte es weniger Arbeit und ein besseres Init-System bedeuten.

Könnte jemand einem nicht-technischen Benutzer angemessen erklären, wie und ob dies überhaupt Auswirkungen auf uns hat?

Theoretisch sollte dies keine Auswirkungen auf den nicht-technischen Endbenutzer haben, der sich nicht mit den Feinheiten der Funktionsweise des Systems beschäftigt. In der Praxis werden Sie eine Menge Dinge sehen.

Hier ist eine unvollständige Liste:

  • Wenn Sie Zusatzsoftware hatten, die Uptart-Job-Definitionsdateien zum Starten von Programmen verwendet, werden diese nicht mehr funktionieren. Sie müssen systemd installieren (und möglicherweise selbst schreiben, aber meistens klauen Sie es einfach von jemandem, der es bereits geschrieben hat). Diensteinheit Dateien. Beispiel: https://askubuntu.com/questions/613785
  • Verschiedene Design-Annahmen der systemd-Entwickler über Dinge wie die Energieverwaltung führen zu Standardeinstellungen, die im Widerspruch zu dem stehen, woran Sie sich vielleicht gewöhnt haben. Die systemd-Entwickler haben sehr genaue Vorstellungen davon, was als Reaktion auf das Einschalten des Deckels bei Laptops geschehen soll.
  • Wenn Sie den proprietären nvidia-Anzeigetreiber verwenden, dann gibt es verschiedene Designentscheidungen in systemd, die Sie betreffen. Beispiel: https://askubuntu.com/questions/613773
  • Es ist nicht wirklich relevant, wenn man von Ubuntu kommt, da Ubuntu-Benutzer schon seit einigen Jahren eine Handbuchseite haben, die sie darüber informiert, aber ich erwähne es für die Nicht-Ubuntu-Benutzer, die dies lesen könnten: Benutzer anderer Linux-Betriebssysteme, die von System 5 kommen init+rc kommen, sind von der Tatsache geplagt, dass systemd nur abwärtskompatibel mit System 5 ist rc. Wie Uptart, und in der Tat die meisten anderen Systeme, behauptet und liefert es keine Abwärtskompatibilität mit System 5 init und seine Konfigurationsdatei /etc/inittab.

    Leute, die den Ratschlägen der Leute aus den letzten 30 Jahren gefolgt sind, die sagten: "Nun, du kannst das einfach in /etc/inittab ...", oder Leute, die Software benutzen, die diesen Rat befolgt haben, haben jetzt Software, die nicht mit Bootstrap startet. Beispiel: https://unix.stackexchange.com/a/196197/5132

  • Sie können nicht zu Einzelbenutzermodus über den systemd shutdown Befehl, wie man es mit dem früheren shutdown Befehlen. Abgesehen von der Tatsache, dass es sich um Rettungsmodus genannt wird, wird der Rettungsmodus in der systemd-Weltanschauung nicht als ein heruntergefahrener Zustand betrachtet. Er wird betrachtet als ein läuft Zustand. shutdown now schaltet die Maschine aus. Es ist systemctl rescue um den Einzelbenutzermodus in der systemd-Welt zu erreichen. Weitere Lektüre: https://unix.stackexchange.com/a/196471/5132
  • Zu diesem letzten Thema: Wenn Sie die Idee noch nicht verworfen haben. Ebenen laufen lassen noch nicht verworfen haben, ist es jetzt an der Zeit, dies zu tun. Lesen Sie weiter: https://unix.stackexchange.com/a/196014/5132
  • Sie werden vorsichtig sein müssen, wenn Sie allgemeine systemd-Ratschläge befolgen, die Sie durch zufälliges Stöbern im WWW gefunden haben, weil Sie "wissen", dass "jetzt alles systemd ist". Du wirst Leute sehen, die über die Ausführung von Befehlen mit dem --user Option zu systemctl. Das trifft auf Ubuntu (noch) nicht zu. upstart und systemd unterscheiden sich in diesem Bereich erheblich, und Ubuntu Version 15 verwendet immer noch die upstart per-session init anstelle eines systemd pro-Benutzer-Instanz. So gilt https://superuser.com/a/860598/38062 zum Beispiel nicht. ☺

Wie andere hier bereits angemerkt haben, sollte dies in der Theorie den nicht-technischen Endbenutzer nicht betreffen - und in der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, aber in der Praxis schon.

Klärung

Ich denke, ein paar Dinge, die hier gepostet wurden, bedürfen der Klärung:

Es handelt sich um ein Init-System, nicht um etwas, mit dem die Benutzer üblicherweise interagieren.

Das war bei SysV init und bei Upstart der Fall, aber bei systemd ist das nicht mehr der Fall. Es macht eine Menge Dinge, mit denen Benutzer traditionell interagieren:

  • https://cgit.freedesktop.org/systemd/systemd/tree/NEWS

Es sollte die von Upstart bereitgestellte Funktionalität vollständig ersetzen
-und ein paar zusätzliche Dinge tun

Zwei Dinge sind zu klären - erstens über den vollständigen Ersatz von Upstart:

Keine SysV-Init-Skripte

Eines der Probleme, die die Leute mit systemd haben, ist, dass es keine SysV-Init-Skripte ausführt. So gibt es ein Beispiel, dass es nicht die von Upstart bereitgestellte Funktionalität nicht vollständig ersetzt.

Das ist etwas, auf das wir uns seit über 30 Jahren verlassen konnten, und traditionell schrieb man SysV-Init-Skripte für maximale Portabilität, ohne sich zu wiederholen (indem man mehrere Versionen der gleichen Skripte schrieb), was heute nicht mehr der Fall ist.

Dies sollte kein Problem sein, wenn man nur Pakete aus offiziellen Repositories verwendet, da vermutlich alle Pakete, die früher entweder SysV-Init- oder Upstart-Skripte hatten, ihre Skripte neu schreiben müssen, bevor sie gepackt werden.

Es wird nur ein Problem für Leute sein, die zufällig irgendwelche Drittanbieter- oder benutzerdefinierte Software verwenden, die ihre Init-Skripte entweder für SysV-Init oder für Upstart geschrieben haben, und diese werden die Init-Skripte neu schreiben müssen, bevor sie auf ein System mit systemd upgraden (oder Upstart installieren lassen, was auch eine Option ist, oder auf ein System migrieren, das systemd nicht verwendet).

Es gibt den systemd-sysv-generator, der automatisch SysV-Init-Skripte in systemd-Skripte übersetzen soll, aber es gibt einige Fehler und eine lange Liste expliziter Inkompatibilitäten.

Nun die zweite Klarstellung - zu den paar zusätzlichen Dingen:

Ein paar zusätzliche Dinge

Diese "wenigen zusätzlichen Dinge", die systemd abdecken wird - laut der Präsentation A Perspective for systemd - What Has Been Achieved, and What Lies Ahead
von Lennart Poettering im Jahr 2014 auf GNOME.asia - sind die folgenden:

  • Init-System
  • Journal-Protokollierung
  • Login-Verwaltung
  • Geräteverwaltung
  • Verwaltung von temporären und flüchtigen Dateien
  • Registrierung von Binärformaten
  • Speichern/Wiederherstellen der Hintergrundbeleuchtung
  • rfkill speichern/wiederherstellen
  • bootchart
  • Readahead
  • Einrichtung verschlüsselter Speicher
  • Erkennung von EFI/GPT-Partitionen
  • Registrierung von virtuellen Maschinen/Containern
  • Container-Verwaltung
  • Verwaltung von Hostnamen
  • Gebietsschema-Verwaltung
  • Zeitmanagement
  • Verwaltung der Zufallsgeneratoren
  • Verwaltung der sysctl-Variablen
  • Konsolen-Verwaltung
  • Introspektion
  • Automatische Erkennung
  • Plug and Play
  • Netzwerk-Management
  • systemd-networkd
  • DNS-Cache
  • mDNS-Beantworter
  • LLMNR-Beantworter
  • DNSSEC-Überprüfung
  • IPC im Kernel
  • kdbus
  • sd-bus
  • Zeitsynchronisation mit NTP
  • systemd-timesyncd
  • Integration mit Containern
  • Sandboxing von Diensten
  • Sandboxing von Anwendungen
  • OS-Image-Format
  • Container-Image-Format
  • App-Image-Format
  • GPT mit automatischer Erkennung
  • Zustandslose Systeme
  • instanziierbare Systeme
  • Werksreset
  • Knoteninitialisierung und Aktualisierung
  • Integration in die Cloud
  • Knotenübergreifende Verwaltung von Diensten
  • Überprüfbare Betriebssystem-Images bis hin zur Firmware
  • Boot-Laden
  • Aufbau des Internet-Betriebssystems der nächsten Generation Vereinheitlichung sinnloser Unterschiede zwischen den Distributionen

Also zurück zum Thema: "Es ist ein Init-System, nicht etwas, mit dem die Benutzer traditionell interagieren." - Es muss darauf hingewiesen werden, dass das Init-System nur ein Punkt auf dieser Liste ist.


Und schließlich der letzte Punkt, den ich kommentieren möchte:

[T]Der einzige Zeitpunkt, an dem ein nicht-technischer Benutzer dies sehen wird, ist, wenn es schief geht.

Oh, was für eine Erleichterung 🙂

Änderungen

Die bemerkenswertesten Änderungen für Endbenutzer (abgesehen von den Skripten selbst) sind das Starten und Beenden von Diensten und die Verwendung von Befehlen wie:

  • screen
  • tmux
  • nohup

die nicht mehr wie erwartet funktionieren. Zum Beispiel, nohup ist ein POSIX-Befehl, der sicherstellt, dass der Prozess weiterläuft, nachdem Sie sich von Ihrer Sitzung abgemeldet haben. Er funktioniert nicht mehr unter systemd. Auch Programme wie screen und tmux müssen auf eine besondere Art und Weise aufgerufen werden, sonst werden die Prozesse, die man mit ihnen ausführt, beendet (während es normalerweise der Hauptgrund ist, screen oder tmux überhaupt auszuführen, um diese Prozesse nicht zu beenden).

Dies ist kein Fehler, sondern eine Design-Entscheidung, die in Zukunft wahrscheinlich nicht behoben werden wird. Dies ist, was Lennart Poettering über dieses Problem gesagt hat:

Meiner Meinung nach war es eigentlich ziemlich seltsam von UNIX, dass es standardmäßig beliebigen Benutzercode nach dem Abmelden uneingeschränkt weiterlaufen ließ. Es wurde schon seit Ewigkeiten unter vielen OS-Leuten diskutiert, dass dies möglich sein sollte, aber sicherlich nicht die Voreinstellung sein sollte, aber niemand hat es bisher gewagt, den Schalter umzulegen, um es von einer Voreinstellung zu einer Option zu machen. Benutzersitzungen nach dem Abmelden nicht aufzuräumen ist nicht nur hässlich und etwas hakelig, sondern auch ein Sicherheitsproblem. systemd 230 hat nun endlich den Schalter umgelegt und räumt nun standardmäßig alles korrekt auf, wenn sich der Benutzer abmeldet.

Für weitere Infos siehe:

  • Systemd beginnt standardmäßig mit dem Töten der Hintergrundprozesse
  • Systemd v230 beendet Hintergrundprozesse, nachdem sich der Benutzer abgemeldet hat, unterbricht den Bildschirm, tmux
  • Debian-Fehler #825394: systemd beendet Hintergrundprozesse, nachdem sich der Benutzer abgemeldet hat

Laufend screen

  • upstart:screen
  • systemd:systemd-run --user --scope screen

(Hinweis: das Verhalten von "upstart" oben ist wirklich alles außer systemd, dies ist nicht upstart-spezifisch)

Starte Job foo:

  • upstart:start foo
  • systemd:systemctl start foo

Stopping job foo:

  • upstart:stop foo
  • systemd:systemctl stop foo

Neustart von Job foo:

  • upstart:restart foo
  • systemd:systemctl restart foo

Auflistung von Aufträgen mit ihrem Status:

  • upstart:initctl list
  • systemd:systemctl status

(Siehe meine Antwort auf Was sind die Vor- und Nachteile von Upstart und systemd? für weitere Details, die den Rahmen dieser Frage sprengen würden).

Protokolle:

Es gibt auch einen großen Unterschied im Umgang mit den Logs, denn entgegen der Unix-Tradition werden die Logs von systemd in Binärdateien in einem eigenen Format gespeichert, also statt:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

müssen Sie spezielle Befehle verwenden, um auf Ihre Protokolle zuzugreifen:

sudo journalctl -u foo
sudo journalctl -u foo -f

Kontroversen

Die Einführung von systemd zunächst in Debian und später in Ubuntu verlief nicht ohne Kontroversen und großen Widerstand, wie jeder weiß, der einen der folgenden Artikel geschrieben hat:

  • Lernen Sie Devuan kennen, den Debian-Fork, der aus einer erbitterten systemd-Revolte entstand (PCWorld)
  • Grab your pitchforks: Ubuntu wird am Montag auf systemd umgestellt (The Register)
  • Linus Torvalds und andere über Linux's systemd (ZDNet)
  • Über die systemd-Kontroverse (Errata Security)

Die offizielle Debian-Position zu systemd und die daraus resultierende Kontroverse hat 2014 zur Exodus-Erklärung geführt und endete mit dem Rücktritt von Ian Jackson.

Die Init-Freiheit, Without-Systemd.org und Systemd-Free.org Initiativen entstanden, die auf Hacker News viel diskutiert wurden.

Weitere Lektüre

  • Traurige Nachrichten heute: systemd-resolved wird in Ubuntu 16.10 von Paul Wouters eingesetzt
  • Argumente gegen systemd auf Ohne Systemd
  • Liste der Inkompatibilitäten von systemd mit SysV (offizielle Dokumente)
  • Upstart unter Ubuntu 15.04 wieder einschalten von Derrik Diener
  • systemd sysv init Kompatibilitätsmodus: wie es funktioniert und Fehlerbehebung, wenn es nicht funktioniert
  • Was sind die Vor- und Nachteile von Upstart und systemd? auf unix.stackexchange.com

Wir wissen es zu schätzen, dass Sie unseren Aufsatz beleben möchten, indem Sie einen Kommentar zeigen und ihn bewerten. Wir begrüßen Sie.



Nutzen Sie unsere Suchmaschine

Suche
Generic filters

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.