Was sind die Vor- / Nachteile von Upstart und systemd?

183

Es sieht so aus, als wäre systemd das brandneue Init- System auf dem Block, so wie Upstart es vor einigen Jahren war. Was sind die Vor- / Nachteile für jeden? Wie ist der Vergleich mit anderen Init-Systemen?

init upstart systemd Tshepang
quelle
4
@keith iirc openrc verwendet einfach SysV den Vorteil , eine gut gestaltete Sammlung von Startskripts, die gemeinsame Komponenten verwenden und tragbar sind (Arbeit an jedem beliebigen Shell Bedeutung) Es ist eine gute Bereinigung, aber nicht wirklich eine neue initd
xenoterracide
@xeno Das tut es, aber man kann es nicht wirklich sagen. Es gibt überhaupt keine rcX.d- oder [KS] -Symlinks. Tatsächlich ist sysv init selbst ziemlich flexibel und die Runlevel werden nicht wirklich auf die übliche Weise verwendet.
Keith
Obwohl der Autor dieses Blogs gegen systemd ist, schlage ich vor, dies zu lesen. Es geht über die Vor- und Nachteile von systemd und BSD init. textplain.net/blog/2015/…
Peschke
1
Bitte lesen Sie auch das 2016-Update unter unix.stackexchange.com/a/287282/49091 .
Igaurav
Angebliche Vorteile von systemd werden in 100 Jahren nicht die Kosten ausgleichen, die der Welt bereits durch die Implementierung entstehen. Jede Minute, jede Stunde oder jeder Tag, die ein Unix-Administrator für die Behandlung dieses Mülls aufgewendet hat, muss sich bereits auf Milliarden belaufen und für welche echten Vorteile außer ein paar Schnickschnack?
Waslap

Antworten:

90

Update 2016

Die meisten Antworten hier sind fünf Jahre alt, also ist es Zeit für ein paar Updates.

Ubuntu verwendete standardmäßig upstart, aber sie gaben es letztes Jahr zugunsten von systemd auf - siehe:

Aus diesem Grund gibt es einen schönen Artikel über Systemd für Upstart-Benutzer im Ubuntu-Wiki - einen sehr detaillierten Vergleich zwischen upstart und systemd und eine Übergangsanleitung von upstart zu systemd.

(Beachten Sie, dass Sie laut Ubuntu-Wiki immer noch einen Upstart auf aktuellen Versionen von Ubuntu ausführen können, indem Sie das upstart-sysvund das ausführen. Angesichts sudo update-initramfs -udes Umfangs des systemd-Projekts weiß ich nicht, wie es in der Praxis funktioniert oder ob systemd funktioniert oder nicht möglich zu deinstallieren.)

Die meisten Informationen in den folgenden Abschnitten "Befehle" und "Skripte" stammen aus einigen Beispielen, die in diesem Artikel verwendet wurden (die wie die Beiträge von Stack Exchange-Benutzern unter der Creative Commons Attribution-ShareAlike 3.0-Lizenz lizenziert sind ).

Hier finden Sie einen schnellen Vergleich von allgemeinen Befehlen und einfachen Skripten. In den folgenden Abschnitten finden Sie detaillierte Erklärungen. Diese Antwort vergleicht das alte Verhalten von Upstart-basierten Systemen mit dem neuen Verhalten von systemd-basierten Systemen, wie in der Frage gestellt. Beachten Sie jedoch, dass die mit "Upstart" gekennzeichneten Befehle nicht unbedingt Upstart-spezifisch sind - es handelt sich häufig um Befehle, die dies tun sind allen systemfremden Linux- und Unix-Systemen gemeinsam.

Befehle

Laufen su:

  • Emporkömmling: su
  • systemd: machinectl shell

(Siehe Abschnitt "su command replacement" weiter unten)

Laufender Bildschirm:

  • Emporkömmling: screen
  • systemd: systemd-run --user --scope screen

(siehe Abschnitt "Unerwartetes Beenden von Hintergrundprozessen" weiter unten)

