it-swarm.com.de

Warum enthalten die meisten systemd-Beispiele WantedBy = multi-user.target?

Ich habe was ist multi-user.target und die systemd Dokumentation gelesen, die besagt, dass das multi-user.target ein spezielles Ziel ist. Außerdem enthalten viele der systemd Beispiele diese Zeile.

  1. Warum enthalten so viele Beispieldienste diese Zeile?
  2. Was würde passieren, wenn sie nicht WantedBy = multi-user.target enthalten würden?
  3. Können Sie mir ein Beispiel geben, wann es tatsächlich ratsam wäre, diese Zeile nicht in eine Definition der Servicedatei aufzunehmen?
  4. Wann ist es in diesem Sinne eine gute Idee, diese Linie beizubehalten?
15
Carl

1.) multi-user.target Ist im Grunde das nächste Äquivalent zum klassischen SysVinit-Runlevel 3, das systemd hat. Wenn ein systemd System hochfährt, versucht systemd, den Systemstatus an den durch default.target Angegebenen Status anzupassen. Dies ist normalerweise ein Alias ​​für graphical.target oder multi-user.target.

multi-user.target Definiert normalerweise einen Systemstatus, in dem alle Netzwerkdienste gestartet werden und das System Anmeldungen akzeptiert, eine lokale GUI jedoch nicht gestartet wird. Dies ist der typische Standardsystemstatus für Serversysteme, bei denen es sich möglicherweise um Rack-Headless-Systeme in einem Remote-Serverraum handelt.

graphical.target Ist ein weiterer möglicher Alias ​​für default.target. Normalerweise wird es als Obermenge des multi-user.target Definiert: Es enthält alles, was der multi-user.target Tut, sowie die Aktivierung eines lokalen GUI-Logins. So ähnlich wie Runlevel 5 im klassischen SysVinit.

Die Zeile WantedBy=multi-user.target In einem Dienst entspricht im Wesentlichen der Angabe "Dieser Dienst sollte in den Runlevel 3, 4 und 5 starten" in SysVinit-Systemen: Sie teilt systemd mit, dass dieser Dienst als Teil gestartet werden soll beim normalen Systemstart, unabhängig davon, ob eine lokale GUI aktiv ist oder nicht.

WantedBy ist jedoch vom aktivierten/deaktivierten Status getrennt. In einem anderen Sinne handelt es sich also um eine Art "Voreinstellung": Es bestimmt, unter welchen Bedingungen der automatische Start erfolgen kann, jedoch nur, wenn der Dienst im aktiviert ist erster Platz.

2.) Wenn Sie die Zeile WantedBy=multi-user.target Weglassen und kein anderer aktivierter Dienst einen Requires=your.service Oder Wants=your.service In seiner Dienstdefinition enthält, wird Ihr Dienst nicht automatisch gestartet.

systemd funktioniert mit Abhängigkeiten, und wenn beim Start nichts Requires oder Wants Ihr Dienst ist, wird er nicht gestartet, selbst wenn der Dienst aktiviert ist.

Natürlich können Sie Ihren default.target Bearbeiten, um Requires oder Wants Zeilen für alle Dienste hinzuzufügen oder zu löschen, die beim Start gestartet werden sollen - aber damit Sie einfach einen neuen Dienst löschen können Datei in das System und lassen Sie es standardmäßig funktionieren (was es für Softwarepaket-Manager sehr einfach macht), systemd hat die Schlüsselwörter WantedBy und RequiredBy, die zum Einfügen verwendet werden können Wants und Requires - Typabhängigkeiten (jeweils) vom "anderen Ende".

3.) Sie sollten die Zeile weglassen, wenn Sie nicht möchten, dass der Dienst beim Booten jemals automatisch gestartet wird, oder dieser Dienst ist Teil einer Kette von Abhängigkeiten Sie haben explizit definiert.

Beispielsweise könnten Sie die Serveranwendung A umgestalten und aus irgendeinem Grund entscheiden, einige optionale Funktionen in einen separaten Dienst B aufzuteilen, damit der Benutzer die Möglichkeit hat, sie nicht zu installieren, wenn sie nicht benötigt wird. Sie können dann Dienst B zu einem separaten service-B.rpm Machen und B.service Mit WantedBy=A.service Definieren, damit systemd Dienst B automatisch startet, wenn Dienst A gestartet wird - aber Nur wenn service-B.rpm tatsächlich installiert ist.

