Eingehende Analyse des systemd-Verwaltungssystems unter CentOS 7

CentOS-Systemstartvorgang:

POST --> Bootloader --> kernel + initramfs -->

innit-Programm:

CentOS 5: SysV-Init

CetnOS 6: Upstart

CentOS 7: Systemd

Systemd neue Funktionen:

Kompatibel mit System Sys V-Init- und LSB-Init-Skripten

Erzielen Sie einen parallelen Start von Diensten beim Systemstart. Verwenden Sie Socket-/D-Bus-Aktivierung und andere Technologien, um die Systemstartzeit zu verkürzen. Das Ziel von systemd besteht darin, so wenige Prozesse wie möglich zu starten. um so viele Prozesse wie möglich zu parallelisieren. Start;

Aktivieren Sie Prozesse bei Bedarf.

Systemd kann die Möglichkeit bieten, bei Bedarf zu starten und einen Dienst nur dann zu starten, wenn er tatsächlich angefordert wird. Wenn der Dienst endet, kann systemd ihn herunterfahren und beim nächsten Bedarf erneut starten.

Möglichkeit zum Erstellen eines Snapshots und zur Wiederherstellung des Systems

Starten Sie die Verwaltung von Mount-Punkten und automatischen Mount-Punkten:

Systemd verwaltet Mount-Punkte auf dem System selbst, um sie beim Systemstart automatisch mounten zu können. Und kompatibel mit der Datei /etc/fstab;

Implementieren Sie das Transaktionsabhängigkeitsmanagement:

systemd verwaltet ein Konzept der „Transaktionskonsistenz“, um sicherzustellen, dass alle zugehörigen Dienste normal und ohne gegenseitige Abhängigkeit oder Deadlock gestartet werden können.

Definieren Sie die Service-Kontrolllogik basierend auf endogenen Abhängigkeiten

system nutzt die Funktion des Linux-Kernels, nämlich CGroup, um die Aufgabe der Prozessverfolgung abzuschließen. Beim Beenden des Dienstes kann systemd durch Abfragen der CGroup sicherstellen, dass alle zugehörigen Prozesse gefunden werden, wodurch der Dienst sauber beendet wird

Protokolldienst:

systemd verfügt über einen eigenen Protokolldienst „journald“, der die Mängel des vorhandenen Syslog-Dienstes beheben soll.

Grundlegende Systemkonzepte

Konzept der Einheit:

Für die Systeminitialisierung müssen viele Dinge getan werden. Hintergrunddienste müssen gestartet werden, z. B. das Starten des SSHD-Dienstes. Es müssen Konfigurationsarbeiten durchgeführt werden, z. B. das Mounten des Dateisystems. Jeder Schritt in diesem Prozess wird von systemd in eine Konfigurationseinheit, also Unit, abstrahiert. Sie können sich einen Dienst als eine Konfigurationseinheit vorstellen; einen Mountpunkt als eine Konfigurationseinheit; die Konfiguration einer Swap-Partition als eine Konfigurationseinheit; systemd klassifiziert Bienenstöcke in verschiedene Typen: Allerdings entwickelt sich systemd rasant weiter und es werden ständig neue Funktionen hinzugefügt. Daher könnte es in naher Zukunft zu einer weiteren Zunahme der Bienenstockarten kommen.

service: stellt einen Hintergrunddienstprozess dar, z. B. mysqld. Dies ist eine häufig verwendete Kategorie;

Socket: Dieser Hive kapselt einen Socket im System und im Internet. Derzeit unterstützt systemd Streaming-, Paket- und kontinuierliche Paket-AF_INET-, AF_INET6- und AF_UNIX-Sockets. Jeder Socket-Hive verfügt über einen entsprechenden Service-Hive. Der entsprechende Dienst wird gestartet, wenn die erste „Verbindung“ in den Socket gelangt (Beispiel: nscd.socket startet nscd.service nach einer neuen Verbindung).

Gerät: Dieser Hive kapselt ein Gerät, das im Linux-Gerätebaum vorhanden ist. Jedes mit einer udev-Regel markierte Gerät wird in systemd als Gerätestruktur angezeigt.

