Ich habe gerade zu Debian Jessie gewechselt, und die meisten Dinge laufen in Ordnung, einschließlich meines grafischen Display-Managers wdm.

Die Sache ist, ich verstehe einfach nicht, wie das funktioniert. Offensichtlich heißt mein /etc/init.d/wdmSkript, denn wenn ich dort ein frühes stelle exit, wird wdm nicht gestartet. Aber wenn ich alternativ das Verzeichnis /etc/rc3.d umbenenne (mein Standard-Runlevel war 3), wird wdm immer noch gestartet.

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

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

Die Antwort von Chaos ist, was einige Dokumentation sagt. Aber es ist nicht das, was systemd tatsächlich tut. (Es ist auch nicht das, was van Smoorenburg rcgetan hat. Der van Smoorenburg rchat die LSB-Header, die insservzur Berechnung der statischen Reihenfolge verwendet wurden, für den Anfang definitiv nicht ignoriert .) diese und andere Punkte. ( HOMETatsächlich wird die Umgebungsvariable häufig festgelegt. Dies war lange Zeit undokumentiert. Zumindest ist dies jetzt im Handbuch dokumentiert, aber die Freedesktop-WWW-Seite wurde noch nicht korrigiert.)

Das native Serviceformat für systemd ist die Serviceeinheit . Das eigentliche Service-Management von systemd arbeitet ausschließlich mit jenen, die es aus einem von neun Verzeichnissen liest, in denen (systemweite) .serviceDateien gespeichert werden können. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, Und /usr/lib/systemd/systemsind vier dieser Verzeichnisse.

Die Kompatibilität mit van Smoorenburg- rcSkripten wird mit einem Konvertierungsprogramm namens erreicht systemd-sysv-generator. Dieses Programm ist im /usr/lib/systemd/system-generators/Verzeichnis aufgeführt und wird daher von systemd zu Beginn des Bootstrap-Vorgangs bei jedem Bootvorgang und jedes Mal, wenn systemd angewiesen wird, seine Konfiguration später erneut zu laden, automatisch ausgeführt.

Dieses Programm ist ein Generator , eine Art Hilfsprogramm, dessen Aufgabe es ist, Service-Unit-Dateien im laufenden Betrieb in einem tmpfs zu erstellen, in dem sich drei weitere dieser neun Verzeichnisse befinden (die nur von Generatoren verwendet werden sollen). systemd-sysv-generatorgeneriert die Serviceeinheiten, von denen aus die van Smoorenburg- rcSkripte ausgeführt werden /etc/init.d, wenn keine systemeigene Serviceeinheit mit diesem Namen gefunden wird, die bereits an den anderen sechs Standorten vorhanden ist.

systemd service management kennt sich nur mit serviceeinheiten aus. Diese automatisch (neu) generierten Serviceeinheiten werden geschrieben, um die van Smoorenburg- rcSkripte aufzurufen . Sie haben unter anderem:

[Einheit]
SourcePath = / etc / init.d / wibble
[Bedienung]
ExecStart = / etc / init.d / wibble start
ExecStop = / etc / init.d / wibble stop

Erhaltene Weisheit ist, dass die van Smoorenburg- rcSkripte einen LSB-Header haben müssen und parallel ausgeführt werden, ohne die vom /etc/rc?.d/System auferlegten Prioritäten zu berücksichtigen . Dies ist in allen Punkten falsch.

Tatsächlich benötigen sie keinen LSB-Header und systemd-sysv-generatorkönnen die eingeschränkteren alten RedHat-Kommentar-Header ( description:, pidfile:usw.) nicht erkennen. Darüber hinaus wird in Abwesenheit eines LSB-Headers auf den Inhalt der /etc/rc?.dsymbolischen Linkfarmen zurückgegriffen, die in den Linknamen codierten Prioritäten gelesen und ein Vorher / Nachher-Ordering von diesen erstellt, die Dienste serialisiert. Nicht nur, dass LSB-Header keine Anforderung sind und nicht nur, dass sie selbst vor / nach Aufträgen codieren, die die Dinge zu einem gewissen Grad serialisieren, das Fallback-Verhalten in ihrer vollständigen Abwesenheit ist tatsächlich ein signifikant nicht parallelisierter Betrieb.

Der Grund, der /etc/rc3.danscheinend keine Rolle spielte, war, dass Sie dieses Skript wahrscheinlich über ein anderes /etc/rc?.d/Verzeichnis aktiviert hatten . systemd-sysv-generatorübersetzt wird , in einem der aufgeführten /etc/rc2.d/, /etc/rc3.d/und /etc/rc4.d/in eine native Wanted-ByBeziehung zu systemd ist multi-user.target. Run-Levels sind in der Systemwelt "veraltet", und Sie können sie vergessen.

Weitere Lektüre

• systemd-sysv-generator . systemd manpages. Freedesktop.org.
• Msgstr "Umgebungsvariablen in erzeugten Prozessen" . systemd.exec. systemd manpages. 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

Systemd ist abwärtskompatibel mit SysV-Init-Skripten. Gemäß LSB 3.1 muss das Init-Skript Kommentar-Konventionen enthalten , die definieren, wann das Skript gestartet / gestoppt werden muss und was für das Starten / Stoppen des Skripts erforderlich ist. Dies ist ein Beispiel:

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO

Dies ist ein kommentierter Abschnitt, der von SysV ignoriert wird. Andererseits liest systemd diese Abhängigkeitsinformationen und führt diese Skripte abhängig davon aus.

Es gibt jedoch einen Punkt, an dem sich systemd und SysV in Bezug auf Init-Skripte unterscheiden. SysV führt die Skripte in der Reihenfolge ihrer Nummer im Dateinamen aus. Systemd nicht. Wenn Abhängigkeiten erfüllt sind, führt systemd die Skripte sofort aus, ohne die Nummerierung der Skriptnamen zu berücksichtigen. Einige von ihnen werden höchstwahrscheinlich aufgrund der Bestellung scheitern. Es gibt viele andere Inkompatibilitäten , die berücksichtigt werden sollten.

Wenn für denselben Dienst Init-Skripte und .service-Dateien vorhanden sind, führt systemd beide aus, sobald die Abhängigkeiten erfüllt sind (im Fall des Init-Skripts die im LSB-Header definierten).