Beachten Sie, dass ein Wants oder WantedBy nur besagt, dass das System einen Dienst starten soll, wenn ein anderer Dienst oder ein anderes Ziel ebenfalls gestartet wird, aber überhaupt nichts über die Start-/Herunterfahrreihenfolge angibt. Wenn Service B bereits beim Start von Service A ausgeführt werden soll, müssen Sie Before=A.service In die Datei B.service Einfügen, um die Abhängigkeit der Startreihenfolge explizit anzugeben.

4.) Immer wenn Sie do möchten, dass der Dienst beim Booten automatisch gestartet werden kann und keine anderen Abhängigkeiten bereits definiert sind.

21
telcoM

Wenn Sie WantedBy=multi-user.target Entfernen, kann systemctl enable your-example-here (Laut) nichts tun.

graphical.target

Wenn Sie pure systemd von der Quelle installieren, ist das "Standardziel", von dem aus gestartet wird, graphical.target.

Das Starten von graphical.target Startet multi-user.target Und alle Einheiten, die für die Bereitstellung einer grafischen Benutzeroberfläche erforderlich sind. Diese zusätzliche Komplexität wurde arrangiert, um alte "Runlevel" zu emulieren.

Sie wirklich sollten die "Runlevel" -Emulation ignorieren/beschönigen; es funktioniert sowieso nicht richtig. Es tut uns leid! Ich denke, der Grund für die Betonung von "grafisch" v.s. "Mehrbenutzer" ist historisch gesehen, dass Grafiksoftware 1) nicht so robust und ausgereift ist wie der Rest des Systems und 2) viele Ressourcen benötigt.

Normalerweise sind nur wenige Einheiten spezifisch für graphical.target. Es gibt einen einzigen Dienst für die GUI selbst wie gdm.target. Es gibt einige Support-Services, die meistens auch hier von der GUI verwendet werden.

Bearbeiten: Googeln schlägt vor, dass systemd möglicherweise eine Warnung protokolliert, wenn Sie keine GUI installiert haben, das "Standardziel" jedoch als graphical.target Belassen wurde. "Abhängigkeitsjob für Unit Display-Manager.Dienst kann nicht hinzugefügt werden, ignoriert: Unit Display-Manager.Dienst konnte nicht geladen werden: Keine solche Datei oder kein solches Verzeichnis." Wir möchten vermeiden, dass unsere Protokolle mit unnötigen Warnungen übersät werden. Wenn Sie also keine GUI installiert haben, empfiehlt es sich, systemctl set-default multi-user Zu verwenden. Obwohl das Installationssystem für Ihr Betriebssystem dies möglicherweise bereits für Sie erledigt hat. Davon abgesehen bin ich stark für Apathie in dieser Angelegenheit :-).

sysinit.target

Einige Dienste und andere Arten von Einheiten sind "am frühen Start beteiligt". Sie sind so definiert, dass sie Before=sysinit.target Starten - entweder direkt oder indirekt. Die meisten Dienste werden nur gestartet After=sysinit.target - dies ist automatisch der Fall, es sei denn, der Dienst setzt DefaultDependencies=no.

multi-user.target

Die meisten Beispieldienste fallen nicht unter eine der oben genannten Kategorien, daher hängen wir sie an multi-user.target An. Dies umfasst die meisten Netzwerkdienste (z. B. einen Webserver), bei denen es sich um den archetypischen Systemdienst handelt.

dynamisch aktivierte Dienste

Eine andere Möglichkeit, die Sie möglicherweise sehen, ist eine Serviceeinheit, die nicht beim Booten automatisch gestartet wird. Es würde also nicht WantedBy=multi-user.target Benötigen. Der Dienst kann stattdessen durch etwas anderes ausgelöst oder "aktiviert" werden.

Ein Beispiel hierfür ist ein dbus-aktivierter Dienst. Dbus kann so konfiguriert werden, dass Ihr Dienst bei Bedarf gestartet wird, wenn ein dbus-Anruf an den Dienst erfolgt.

Für Netzwerkdienste können Sie Socket-aktivierte Dienste verwenden. Dies ist möglicherweise einfacher zu finden, da die gesamte Konfiguration in systemd-Einheiten erfolgt. Zum Beispiel ist normalerweise sshd.socket Oder ssh.socket Verfügbar, um [email protected] Oder [email protected] Zu aktivieren. Ich denke jedoch, dass es üblicher ist, den sshd-Dienst beim Booten zu starten.


Wie immer vereinfacht und lässt das oben Gesagte Details aus, die nicht erforderlich zu sein schienen.

3
sourcejedi