mount: Dieser Hive-Typ kapselt einen Mount-Punkt in der Strukturhierarchie des Dateisystems. Systemd überwacht und verwaltet diesen Mountpunkt. Beispielsweise kann es beim Start automatisch gemountet werden; unter bestimmten Bedingungen kann es automatisch deinstalliert werden. Systemd konvertiert alle Einträge in /etc/fstab in Mountpunkte und verarbeitet sie beim Booten.

Automount: Dieser Hive-Typ kapselt einen Self-Mount-Punkt in der Systemstrukturhierarchie. Jeder selbstmontierende Hive entspricht einem Mount-Hive. Wenn auf den automatischen Mount-Punkt zugegriffen wird, führt systemd das im Mount-Punkt definierte Mount-Verhalten aus.

Swap: Ähnlich wie der Mount-Hive wird der Swap-Hive zur Verwaltung der Swap-Partition verwendet. Benutzer können Swap-Hives verwenden, um Swap-Partitionen im System zu definieren, sodass diese Swap-Partitionen beim Booten aktiviert werden können.

Ziel: Dieser Bienenstock bietet eine logische Gruppierung anderer Bienenstöcke. Sie machen eigentlich nichts selbst, sie beziehen sich lediglich auf andere Bienenstöcke. Dies ermöglicht eine einheitliche Steuerung der Konfigurationseinheit. Damit lässt sich das bekannte Konzept der Runlevel umsetzen. Wenn Sie beispielsweise möchten, dass das System in den grafischen Modus wechselt, müssen Sie viele Dienste und Konfigurationsbefehle ausführen. Diese Vorgänge werden durch Konfigurationseinheiten einzeln dargestellt. Das Kombinieren aller dieser Konfigurationseinheiten in einem Ziel bedeutet, dass alle diese Konfigurationseinheiten ausgeführt werden müssen einmal ausgeführt werden, um in den durch das Ziel dargestellten Systembetriebszustand zu gelangen. (Zum Beispiel: multi-user.target entspricht Runlevel 3 in Systemen, die traditionelles SysV verwenden)

Timer: Die Timer-Konfigurationseinheit wird verwendet, um benutzerdefinierte Vorgänge in regelmäßigen Abständen auszulösen. Diese Art von Konfigurationseinheit ersetzt herkömmliche Timing-Dienste wie atd und crond.

Schnappschuss: Ähnlich wie bei einem Zielstock handelt es sich bei einem Schnappschuss um eine Reihe von Bienenstöcken. Es speichert den aktuellen Betriebszustand der Anlage.

Abhängigkeiten:

Obwohl systemd die Abhängigkeit von einer großen Anzahl von Startaufgaben beseitigt, sodass diese gleichzeitig gestartet werden können. Es gibt jedoch immer noch einige Aufgaben, zwischen denen eine inhärente Abhängigkeit besteht, und die drei Hauptmethoden „Socket-Aktivierung“ (Socket-Aktivierung), D-Bus-Aktivierung und Autofs können nicht verwendet werden, um die Abhängigkeit zu beseitigen (Einzelheiten dazu finden Sie in den folgenden Beschreibungen). die drei Hauptmethoden). Beispiel: Der Mount muss darauf warten, dass der Mountpunkt im Dateisystem erstellt wird; der Mount muss auch darauf warten, dass das entsprechende physische Gerät bereit ist. Um diese Art von Abhängigkeitsproblem zu lösen, können Systemd-Hives Abhängigkeiten voneinander definieren.

Systemd verwendet Schlüsselwörter in Hive-Definitionsdateien, um Abhängigkeiten zwischen Hives zu beschreiben. Beispiel: Einheit A hängt von Einheit B ab, was in der Definition von Einheit B durch „erforderlich A“ dargestellt werden kann. Auf diese Weise stellt systemd sicher, dass zuerst A und dann B gestartet wird.

Systemd-Transaktionen:

Systemd kann die Transaktionsintegrität garantieren. Das Transaktionskonzept von Systemd unterscheidet sich von dem in der Datenbank, hauptsächlich um sicherzustellen, dass es keine Zirkelverweise zwischen mehreren abhängigen Konfigurationseinheiten gibt. Wenn eine zirkuläre Abhängigkeit besteht, kann systemd keinen Dienst starten. Zu diesem Zeitpunkt wird systemd versuchen, dieses Problem zu lösen, da es zwei Arten von Abhängigkeiten zwischen Hives gibt: „required“ ist eine starke Abhängigkeit; „want“ ist eine schwache Abhängigkeit Zyklus. Wenn es nicht repariert werden kann, meldet systemd einen Fehler.

Systemd kann solche Konfigurationsfehler automatisch erkennen und reparieren, wodurch der Aufwand für die Fehlerbehebung für den Administrator erheblich verringert wird.

Ziel und Runlevel:

systemd ersetzt das Konzept des Run-Levels durch das Ziel und bietet so mehr Flexibilität. Sie können beispielsweise ein vorhandenes Ziel erben und andere Dienste hinzufügen, um Ihr eigenes Ziel zu erstellen. In der folgenden Tabelle sind die entsprechenden Beziehungen zwischen Zielen unter systemd und allgemeinen Runlevels aufgeführt:

Systemd s gleichzeitiges Startprinzip

Wie bereits erwähnt, werden in Systemd alle Dienste gleichzeitig gestartet, z. B. Avahi, D-Bus, livirtd, X11 und HAL können gleichzeitig gestartet werden. Auf den ersten Blick scheint dies ein kleines Problem zu sein. Avahi muss beispielsweise gleichzeitig mit dem Syslog-Dienst gestartet werden, da Syslog noch nicht bereit ist Protokolle. Würde das nicht Probleme verursachen?

Systemd-Entwickler haben die Art der gegenseitigen Abhängigkeit zwischen Diensten sorgfältig untersucht und festgestellt, dass sogenannte Abhängigkeiten in drei spezifische Typen unterteilt werden können und jeder Typ tatsächlich Abhängigkeiten durch entsprechende Technologien beseitigen kann.

Eines der Prinzipien des gleichzeitigen Starts: Lösen von Socket- Abhängigkeiten

Die überwiegende Mehrheit der Dienstabhängigkeiten sind Socket-Abhängigkeiten. Beispielsweise stellt Dienst A seine eigenen Dienste über einen Socket-Port S1 bereit. Wenn andere Dienste Dienst A benötigen, müssen sie eine Verbindung zu S1 herstellen. Wenn also Dienst A noch nicht gestartet wurde, existiert S1 nicht und andere Dienste erhalten Startfehler. Daher müssen Benutzer traditionell zuerst Dienst A starten, warten, bis er in den Bereitschaftszustand wechselt, und dann andere Dienste starten, die ihn benötigen. Systemd glaubt, dass alle anderen Dienste gleichzeitig gestartet werden können, solange wir S1 im Voraus einrichten, ohne darauf warten zu müssen, dass Dienst A S1 erstellt. Wenn Dienst A nicht gestartet wurde, wird die von anderen Prozessen an S1 gesendete Dienstanforderung tatsächlich vom Linux-Betriebssystem zwischengespeichert und andere Prozesse warten am Speicherort dieser Anforderung. Sobald Dienst A betriebsbereit ist, können zwischengespeicherte Anfragen sofort verarbeitet werden und alles beginnt normal zu laufen.

Wie nutzt der Dienst also den vom Init-Prozess erstellten Socket?

Das Linux-Betriebssystem verfügt über eine Funktion, wenn ein Prozess fork oder exec aufruft, um einen untergeordneten Prozess zu erstellen. Alle im übergeordneten Prozess geöffneten Dateideskriptoren werden vom untergeordneten Prozess geerbt. Ein Socket ist auch eine Art Dateihandle. Wenn Prozess A dann exec aufruft, um einen neuen untergeordneten Prozess zu starten, wird der neue untergeordnete Prozess aktiviert, solange das Flag close_on_exec des Sockets gelöscht ist kann diesen Socket erben. Der vom untergeordneten Prozess gesehene Socket und der vom übergeordneten Prozess erstellte Socket sind dieselben System-Sockets. Als ob der Socket vom untergeordneten Prozess selbst erstellt worden wäre, gibt es keinen Unterschied.