Tmux ausführen:

  • Emporkömmling: tmux
  • systemd: systemd-run --user --scope tmux

(siehe Abschnitt "Unerwartetes Beenden von Hintergrundprozessen" weiter unten)

Berufseinstieg foo:

  • Emporkömmling: start foo
  • systemd: systemctl start foo

Job beenden:

  • Emporkömmling: stop foo
  • systemd: systemctl stop foo

Job foo neu starten:

  • Emporkömmling: restart foo
  • systemd: systemctl restart foo

Jobs auflisten:

  • Emporkömmling: initctl list
  • systemd: systemctl status

Konfiguration von job foo überprüfen:

  • Emporkömmling: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Umgebungsvariablen des Jobs auflisten:

  • Emporkömmling: initctl list-env
  • systemd: systemctl show-environment

Umgebungsvariable des Jobs festlegen:

  • Emporkömmling: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Umgebungsvariable des Jobs entfernen:

  • Emporkömmling: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Protokolle

In upstart sind die Protokolle normale Textdateien im Verzeichnis / var / log / upstart, sodass Sie sie wie gewohnt verarbeiten können:

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

In systemd werden Protokolle in einem internen Binärformat gespeichert (nicht als Textdateien). Sie müssen daher den journalctlBefehl verwenden, um darauf zuzugreifen:

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

Skripte

Beispiel für ein Upstart-Skript, geschrieben in /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Beispiel für ein systemd-Skript, geschrieben in /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

su befehl ersatz

In suPull-Anforderung Nr. 1022 wurde eine Befehlsersetzung in systemd zusammengeführt:

denn laut lennart poettering ist "su wirklich ein kaputtes konzept" .

Er erklärt, dass "Sie su und sudo wie zuvor verwenden können, aber nicht erwarten, dass es in vollem Umfang funktionieren wird " .

Der offizielle Weg zu einem suähnlichen Verhalten ist jetzt:

machinectl shell

Lennart Pöttering hat dies in der Diskussion zu Ausgabe 825 näher erläutert :

"Nun, es gab lange Diskussionen darüber, aber das Problem ist, dass das, was su tun soll, sehr unklar ist. [...] Um es kurz zu machen: su ist wirklich ein kaputtes Konzept. Es wird dir eine Art Hülle geben , und es ist in Ordnung, es dafür zu verwenden, aber es ist keine vollständige Anmeldung und sollte nicht mit einer verwechselt werden. " - Lennart Pöttering

Siehe auch:

Unerwartetes Beenden von Hintergrundprozessen

Befehle wie:

nicht mehr wie erwartet arbeiten . nohupEin POSIX-Befehl stellt beispielsweise sicher, dass der Prozess weiter ausgeführt wird, nachdem Sie sich von Ihrer Sitzung abgemeldet haben. Auf systemd funktioniert es nicht mehr . Auch Programme wie screenund tmuxmüssen auf besondere Weise aufgerufen werden, da andernfalls die Prozesse, die Sie mit ihnen ausführen, abgebrochen werden (wenn diese Prozesse nicht abgebrochen werden, ist dies in der Regel der Hauptgrund für die Ausführung von screen oder tmux).

Dies ist kein Fehler, es ist eine bewusste Entscheidung, daher ist es unwahrscheinlich, dass dies in Zukunft behoben wird. Das hat Lennart Pöttering zu diesem Thema gesagt :

Meiner Ansicht nach war es für UNIX eigentlich ziemlich seltsam, dass es nach dem Abmelden standardmäßig beliebigen Benutzercode uneingeschränkt herumstehen ließ. Unter vielen OS-Leuten wird seit Ewigkeiten diskutiert, dass dies möglich sein sollte, aber sicherlich nicht die Standardeinstellung, aber bisher wagte niemand, den Schalter zu betätigen, um ihn von einer Standardeinstellung in eine Option umzuwandeln. Das Bereinigen von Benutzersitzungen nach dem Abmelden ist nicht nur hässlich und etwas hackisch, sondern auch ein Sicherheitsproblem. systemd 230 hat jetzt endlich den Schalter umgelegt und standardmäßig alles richtig aufgeräumt, wenn sich der Benutzer abmeldet.

