Ich habe gelesen, was multi-user.target und die systemd-Dokumentation ist, die besagt, dass multi-user.target ein spezielles Ziel ist. Außerdem enthalten viele der systemd-Beispiele diese Zeile.
- Warum enthalten so viele Beispieldienste diese Zeile?
- Was würde passieren, wenn sie WantedBy=multi-user.target nicht enthalten würden?
- Können Sie mir ein Beispiel dafür geben, wann es tatsächlich ratsam wäre, diese Zeile nicht in eine Dienstdateidefinition aufzunehmen?
- In diesem Sinne, wann ist es eine gute Idee, diese Linie beizubehalten?
Akzeptierte Antwort:
1.) multi-user.target ist im Grunde das nächste Äquivalent zum klassischen SysVinit-Runlevel 3, das systemd verfügt über. Wenn ein systemd System bootet, systemd versucht, den Systemstatus mit dem durch default.target angegebenen Status abzugleichen – was normalerweise ein Alias für entweder graphical.target ist oder multi-user.target .
multi-user.target definiert normalerweise einen Systemzustand, in dem alle Netzwerkdienste gestartet sind und das System Anmeldungen akzeptiert, aber keine lokale GUI gestartet wird. Dies ist der typische Standardsystemstatus für Serversysteme, bei denen es sich um in einem Rack montierte Headless-Systeme in einem entfernten Serverraum handeln kann.
graphical.target ist ein weiterer möglicher Alias für default.target . Normalerweise ist es als Obermenge von multi-user.target definiert :Es enthält alles, was multi-user.target enthält tut, plus die Aktivierung einer lokalen GUI-Anmeldung. So ähnlich wie Runlevel 5 im klassischen SysVinit.
Die Zeile WantedBy=multi-user.target in einem Dienst ist im Wesentlichen dasselbe wie die Angabe „dieser Dienst sollte in den Runlevels 3, 4 und 5 starten“ in SysVinit-Systemen:Es teilt systemd mit dass dieser Dienst als Teil des normalen Systemstarts gestartet werden sollte, unabhängig davon, ob eine lokale GUI aktiv ist oder nicht.
Allerdings WantedBy ist vom aktivierten/deaktivierten Zustand getrennt:In einem anderen Sinne ist es also eine Art „Voreinstellung“:Es bestimmt, unter welchen Bedingungen der automatische Start erfolgen kann, aber nur, wenn der Dienst überhaupt aktiviert ist.
2.) wenn Sie WantedBy=multi-user.target weglassen Zeile und kein anderer aktivierter Dienst enthält ein Requires=your.service oder Wants=your.service in seiner Dienstdefinition wird Ihr Dienst nicht automatisch gestartet.
systemd funktioniert bei Abhängigkeiten und beim Booten, wenn nichts Requires ist oder Wants Ihr Dienst, wird er nicht gestartet, selbst wenn der Dienst aktiviert ist.
Sicher, Sie könnten Ihr default.target bearbeiten zum Hinzufügen oder Löschen von Requires oder Wants Zeilen für alle Dienste, die beim Booten gestartet werden sollen – aber damit Sie einfach eine neue Dienstdatei in das System ziehen und sie standardmäßig zum Laufen bringen können (was die Dinge für Softwarepaketmanager sehr einfach macht), systemd hat den WantedBy und RequiredBy Schlüsselwörter, die zum Einfügen von Wants verwendet werden können und Requires -Typ-Abhängigkeiten (jeweils) vom „anderen Ende“.
3.) Sie sollten die Zeile weglassen, wenn Sie nicht möchten, dass der Dienst immer automatisch beim Booten gestartet wird, oder Dieser Dienst ist Teil einer Kette von Abhängigkeiten, die Sie explizit definiert haben.
Beispielsweise könnten Sie die Serveranwendung A umgestalten und aus irgendeinem Grund entscheiden, einige optionale Funktionen davon in einen separaten Dienst B aufzuteilen, um dem Benutzer die Wahl zu lassen, sie nicht zu installieren, wenn sie nicht benötigt wird. Sie könnten dann Service B zu einer separaten service-B.rpm machen , und definieren Sie B.service mit WantedBy=A.service um systemd zu machen Dienst B automatisch starten, wenn Dienst A gestartet wird – aber nur wenn service-B.rpm tatsächlich installiert ist.
Beachten Sie, dass ein Wants oder WantedBy sagt nur, dass das System einen Dienst starten soll, wenn auch ein anderer Dienst oder ein anderes Ziel gestartet wird, aber es gibt überhaupt nichts über die Start-/Herunterfahrreihenfolge an. Wenn Dienst B bereits ausgeführt werden soll, wenn Dienst A gestartet wird, müssen Sie Before=A.service hinzufügen im B.service Datei, um die Abhängigkeit der Startreihenfolge explizit anzugeben.
4.) Jederzeit tun möchten, dass der Dienst beim Booten automatisch gestartet werden kann und keine anderen Abhängigkeiten bereits definiert sind.