Diese Funktion wurde zuvor von einem Systemdienst namens inetd ausgenutzt. Der Inetd-Prozess ist für die Überwachung einiger gängiger Socket-Ports verantwortlich, z. B. Telnet. Wenn eine Verbindungsanforderung für den Port vorliegt, startet inetd den Telnetd-Prozess und übergibt den verbundenen Socket zur Verarbeitung an den neuen Telnetd-Prozess. Wenn das System keine Telnet-Client-Verbindung hat, ist es auf diese Weise nicht erforderlich, den Telnetd-Prozess zu starten. Inetd kann viele Netzwerkdienste vertreten, wodurch viel Systemlast und Speicherressourcen eingespart werden können. Der entsprechende Dienst wird nur gestartet, wenn eine echte Verbindungsanforderung vorliegt, und der Socket wird an den entsprechenden Dienstprozess übergeben.

Ähnlich wie inetd ist systemd der übergeordnete Prozess aller anderen Prozesse. Es kann zunächst alle erforderlichen Sockets einrichten und dann den Socket beim Aufruf von exec an den neuen Prozess übergeben anrufen und Service durchführen.

Prinzip 2 des gleichzeitigen Starts: Lösen von D-Bus-Abhängigkeiten D-Bus ist die Abkürzung für Desktop-Bus, ein prozessübergreifender Kommunikationsmechanismus mit geringer Latenz, geringem Overhead und hoher Verfügbarkeit. Es wird zunehmend für die Kommunikation zwischen Anwendungen, aber auch für die Kommunikation zwischen Anwendungen und dem Betriebssystemkernel verwendet. Viele moderne Serviceprozesse verwenden D-Bus anstelle von Sockets als prozessübergreifenden Kommunikationsmechanismus zur Bereitstellung externer Services. Beispielsweise nutzt der NetworkManager-Dienst, der die Linux-Netzwerkkonfiguration vereinfacht, D-Bus, um mit anderen Anwendungen oder Diensten zu interagieren: Die Weiterentwicklung der E-Mail-Client-Software kann Änderungen im Netzwerkstatus vom NetworkManager-Dienst über D-Bus abrufen, um sie entsprechend zu verarbeiten.

D-Bus unterstützt die sogenannte „Busaktivierung“-Funktion. Wenn Dienst A den D-Bus-Dienst von Dienst B verwenden muss und Dienst B nicht ausgeführt wird, kann D-Bus Dienst B automatisch starten, wenn Dienst A den D-Bus von Dienst B anfordert. Die von Dienst A ausgegebene Anforderung wird von D-Bus zwischengespeichert und Dienst A wartet darauf, dass Dienst B bereit ist. Mit dieser Funktion können Dienste, die auf D-Bus basieren, parallel gestartet werden.

Prinzip 3 des gleichzeitigen Starts: Dateisystemabhängigkeiten auflösen

Während des Systemstartvorgangs sind dateisystembezogene Aktivitäten am zeitaufwändigsten. Beispielsweise sind das Mounten des Dateisystems, die Durchführung einer Festplattenprüfung (fsck) für das Dateisystem, die Festplattenkontingentprüfung usw. sehr zeitaufwändig Operationen. Während das System auf den Abschluss dieser Arbeit wartet, bleibt es im Leerlauf. Dienste, die das Dateisystem verwenden möchten, müssen offenbar warten, bis die Initialisierung des Dateisystems abgeschlossen ist, bevor sie gestartet werden können. Aber systemd hat herausgefunden, dass diese Abhängigkeit auch vermieden werden kann.