Für weitere Informationen siehe:

Hochrangiges Startup-Konzept

In gewisser Weise funktioniert systemd rückwärts - bei Aufrüstaufträgen werden sie so schnell wie möglich gestartet, und bei systemd-Aufträgen werden sie gestartet, wenn sie müssen. Letztendlich können die gleichen Jobs von beiden Systemen und in der gleichen Reihenfolge gestartet werden, aber Sie denken sozusagen aus einer entgegengesetzten Richtung darüber nach.

So erklärt es Systemd für Upstart-Benutzer :

Das Modell von Upstart zum Starten von Prozessen (Jobs) ist "greedy event-based", dh alle verfügbaren Jobs, deren Startereignisse eintreten, werden so früh wie möglich gestartet. Während des Startvorgangs synthetisiert upstart einige Anfangsereignisse wie startup oder rcS als "Baumstamm", die frühen Dienste werden auf diesen gestartet, und die späteren Dienste werden gestartet, wenn die ersteren ausgeführt werden. Ein neuer Job muss lediglich seine Konfigurationsdatei in / etc / init / installieren, um aktiv zu werden.

Das systemd -Modell zum Starten von Prozessen (Units) ist "Lazy Dependency-based", dh eine Unit startet nur, wenn eine andere Start-Unit davon abhängig ist. Während des Bootens startet systemd eine "root unit" (default.target, kann in grub überschrieben werden), die sich dann transitiv erweitert und ihre Abhängigkeiten startet. Eine neue Einheit muss sich selbst als Abhängigkeit von einer Einheit der Startsequenz (üblicherweise multi-user.target) hinzufügen, um aktiv zu werden.

Verwendung in Distributionen

Nun einige aktuelle Daten laut Wikipedia:

Distributionen, die standardmäßig upstart verwenden:

Distributionen, die standardmäßig systemd verwenden:

(Siehe Wikipedia für aktuelle Informationen)

Distributionen, die weder Upstart noch systemd verwenden:

Kontroverse

In der Vergangenheit wurde eine Abzweigung von Debian vorgeschlagen, um systemd zu vermeiden . Die Devuan GNU + Linux wurde erstellt - eine Abzweigung von Debian ohne Systemd (danke an fpmurphy1 für den Hinweis in den Kommentaren).

Weitere Informationen zu dieser Kontroverse finden Sie unter:

Wie viele von Ihnen vielleicht bereits wissen, war die von Ian Jackson beworbene Init GR Debian-Abstimmung nicht nützlich, um Debians Vermächtnis und seine Benutzer vor der Systemlawine zu schützen.

Diese Situation verspricht eine Sperrung von Systemabhängigkeiten, die de facto die Entwicklungsfreiheit bedroht und schwerwiegende Folgen für Debian, seinen Upstream und seinen Downstream hat.

Die CTTE hat es geschafft, eine Abhängigkeit auszutauschen und uns Zeit für eine subtile Installation von systemd über sysvinit zu gewinnen, aber selbst dieser Prozess war anstrengend und voller Drama. Letztendlich ist Ian Jackson vor einer Woche zurückgetreten. [...]

Ich trete mit sofortiger Wirkung aus dem Technischen Komitee aus.

Während es wichtig ist, dass die Ansichten der 30-40% des Projekts, die mit mir übereinstimmen, weiterhin im TC vertreten sind, bin ich selbst zu kontrovers, um dies zu tun. Ich sollte beiseite treten, um zu versuchen, das Ausmaß zu verringern, in dem Gespräche über die Projektleitung personalisiert werden. [...]

