Ich bin gerade zu Debian Jessie gewechselt, und die meisten Dinge laufen gut, einschließlich meines grafischen Anzeigemanagers wdm .

Die Sache ist, ich verstehe einfach nicht, wie das funktioniert. Offensichtlich mein /etc/init.d/wdm script aufgerufen wird, weil ich bei einem frühen exit gesetzt habe dort wird wdm nicht gestartet. Aber wenn ich alternativ die /etc/rc3.d umbenenne Verzeichnis (mein Standard-Runlevel war früher 3), dann wird wdm immer noch gestartet.

Ich konnte nicht herausfinden, wie systemd dieses Skript findet, und ich verstehe nicht, was es mit all den anderen init.d-Skripten macht.

• Wann und wie führt systemd init.d-Skripte aus?
• Sollte ich auf lange Sicht alle init.d-Skripte loswerden?

Akzeptierte Antwort:

Die Antwort von Chaos ist, was einige Dokumentationen sagen. Aber es ist nicht das, was systemd tatsächlich tut. (Es ist nicht was van Smoorenburg rc auch nicht. Der van Smoorenburg rc ganz sicher nicht LSB-Header ignorieren, die insserv verwendet, um statische Ordnungen zu berechnen, für den Anfang.) Die Freedesktop-Dokumentation, wie die Seite „Inkompatibilitäten“, ist in diesen und anderen Punkten tatsächlich falsch. (Die HOME Umgebungsvariable ist oft gesetzt, zum Beispiel. Das ging lange Zeit nirgendwo völlig undokumentiert. Es ist jetzt zumindest im Handbuch dokumentiert, aber diese Freedesktop-WWW-Seite wurde immer noch nicht korrigiert.)

Das native Dienstformat für systemd ist die Diensteinheit . Die eigentliche Dienstverwaltung von systemd arbeitet ausschließlich in Bezug auf diejenigen, die es aus einem von neun Verzeichnissen liest, in denen (systemweit) .service Dateien können leben. /etc/systemd/system , /run/systemd/system , /usr/local/lib/systemd/system , und /usr/lib/systemd/system sind vier dieser Verzeichnisse.

Die Kompatibilität mit van Smoorenburg rc scripts wird mit einem Konvertierungsprogramm namens systemd-sysv-generator erreicht . Dieses Programm ist in /usr/lib/systemd/system-generators/ aufgeführt Verzeichnis und wird daher von systemd früh im Bootstrap-Prozess bei jedem Start automatisch ausgeführt, und jedes Mal, wenn systemd später angewiesen wird, seine Konfiguration neu zu laden.

Dieses Programm ist ein Generator , eine Art Hilfsdienstprogramm, dessen Aufgabe es ist, Service-Unit-Dateien im Handumdrehen zu erstellen, in einem tmpfs, in dem sich drei weitere dieser neun Verzeichnisse (die nur von Generatoren verwendet werden sollen) befinden. systemd-sysv-generator generiert die Diensteinheiten, die den van Smoorenburg rc ausführen Skripte von /etc/init.d , wenn es keine native systemd-Diensteinheit mit diesem Namen findet, die bereits an den anderen sechs Standorten vorhanden ist.

Die systemd-Dienstverwaltung kennt nur Diensteinheiten. Diese automatisch (neu) generierten Diensteinheiten werden geschrieben, um den van Smoorenburg rc aufzurufen Skripte. Sie haben unter anderem:

[Unit]
SourcePath=/etc/init.d/wibble
[Service]
ExecStart=/etc/init.d/wibble start
ExecStop=/etc/init.d/wibble stop

Verwandte:Ubuntu – Wie führe ich .sh-Skripte aus?

Überlieferte Weisheit ist, dass der van Smoorenburg rc Skripte müssen einen LSB-Header haben und werden parallel ausgeführt, ohne die von /etc/rc?.d/ auferlegten Prioritäten zu berücksichtigen System. Das ist in allen Punkten falsch.

Tatsächlich müssen sie keinen LSB-Header haben, und wenn sie keinen systemd-sysv-generator haben kann die eingeschränkteren alten RedHat-Kommentarkopfzeilen erkennen (description: , pidfile: , und so weiter). Darüber hinaus wird in Abwesenheit eines LSB-Headers auf den Inhalt von /etc/rc?.d zurückgegriffen Symbolische Linkfarmen, Lesen der in den Linknamen codierten Prioritäten und Erstellen einer Vorher/Nachher-Ordnung daraus, Serialisieren der Dienste. LSB-Header sind nicht nur keine Voraussetzung, und sie codieren nicht nur selbst Vorher/Nachher-Ordnungen, die Dinge in gewissem Maße serialisieren, das Fallback-Verhalten in ihrer vollständigen Abwesenheit ist tatsächlich ein signifikant nicht parallelisierter Betrieb.

Der Grund dafür, dass /etc/rc3.d keine Rolle spielte, war, dass Sie dieses Skript wahrscheinlich über eine andere /etc/rc?.d/ aktiviert hatten Verzeichnis. systemd-sysv-generator übersetzt, die in /etc/rc2.d/ aufgeführt sind , /etc/rc3.d/ , und /etc/rc4.d/ in ein natives Wanted-By Beziehung zu systemds multi-user.target . Runlevels sind in der Systemd-Welt „veraltet“, und Sie können sie vergessen.

Weiterführende Literatur

• systemd-sysv-generator . systemd Handbuchseiten. Freedesktop.org.
• „Umgebungsvariablen in erzeugten Prozessen“. systemd.exec . systemd Handbuchseiten. Freedesktop.org.
• https://unix.stackexchange.com/a/394191/5132
• https://unix.stackexchange.com/a/204075/5132
• https://unix.stackexchange.com/a/196014/5132
• https://unix.stackexchange.com/a/332797/5132