Systemd bezieht sich auf die Designideen von autofs, die es ermöglichen, dass Dienste, die auf dem Dateisystem basieren, und die Initialisierung des Dateisystems selbst gleichzeitig funktionieren. autofs kann erkennen, wann tatsächlich auf einen Dateisystem-Mount-Punkt zugegriffen wird, bevor der Mount-Vorgang ausgelöst wird. Dies wird durch die Unterstützung des Kernel-Automounter-Moduls erreicht. Wenn beispielsweise ein open()-Systemaufruf für „/misc/cd/file1“ ausgeführt wird, hat /misc/cd den Montagevorgang noch nicht durchgeführt. Der open()-Aufruf wird zu diesem Zeitpunkt angehalten und wartet Der Kernel benachrichtigt Autofs und Autofs führt den Montagevorgang durch. Zu diesem Zeitpunkt wird die Steuerung an den Systemaufruf open() zurückgegeben und die Datei wird normal geöffnet.

Systemd integriert die Implementierung von autofs. Für Einhängepunkte im System, z. B. /home, erstellt systemd beim Systemstart einen temporären automatischen Einhängepunkt dafür. Zu diesem Zeitpunkt wurde das eigentliche Montagegerät von /home noch nicht gestartet, der eigentliche Montagevorgang wurde noch nicht durchgeführt und die Dateisystemerkennung ist noch nicht abgeschlossen. Prozesse, die auf dieses Verzeichnis angewiesen sind, können jedoch bereits gleichzeitig gestartet werden, und ihre open()-Vorgänge werden von in systemd integrierten autofs erfasst, die den open()-Aufruf unterbrechen (was den Ruhezustand unterbrechen kann). Nachdem der eigentliche Mount-Vorgang abgeschlossen ist und die Dateisystemerkennung abgeschlossen ist, ersetzt systemd den automatischen Mount-Punkt durch den echten Mount-Punkt und lässt den open()-Aufruf zurückkehren. Dadurch können Dienste, die auf dem Dateisystem basieren, und das Dateisystem selbst gleichzeitig gestartet werden.

Natürlich muss die Abhängigkeit vom Stammverzeichnis „/“ tatsächlich seriell ausgeführt werden, da systemd selbst auch unter / gespeichert ist und warten muss, bis das Stammverzeichnis des Systems gemountet und überprüft wird.

Bei Mount-Punkten wie /home kann diese Parallelität jedoch die Startgeschwindigkeit des Systems verbessern, insbesondere wenn /home ein Remote-NFS-Knoten oder eine verschlüsselte Festplatte usw. ist, was lange dauert, bis es bereit ist Beim gleichzeitigen Start hat das System in diesem Zeitraum nichts zu tun, sondern kann diese freie Zeit für weitere Startvorgänge nutzen, was die Systemstartzeit insgesamt verkürzt.

Systemd

Nutzung

Im Folgenden finden Sie eine kurze Einführung in die Verwendung von systemd für die verschiedenen Rollen des technischen Personals. Dieser Artikel soll lediglich eine einfache Beschreibung geben, um Ihnen ein allgemeines Verständnis der Verwendung von systemd zu vermitteln. Es gibt zu viele spezifische Details, um in einen kurzen Artikel zu passen. Leser müssen die systemd-Dokumentation selbst weiter konsultieren.

Einheit Schreiben von Dateien

Wenn Entwickler ein neues Dienstprogramm wie httpd entwickeln, müssen sie eine Hive-Datei dafür schreiben, damit der Dienst von systemd verwaltet werden kann, ähnlich der Arbeitskonfigurationsdatei von UpStart. Definieren Sie in dieser Datei die Befehlszeilensyntax für den Dienststart sowie Abhängigkeiten von anderen Diensten.

Darüber hinaus haben wir zuvor gelernt, dass systemd viele Funktionen hat. Es wird nicht nur zum Verwalten von Diensten verwendet, sondern auch zum Verwalten von Bereitstellungspunkten, zum Definieren geplanter Aufgaben usw. Diese Aufgaben werden durch Bearbeiten der entsprechenden Hive-Datei erledigt. Ich gebe hier einige Beispiele für Hive-Dateien.