Devuan entstand aus einer Kontroverse über die Entscheidung, Debian als Standard-Init-System zu verwenden. Die offizielle Debian-Position zu systemd ist voll von Behauptungen, die andere entlarvt haben . Interessierte Leser können dieses heiße Thema in der Systemd-Kontroverse weiter diskutieren . Wir empfehlen Ihnen jedoch, Ihren Kopf kühl und Ihre Stimme höflich zu halten. Bei Devuan sind wir mehr daran interessiert, sie falsch zu programmieren als zurückzublicken. [...]

Einige Websites und Artikel zur Systemd-Kontroverse wurden erstellt:

Es gibt viele interessante Diskussionen in den Hacker News:

Ähnliche Tendenzen sind auch in anderen Distributionen zu beobachten:

Philosophie

upstart folgt der Unix-Philosophie von DOTADIW - "Do One Thing und Do It Well". Es ist ein Ersatz für den traditionellen Init-Daemon. Es wird nichts anderes getan, als Dienste zu starten und zu stoppen. Andere Aufgaben werden an andere spezialisierte Subsysteme delegiert.

systemd kann noch viel mehr. Neben dem Starten und Beenden von Diensten werden auch Kennwörter, Anmeldungen, Terminals, Energieverwaltung, Zurücksetzen auf die Werkseinstellungen, Protokollverarbeitung, Dateisystem-Bereitstellungspunkte, Netzwerke und vieles mehr verwaltet - einige der Funktionen finden Sie in der NEWS- Datei.

Pläne zur Erweiterung

Nach einer Perspektive für das Erreichte und das Bevorstehende von Lennart Pöttering auf GNOME.asia im Jahr 2014 sind hier die Hauptziele von systemd, die bereits abgedeckten und die noch laufenden Bereiche:

Systemziele:

Unsere Ziele

  • Verwandeln von Linux aus einer Tüte Bits in ein wettbewerbsfähiges Allzweck-Betriebssystem.
  • Aufbau des Internet-Betriebssystems der nächsten Generation Vereinheitlichen Sie sinnlose Unterschiede zwischen Distributionen

  • Bringen Sie Innovation zurück zum Kernbetriebssystem

  • Desktop, Server, Container, Embedded, Mobil, Cloud, Cluster,. . . Diese Bereiche sind näher beieinander, als Sie vielleicht denken

  • Reduzierung der Administratorkomplexität, Zuverlässigkeit ohne Aufsicht
  • Alles nachvollziehbar
  • Automatische Erkennung, Plug-and-Play ist der Schlüssel
  • Wir reparieren Dinge dort, wo sie kaputt sind, und kleben sie niemals auf

Bereits abgedeckte Bereiche:

Was wir bereits abdecken:

Init-System, Journal-Protokollierung, Anmeldeverwaltung, Geräteverwaltung, temporäre und flüchtige Dateiverwaltung, Binärformatregistrierung, Speichern / Wiederherstellen von Hintergrundbeleuchtung, Speichern / Wiederherstellen von Rfkills, Bootchart, Readahead, Einrichtung des verschlüsselten Speichers, EFI / GPT-Partitionserkennung, virtuelle Maschine / Container Registrierung, Minimalcontainerverwaltung, Hostnamenverwaltung, Gebietsschemaverwaltung, Zeitverwaltung, Zufallsgeneratorverwaltung, Systemvariablenverwaltung, Konsolenverwaltung,. . .

In Arbeit:

Woran wir arbeiten:

  • Netzwerk Management
  • systemd-networkd
  • Lokaler DNS-Cache, mDNS-Responder, LLMNR-Responder, DNSSEC-Überprüfung
  • IPC im Kernel
  • kdbus, sd-bus
  • Zeitsynchronisation mit NTP
  • systemd-timesyncd
  • Mehr Integration mit Containern
  • Sandboxing von Diensten
  • Sandboxing von Apps
  • OS-Image-Format
  • Container-Bildformat
  • App-Bildformat
  • GPT mit automatischer Erkennung
  • Zustandslose Systeme, instanziierbare Systeme, Werksreset
  • / usr ist das Betriebssystem
  • / etc ist eine (optionale) Konfiguration
  • / var ist der (optionale) Status
  • Atomknoten-Initialisierung und -Updates
  • Integration in die Cloud
  • Service Management über Knoten hinweg
  • Überprüfbare BS-Images
  • Bis zur Firmware
  • Boot wird geladen

