Was unterscheidet systemd von anderen init-Systemen?

Es ist nicht ganz offiziell, aber es sieht so aus, als käme systemd zu Debian, und nachdem ich einige der heftigen Diskussionen auf der Mailingliste über diese Entscheidung gelesen habe, bin ich gespannt, wie polarisierend systemd unter Linux-Benutzern ist. Ich verwende Debian- (sysvinit) und Gentoo- (OpenRC) Systeme und weiß nichts Konkretes über systemd, obwohl es so aussieht, als ob es mir in den Weg kommt.

Ich habe gesehen, dass diese verwandte Frage das Für und Wider von systemd vs upstart fragt, aber es sind 3 Jahre vergangen, seit diese Frage veröffentlicht wurde und ich bin sicher, dass sich die Dinge in dieser Zeit geändert haben.

Meine Frage ist: Wie vergleicht sich systemd mit anderen init-Systemen?

• Was zeichnet es aus - was können die anderen init-Systeme dagegen?
• Gibt es etwas zu verlieren beim Wechsel von einem anderen Init-System?
• Wie verhält sich die Administration von systemd zu den anderen?

Wahrscheinlich finden Sie alles, was Sie wissen möchten, hier auf den " Debate Init System To Use " -Seiten, die das Debian-Projekt zusammengestellt hat, um die Entscheidung zu treffen, mit welchem ​​Initsystem Sie arbeiten möchten. Auf dieser Seite befindet sich ein separater Link zu jeder Auswahl von initsystems.

• Debatte initsystem Emporkömmling
• Debatte initsystem systemd

Für eine Einführung in Systemd enthält diese Seite so ziemlich alles, was man wissen muss, um damit zu beginnen. RHEL7: Erste Schritte mit Systemd .

Zusätzliche Ressourcen, die ich hilfreich fand, um ein besseres Verständnis der beiden Hauptoptionen zu erhalten. Ich habe auch die Wikipedia-Seiten zu den jeweiligen Technologien gelesen:

• https://en.wikipedia.org/wiki/Upstart
• https://en.wikipedia.org/wiki/Systemd

Das Gentoo-Projekt bietet auch einen guten Vergleich einiger der wichtigsten Funktionen in den verschiedenen Initsystemen:

• Diskussion: Vergleich von init-Systemen

Ich nehme Ihre Fragen an

F # 1: Wie vergleicht sich systemd mit anderen init-Systemen?

Dies ist eine sehr schwierige Frage, die im Rahmen einer SE-Antwort beantwortet werden muss. Ich möchte mich daher lieber den verschiedenen Quellen widmen, auf die ich oben verwiesen habe. Ich werde das allerdings sagen. Beim Lesen eines Großteils der Artikel über systemddie Alternativen wird versucht, viele Aspekte der Mängel früherer Tools zum Starten von Diensten auf Linux-Systemen zu behandeln. Es hat ein sehr durchdachtes Design und versucht, es in einer sehr modularen Weise bereitzustellen.

Daher würde ich sagen, dass IMO sowohl hinsichtlich des Aufwands beim Entwurf als auch der Ausführung dieses Entwurfs und der Übernahme durch mehrere größere Linux-Distributionen einen sehr günstigen Vergleich darstellt.

F # 2: Was zeichnet es aus - was kann es, was die anderen Init-Systeme nicht können?

Das sind viele Dinge, sytemddie andere Systeme nicht können. Wahrscheinlich sind 3 seiner stärksten Merkmale:

1. Protokollierung
2. Ressourcenbeschränkung
3. Umgang mit Dämonen, die sich teilen

1. Protokollierung

Auf der Logging-Front systemdhat ein neues Logging-System namens "Journal" den Dienst aufgerufen systemd-journald.service. Dies ist ein eigenes Thema. Weitere Informationen hierzu finden Sie in diesem Artikel mit dem Titel: Introducing the Journal . Hier ist ein Beispiel eines Benutzers, "harald", der sich anmeldet.

_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500

2 & 3. Ressourcenbegrenzung & Daemons, die sich teilen

systemdverwendet hier einen neuartigen Ansatz, bei cgroupsdem alle Dienste, für die ein Verzweigen oder Beschränken des Zugriffs auf Ressourcen erforderlich ist, sowohl begrenzt als auch begrenzt werden.

Auszug

Systemd hat eine sehr clevere Lösung für das Problem der Verfolgung von Daemons, die von diesem Fork stammen und zufällig gleichzeitig die Ressourcenbeschränkung handhaben. Wenn Upstart ptrace verwendet, um das Forking zu überwachen, führt systemd jeden Daemon in einer Kontrollgruppe aus (erfordert Linux 2.6.24 oder neuer), aus der es mit beliebig viel Forking nicht entkommen kann. Dies ermöglicht eine einfache Ressourcenbegrenzung, sowohl für forkende als auch für nicht forkende Daemons, da Kontrollgruppen für diese Art von Dingen erstellt wurden.

Quelle: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

F # 3: Gibt es etwas zu verlieren, wenn Sie von einem anderen Init-System darauf wechseln?

Die wahrscheinlich größte Einschränkung beim Umstieg auf systemd über Upstart oder sysV init besteht darin, dass viele neue Komplexitäten in Kauf genommen werden müssen. Systemd hat viele bewegliche Teile und ist äußerst funktionsreich. Mit diesen zusätzlichen Funktionen verbringen Sie wahrscheinlich eine ganze Menge Zeit damit, sich ein Bild davon zu machen, wie alles funktioniert.

F # 4: Wie verhält sich die Administration von systemd zu den anderen?

Wie in meiner obigen Antwort auf Q # 3 angegeben. Ich werde hier noch einmal wiederholen. Während es für sysV init relativ trivial war, in wenigen Stunden bis Tagen das Verwalten und Navigieren zu erlernen, werden Sie bei Upstart wahrscheinlich eine Woche oder länger brauchen, um auf den neuesten Stand zu kommen, während systemd Sie wahrscheinlich viel länger brauchen wird Wochen, um genug flüchtiges Wissen darüber zu erlangen, wo ich in der Lage sein werde, meine eigenen .serviceDateien zu erstellen und Dienste mit der gleichen Leichtigkeit zu stoppen / starten, die ich jetzt mit sysV init genieße.

Verweise

• Linux-Startvorgang
• Schwerwiegende Syslog-Probleme?
• Manpage systemd-journald.service