Das Folgende ist die Konfigurationseinheitsdatei des SSH-Dienstes. Die Dienstkonfigurationseinheitsdatei hat .service als Dateinamenssuffix.

[root@kalaguiyin system]# cat/usr/lib/systemd/system/sshd.service

[Einheit]

Description=OpenSSH-Server-Daemon

After=network.target sshd-keygen.service

Wants=sshd-keygen.service

#[Einheit] Teil, Beschreibungsinformationen

[Service]

EnvironmentFile=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=Prozess

Neustart=bei Fehler

RestartSec=42s

#[Dienst]-Definition, ExecStartPre definiert den Befehl, der vor dem Starten des Dienstes ausgeführt werden soll

#ExecStart definiert die spezifische Befehlszeilensyntax zum Starten des Dienstes.

[Installieren]

WantedBy=multi-user.target

#[install] Abschnitt: WangtedBy gibt an, dass dieser Dienst im Mehrbenutzermodus erforderlich ist.

Dann werfen wir einen Blick auf multi-user.target:

[root@kalaguiyin system]#catmulti-user.target

[Einheit]

Beschreibung=Mehrbenutzersystem

Documentation=man:systemd.special(7)

Requires=basic.target

Conflicts=rescue.service Rescue.target

After=basic.target Rescue.servicerescue.target

AllowIsolate=yes

# Die Requires-Definition gibt an, dass beim Start von multi-user.target auch basic.target gestartet werden muss. Wenn basic.target stoppt, muss auch multi-user.target gestoppt werden. Wenn Sie sich dann die Datei basic.target ansehen, werden Sie feststellen, dass dort auch sysinit.target

angegeben ist

# Weitere Einheiten müssen entsprechend gestartet werden. Ebenso enthält sysinit.target auch andere Einheiten. Mithilfe einer solchen schichtweisen Verbindungsstruktur werden schließlich alle Komponentendienste initialisiert und gestartet, die den Mehrbenutzermodus unterstützen müssen.

[Installieren]

Alias=default.target

# Alias-Definition, dh definieren Sie den Alias ​​dieser Einheit, sodass Sie diesen Alias ​​verwenden können, um auf diese Einheit zu verweisen, wenn Sie systemctl ausführen.

Darüber hinaus können Sie auch Verzeichnisse wie *.wants im Verzeichnis /etc/systemd/system sehen. Die in diesem Verzeichnis abgelegte Konfigurationseinheitsdatei entspricht dem Schlüsselwort „wants“ im Abschnitt [Unit], d. h. wenn dies der Fall ist Einheit startet. Diese Einheiten müssen ebenfalls gestartet werden. Sie können beispielsweise einfach die Datei foo.service, die Sie selbst geschrieben haben, in das Verzeichnis multi-user.target.wants legen, sodass sie jedes Mal standardmäßig gestartet wird.

[root@kalaguiyin system]#pwd

/etc/systemd/system

[root@kalaguiyin system]#ls

basic.target.wants display-Manager.Service

bluetooth.target.wants                                                                                                                           

dbus-org.bluez.service           graphical.target.wants

TPrinter.target.wants sockets.target.wants

spice-vdagentd.target.wants                                                                                              default.tar get.wants

Lassen Sie uns noch einmal einen Blick auf die Datei sys-kernel-debug.mout werfen. Diese Datei definiert einen Datei-Mount-Punkt:

[root@kalaguiyin system]#cat

sys-kernel-debug.mount

[Einheit]

Description=Debug-Dateisystem

Documentation=https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt

Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

DefaultDependencies=no

ConditionPathExists=/sys/kernel/debug

Before=sysinit.target

[Reittier]

Was=debugfs

Where=/sys/kernel/debug

Type=debugfs

Diese Hive-Datei definiert einen Mount-Punkt. Die Mount-Hive-Datei verfügt über einen Konfigurationsabschnitt [Mount], der drei Datenelemente enthält: Was, Wo und Typ. Diese sind für den Mount-Befehl erforderlich. Die Konfiguration im Beispiel entspricht dem folgenden Mount-Befehl:

mount –t debugfs /sys/kernel/debug debugfs

SystemdSystemverwaltung:

Das wichtigste Befehlszeilentool von

systemd ist systemctl.

Die meisten Administratoren sollten bereits mit der Verwaltung von Systemdiensten und Init-Systemen bestens vertraut sein, beispielsweise mit der Verwendung der Befehle service, chkconfig und telinit. systemd führt ebenfalls dieselben Verwaltungsaufgaben aus, die Syntax des Befehlstools systemctl ist jedoch unterschiedlich.

Dienst starten

systemctl startet httpd.service wie in Abbildung 1 gezeigt:

Dienst einstellen

systemctl stoppt httpd.service, wie in Abbildung 2 gezeigt:

Dienst neu starten

systemctl restarthttpd.service wie in Abbildung 3 dargestellt:

Reload-Service

systemctl reloadhttpd.service

Bedingter Neustart

systemctl condrestarthttpd.service

Statusprüfung

systemctl statushttpd.service

Liste der Dienste, die gestartet oder gestoppt werden können.

systemctl list-unit-files –type=service

Stellen Sie den Dienst so ein, dass er beim Booten startet

chkconfig httpd on

systemctl enablehttpd.service

Dienststart abbrechen;

systemctldisablehttpd.service

Überprüfen Sie, ob ein Dienst so konfiguriert ist, dass er in der aktuellen Umgebung aktiviert oder deaktiviert ist.

systemctl is-enabledhttpd.service;echo $?

Geben Sie die Aktivierung und Deaktivierung von Diensten auf jeder Ausführungsebene aus

systemctl list-unit-files –type=service

Listet die Runlevel auf, auf denen ein Dienst aktiviert und deaktiviert ist.

ls /etc/lib/systemd/system/*.wants/httpd.service

Benutzer-Runlevel ändern:

systemctl isolatemulti-user.target

multi-user.target == 3. Runlevel

graphical.target == 5. Laufebene

runlevel3.target symbolischer Link, der auf multi-user.target verweist

runlevel5.target symbolischer Link, der auf Graphical.target verweist

Standard-Runlevel ändern:

[root@kalaguiyinsystem]# systemctl set-default multi-user.target

rm'/etc/systemd/system/default.target'

ln -s'/usr/lib/systemd/system/multi-user.target''/etc/systemd/system/default.target'

Der Kern des oben genannten Vorgangs besteht darin, /usr/lib/systemd/system/default.target zu löschen und dann die Zieldatei auf Zielebene mit der Datei /etc/systemd/system/default.target zu verknüpfen

systemd ist mehr als nur ein Initialisierungssystem:

systemd ist auch für andere Verwaltungskonfigurationen des Systems verantwortlich, wie z. B. die Konfiguration des Netzwerks, die Verwaltung von Locale , die Verwaltung des Ladens von Systemkernelmodulen usw.

Systemd leistet hervorragende Arbeit beim Ersetzen der gesamten Funktionalität von Sysvinit, ist aber nicht selbstgefällig. Da der Init-Prozess der übergeordnete Prozess aller Prozesse im System ist, eignet sich systemd sehr gut für die Bereitstellung von Funktionen, die zuvor von anderen Diensten bereitgestellt wurden, z. B. geplante Aufgaben (zuvor von crond ausgeführt) Sitzungsverwaltung (zuvor von ConsoleKit/PolKit verwaltet usw.); .). Schon der oberflächlichen Einführung in diesem Artikel nach zu urteilen, hat Systemd bereits viel erledigt, befindet sich aber noch in der Entwicklung. Es wird nach und nach zu einer multifunktionalen Systemumgebung, die viele Systemverwaltungsaufgaben bewältigen kann. Manche Leute betrachten es sogar als Betriebssystem. Dies ist sehr hilfreich bei der Standardisierung der Linux-Verwaltung!

Das obige ist der detaillierte Inhalt vonEingehende Analyse des systemd-Verwaltungssystems unter CentOS 7. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!