Umfang dieser Antwort

Wie fpmurphy1 in den Kommentaren feststellte, "sollte darauf hingewiesen werden, dass systemd seinen Arbeitsumfang im Laufe der Jahre weit über den des Systemstarts hinaus erweitert hat."

Ich habe versucht, die meisten relevanten Informationen hier aufzunehmen. Hier vergleiche ich die allgemeinen Funktionen von Upstart und systemd, wenn sie als Init-Systeme verwendet werden. Ich erwähne nur Funktionen von systemd, die über den Umfang eines Init-Systems hinausgehen, da diese nicht mit Startup verglichen werden können, aber ihre Präsenz wichtig ist den Unterschied zwischen diesen beiden Projekten zu verstehen. Weitere Informationen finden Sie in der entsprechenden Dokumentation.

Mehr Info

Weitere Informationen finden Sie unter:

Extras

Das LinOxide- Team hat ein Systemd vs SysV Init Linux-Cheatsheet erstellt .

rsp
quelle
4
... und eine solche Abzweigung von Debian ist aufgetreten. Devuan GNU + Linux ist eine Abzweigung von Debian ohne System.
Fpmurphy
2
Es sei darauf hingewiesen, dass systemd im Laufe der Jahre seinen Tätigkeitsbereich weit über den des Systemstarts hinaus erweitert hat.
Fpmurphy
1
Hervorragender Beitrag und äußerst hilfreich für Cent-Typ. Vielen Dank, dass Sie sich die Zeit genommen haben, Sir !!!
origin1tech
4
@Ronsmith service <foo> start/stop/restart/statusnoch gut funktionieren. Wie die meisten Unix-Programme bietet systemd Befehlskompatibilität zu bekannten Standardeinstellungen.
Shadur
2
Sehr gute Antwort. Ein Punkt: Die BSD-Betriebssysteme sind keine Linux-Distributionen, sondern verschiedene Unix-Betriebssysteme mit eigenem Kernel.
Giorgio
68

Sowohl upstart als auch systemd sind Versuche, einige der Probleme mit den Einschränkungen des traditionellen SysV-Init-Systems zu lösen. Einige Dienste müssen beispielsweise nach anderen Diensten gestartet werden (zum Beispiel können Sie NFS-Dateisysteme erst bereitstellen, wenn das Netzwerk ausgeführt wird). Die einzige Möglichkeit in SysV, dies zu handhaben, besteht darin, die Links im Verzeichnis rc # .d festzulegen so dass einer vor dem anderen ist. Hinzu kommt, dass Sie möglicherweise alles später neu nummerieren müssen, wenn Abhängigkeiten hinzugefügt oder geändert werden. Upstart und Systemd verfügen über intelligentere Einstellungen zum Definieren von Anforderungen. Außerdem gibt es das Problem, dass alles ein Shell-Skript ist und nicht jeder die besten Init-Skripte schreibt. Dies wirkt sich auch auf die Startgeschwindigkeit aus.

Einige der Vorteile von systemd, die ich sehen kann:

  • Jeder gestartete Prozess erhält eine eigene cgroup oder eine bestimmte cgroup.
  • Vorab-Erstellung von Sockets und Datei-Handles für Dienste, ähnlich wie xinetd für seine Dienste, sodass abhängige Dienste schneller gestartet werden können. Beispielsweise wird systemd das Dateihandle für / dev / log für syslog geöffnet halten, und nachfolgende Dienste, die an / dev / log senden, werden ihre Nachrichten gepuffert, bis syslogd zur Übernahme bereit ist.
  • Es werden weniger Prozesse ausgeführt, um einen Dienst tatsächlich zu starten. Dies bedeutet, dass Sie kein Shell-Skript schreiben, um Ihren Dienst zu starten. Dies kann eine Geschwindigkeitsverbesserung sein und (IMO) etwas, das an erster Stelle einfacher einzurichten ist.

