Dokumentation5.4. Verwalten von Diensten
Kali verwendet systemd als Init-System, das nicht nur für die Boot-Sequenz verantwortlich ist, sondern auch permanent als vollwertiger Service-Manager fungiert und Dienste startet und überwacht.
systemd abgefragt und gesteuert werden können systemctl. Ohne jedes Argument wird das ausgeführt systemctl list-units Befehl, der eine Liste der aktiven ausgibt Bereiche. Wenn du läufst Systemctl-Status, die Ausgabe zeigt eine hierarchische Übersicht der ausgeführten Dienste. Wenn man beide Ausgaben vergleicht, sieht man sofort, dass es mehrere Arten von Einheiten gibt und dass Dienste nur eine davon sind.
Jeder Dienst wird durch a dargestellt Serviceeinheit, die durch eine normalerweise mitgelieferte Servicedatei beschrieben wird
/lib/systemd/system/ (oder /run/systemd/system/ oder /etc/systemd/system/; sie werden in aufsteigender Reihenfolge ihrer Wichtigkeit aufgelistet, und der letzte gewinnt). Jeder wird möglicherweise durch den anderen modifiziert Dienstname.service.d/*.conf-Dateien im gleichen Verzeichnissatz. Bei diesen Unit-Dateien handelt es sich um reine Textdateien, deren Format an die bekannten „*.ini“-Dateien von Microsoft Windows angelehnt ist Haupt
= Wert Paare gruppiert zwischen [Abschnitt]-Kopfzeilen. Hier sehen wir eine Beispiel-Servicedatei für /lib/systemd/system/ssh.service:
[Einheit]
Beschreibung=OpenBSD Secure Shell-Server After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Bedienung]
EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process
Restart=bei Fehler RestartPreventExitStatus=255 Type=notify
[Installieren]
WantedBy=multi-user.target Alias=sshd.service
[Einheit]
Beschreibung=OpenBSD Secure Shell-Server After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Bedienung]
EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process
Restart=bei Fehler RestartPreventExitStatus=255 Type=notify
[Installieren]
WantedBy=multi-user.target Alias=sshd.service
Zieleinheiten sind ein weiterer Teil des Systemsd-Designs. Sie stellen einen gewünschten Zustand dar, den Sie in Bezug auf aktivierte Einheiten erreichen möchten (was im Fall von Serviceeinheiten einen laufenden Dienst bedeutet). Sie dienen hauptsächlich dazu, Abhängigkeiten von anderen Einheiten zu gruppieren. Wenn das System startet, aktiviert es die Einheiten, die zum Erreichen des Ziels erforderlich sind default.target (das ist ein symbolischer Link zu grafisches.Ziel, und was wiederum davon abhängt Mehrbenutzerziel). Daher werden alle Abhängigkeiten dieser Ziele beim Booten aktiviert.
Solche Abhängigkeiten werden mit ausgedrückt Will Direktive für die Zieleinheit. Sie müssen die Zieleinheit jedoch nicht bearbeiten, um neue Abhängigkeiten hinzuzufügen. Sie können auch einen Symlink erstellen, der auf die Zieleinheit verweist
abhängige Einheit in der / etc / systemd / system /Zielname.target.wants/ Verzeichnis. Und genau das ist es systemctl aktivieren foo.service tut. Wenn Sie einen Dienst aktivieren, weisen Sie systemd an, eine Abhängigkeit von den im aufgeführten Zielen hinzuzufügen Gesucht von Eintrag der [Installieren] Abschnitt der Service-Unit-Datei. Umgekehrt, systemctl deaktivieren foo.service löscht den gleichen Symlink und damit die Abhängigkeit.
Der ermöglichen und deaktivieren Befehle ändern nichts am aktuellen Status der Dienste. Sie beeinflussen nur, was beim nächsten Booten passiert. Wenn Sie den Dienst sofort ausführen möchten, sollten Sie ihn ausführen systemctl starten foo.service. Umgekehrt können Sie es mit stoppen systemctl stoppen foo.service. Sie können den aktuellen Status eines Dienstes auch mit überprüfen Systemctl-Status foo.service, die sinnvollerweise die neuesten Zeilen des zugehörigen Protokolls enthält. Nachdem Sie die Konfiguration eines Dienstes geändert haben, möchten Sie ihn möglicherweise neu laden oder neu starten: Diese Vorgänge sind damit erledigt systemctl neu laden foo.service und systemctl neu starten foo. Service beziehungsweise.
# systemctl-status postgresql
● postgresql.service – PostgreSQL-RDBMS
Geladen: geladen (/lib/systemd/system/postgresql.service; deaktiviert; Herstellervoreinstellung:
➥ deaktiviert)
Aktiv: inaktiv (tot)
# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service
ls: kann nicht auf „/etc/systemd/system/multi-user.target.wants/postgresql.service“ zugreifen: Nein
➥ eine solche Datei oder ein solches Verzeichnis
# systemctl aktivieren postgresql
[...]
# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service
lrwxrwxrwx 1 root root 38 21. April 16:21 /etc/systemd/system/multi-user.target.wants/
➥ postgresql.service -> /lib/systemd/system/postgresql.service
# systemctl-status postgresql
● postgresql.service – PostgreSQL-RDBMS
Geladen: geladen (/lib/systemd/system/postgresql.service; aktiviert; Herstellervoreinstellung:
➥ deaktiviert)
Aktiv: inaktiv (tot)
# systemctl starten postgresql
# systemctl-status postgresql
● postgresql.service – PostgreSQL-RDBMS
Geladen: geladen (/lib/systemd/system/postgresql.service; aktiviert; Herstellervoreinstellung:
➥ deaktiviert)
Aktiv: aktiv (beendet) seit Do 2016 04:21:16 EDT; Vor 22s Prozess: 29 ExecStart=/bin/true (Code=exited, Status=2/SUCCESS)
Haupt-PID: 6355 (Code=exited, Status=0/SUCCESS)
21. April 16:22:29 kali-rolling systemd[1]: PostgreSQL RDBMS wird gestartet... 21. April 16:22:29 kali-rolling systemd[1]: PostgreSQL RDBMS gestartet.