Ein Nachteil, den ich kenne, ist, dass viele Daemons gepatcht werden müssen, damit systemd die FH an sie weiterleitet, um die Socket- / FH-Vorbelegung von systemd nutzen zu können.

jsbillings
quelle
13
PulseAudio ist ein stark bösartiges Soundsystem ( pulseaudio.org ), das ursprünglich von Lennart Pöttering, dem Autor von systemd, geschrieben wurde. Ich habe hier hauptsächlich einen Witz gemacht, weil ich mehrere Leute kenne, die sich gerne über pulseaudio beschweren, und ich bin mir sicher, dass sie sich auch über systemd beschweren würden. Ehrlich gesagt hatte ich weder mit systemd noch mit pulseaudio ein Problem.
jsbillings
4
Macht einen fast zur Kiefer für die üppigen Fjorde von Plan9 ... alles ist eine Feile.
dhchdhd
4
Um ehrlich zu sein, war pulseaudio eine Lösung für ein nicht existierendes Problem. Es gibt nichts, was PA tun kann, was ALSA nicht kann, und ich habe immer wieder VIELE Leute gehört, die Probleme mit PA haben.
WhyNotHugo
3
Zwei Systemnachteile, die Sie verpasst haben: (1) Alle Startskripte müssen neu geschrieben werden. (2) Es gibt viel weniger Kompatibilität mit Nicht-Linux-Betriebssystemen (wie z. B. BSDs).
WhyNotHugo
8
Einfach toll. Bitte werfen Sie einen Blick auf 0pointer.de/blog/projects/the-biggest-myths . Ich habe das Wachstum von systemd miterlebt und kann bestätigen, dass viele der hier vorgebrachten Kritikpunkte völlig unbegründet sind. Unter dem Link finden Sie eine mit Gründen versehene Gegenargumentation.
Vonbrand
30

Saw wurde heute systemdauf Arch General ML erwähnt . Also lies es dir durch. Das H Online ist wie immer eine großartige Quelle für Linux-Technologie und hier habe ich meinen Platz gefunden, um Systemd als SysV Init- und Upstart-Alternative zu erforschen . Der H Online-Artikel (in diesem Fall) ist jedoch keine sehr nützliche Lektüre. Die eigentliche Verwendung dahinter besteht darin, dass er Links zu den nützlichen Lektüren enthält.

Die wirkliche Antwort liegt in der Ankündigung von systemd . Dies gibt einige wichtige Hinweise darauf, was mit SysV initd nicht stimmt und was neue Systeme tun müssen

  • Weniger anfangen.
  • Und mehr parallel zu beginnen.

Der Hauptplan hierfür scheint darin zu bestehen, Dienste nur nach Bedarf zu starten und einen Socket für diesen Dienst zu starten, damit der Dienst, der dies benötigt, eine Verbindung mit dem erstellten Socket herstellen kann, lange bevor der Dämon vollständig online ist. Anscheinend behält ein Socket eine kleine Menge gepufferter Daten bei, was bedeutet, dass während der Verzögerung keine Daten verloren gehen. Sie werden verarbeitet, sobald der Dämon online ist.

Ein weiterer Teil des Plans scheint darin zu bestehen, Dateisysteme nicht zu serialisieren, sondern diese bei Bedarf bereitzustellen, damit Sie nicht darauf warten /home/, dass sie usw. (nicht zu verwechseln /etc) bereitgestellt werden, und / oder fsckwann Sie es könnten Start-Daemons as /und /var/etc sind bereits gemountet. Es hieß, es würde zu diesem Zweck Autofs verwenden.

Es hat auch das Ziel, .desktopStyle-Init-Deskriptoren als Ersatz für Skripte zu erstellen . Dies wird Tonnen langsam verhindert shProzesse und noch mehr Gabeln von Prozessen von Dingen wie sedund grepdass oft in Shell - Skripten verwendet.

Sie planen auch, einige Dienste erst dann zu starten, wenn sie dazu aufgefordert werden, und sie möglicherweise sogar auszuschalten, wenn sie nicht mehr benötigt werden. Das Bluetooth-Modul und der Dämon werden beispielsweise nur benötigt, wenn Sie ein Bluetooth-Gerät verwenden. Ein weiteres Beispiel ist der ssh-Daemon. Dies ist die Art von Dingen, zu denen inetd fähig ist. Persönlich bin ich mir nicht sicher, ob mir das gefällt, da es möglicherweise zu Wartezeiten führen kann, wenn ich sie benötige, und im Falle von ssh denke ich, dass es eine mögliche Sicherheitslücke darstellt, wenn mein inetd kompromittiert wäre, würde das gesamte System betroffen sein. Ich wurde jedoch darüber informiert, dass dies nicht möglich ist, um gegen dieses System zu verstoßen. Wenn ich möchte, kann ich diese Funktion pro Dienst und auf andere Weise deaktivieren.

Ein weiteres Merkmal wird anscheinend die Fähigkeit sein, basierend auf Zeitereignissen entweder in regelmäßigen Intervallen oder zu einer bestimmten Zeit zu starten. Dies ist ähnlich zu dem, was crondund atdjetzt zu tun. Obwohl mir gesagt wurde, dass es den Benutzer "cron" nicht unterstützen wird. Persönlich klingt dies wie die sinnloseste Sache. Ich denke, dies wurde von Leuten geschrieben / ausgedacht, die nicht in Mehrbenutzerumgebungen arbeiten. Benutzer cron hat nicht viel Sinn, wenn Sie der einzige Benutzer auf dem System sind, außer dass Sie nicht als Root ausgeführt werden. Ich arbeite täglich an Mehrbenutzersystemen, und die Regel lautet immer, Benutzerskripte als Benutzer auszuführen. Aber vielleicht habe ich nicht die Voraussicht, die sie haben, und es wird in keiner Weise dazu führen, dass ich nicht laufen kann crondoder atd, also tut es niemandem weh, außer den Entwicklern, nehme ich an.

Der große Nachteil von systemd ist, dass einige Daemons modifiziert werden müssen, um den vollen Nutzen daraus zu ziehen. Sie funktionieren jetzt, aber sie funktionieren besser, wenn sie speziell für das Socket-Modell geschrieben wurden.

Es scheint zum größten Teil, dass das Problem der System-Leute mit Emporkömmlingen das Ereignissystem ist und dass sie glauben, dass es keinen Sinn ergibt oder unnötig ist. Vielleicht sagen ihre Worte es am besten.

Einfacher ausgedrückt: Die Tatsache, dass der Benutzer gerade D-Bus gestartet hat, ist in keiner Weise ein Hinweis darauf, dass NetworkManager ebenfalls gestartet werden sollte (dies würde Upstart jedoch tun). Umgekehrt ist es richtig: Wenn der Benutzer nach NetworkManager fragt, ist dies definitiv ein Hinweis darauf, dass auch D-Bus gestartet werden sollte (was sicherlich die meisten Benutzer erwarten würden, oder?).
Ein gutes Init-System sollte nur das starten, was benötigt wird, und das bei Bedarf. Entweder träge oder parallelisiert und im Voraus. Es sollte jedoch nicht mehr als nötig gestartet werden, insbesondere nicht alles, was installiert ist und diesen Dienst nutzen kann.

Wie ich bereits sagte, wird dies in der Ankündigung von systemd viel umfassender besprochen .

Xenoterracid
quelle
Entschuldigung, aber die Ankündigung ist wie ein Buch. Ich muss lesen und grok, bevor ich hier wirklich mehr aufnehmen kann.
Xenoterracide
2
Wie ist das besser als @ Johns Antwort? Ist es ein Platzhalter? Eine Promo von H Online ?
Tshepang
1
@tshepang naja es verlinkt eigentlich auf die ankündigung von system d und das h online zeug hat links dazu und andere interessante links. Es ist eine langweilige Lektüre. Ich möchte vielleicht noch mehr hinzufügen, wenn ich es geschafft habe ... dies ist kein einfaches Thema. Als ich das schrieb, dachte ich mir, Sie möchten vielleicht früher als später mit dem Lesen beginnen. aber zögern sie nicht mich zu modifizieren. sicherlich @jsbillings Antwort ist anständig und besser als meine bisher. aber nicht so gut wie die Ankündigung selbst zu
lesen
@tshepang Ich werde wahrscheinlich morgen nach dem Schlafengehen mehr hinzufügen. Ich war nur ein guter Journalist und zitierte meine Quellen.
Xenoterracide
@tshepang. Ich habe meine Antwort aktualisiert. Ich bin mir ziemlich sicher, dass ich fertig bin, es sei denn, die hilfsbereiten Leute von irc: //frenode.net/systemd entscheiden, dass sie eine Korrektur anbieten wollen.
Xenoterracide
11

Eine Sache, die die meisten von Ihnen vergessen haben, ist die Organisation von Prozessen in Gruppen .

Wenn systemd also ein Ding gestartet hat, wird es dieses Ding in eine eigene C-Gruppe einordnen, und es gibt keine (nicht privilegierte) Möglichkeit, dass der Prozess dieser C-Gruppe entkommt. Hier sind die Konsequenzen davon:

  • Ein Administrator eines großen Systems mit vielen Benutzern hat effiziente neue Möglichkeiten, um böswillige Benutzer / Prozesse zu identifizieren.
  • Die Prioritäten für die CPU-Planung lassen sich besser bestimmen als mit dem "Wonder Autocgroup Patch" .
Tshepang
quelle
8

Für einen sehr detaillierten Blick auf systemd, beginnend mit den ersten Entwurfsentwürfen (und einer detaillierten Kritik der vorhandenen Init-Systeme, einschließlich des Upstarts, und wie systemd diese zu beheben vorschlägt), gehen Sie zu seiner Homepage . Im Laufe der Zeit wurden mehrere Artikel zum Thema Startup in LWN veröffentlicht . Es sei nur darauf hingewiesen, dass jede Erwähnung von systemd (oder pulseaudio) dort nie endende Flammenkriege auslöst.

IMVHO (und als Fedora-Benutzer) bin ich sehr zufrieden damit. Etwas in dieser Reihe war längst überfällig, um die Komplexität aktueller Linux-Systeme zu bewältigen. Fedora hat eine Weile Emporkömmling benutzt, aber es ist nie aus dem Stadium gekommen, ein ausgefallener Ersatz für sysvinit zu sein, da es größtenteils unveränderte Init-Skripte ausführte. Das Versprechen, die Boot-Konfiguration zu vereinfachen, geht zu Lasten von neuemManuelles Einrichten von Abhängigkeiten, und das funktioniert einfach nicht. systemd figures hängt von sich selbst ab (oder erlaubt nur das Starten von Sachen ohne Rücksicht auf Abhängigkeiten, sie sortieren sich selbst aus). Ein weiterer großer Vorteil (einige sagen, es sei ein schwerwiegender Nachteil) ist, dass Linux-spezifische Funktionen im Griff behalten werden (insbesondere cgroups ermöglichen die Isolierung eines Daemons und aller seiner Nachkommen, sodass es einfach ist, die Ressourcen zu überwachen, zu begrenzen oder zu töten eine Gruppe; es gibt viele andere).

vonbrand
quelle
3

Journaling - Systemd ist buchstäblich wie der WinSXS-Ordner, wenn es um die Protokollierung geht. Es erstellt Kopien von Kopien, es sei denn, Sie löschen manuell oder reduzieren die Dateigröße, die es auf Ihrem Laufwerk verbraucht. Ich nenne es Bootloader-Cookies.

Bert
quelle
falsch. Das sind keine Kopien und es gibt ein konfigurierbares Limit freedesktop.org/software/systemd/man/journald.conf.html
pal