systemd
systemd ist der Init-Prozess von Arch Linux. Es startet, überwacht, und beendet alle weiteren Services, ist für das mitloggen von Servicerückmeldungen und Benutzerinteraktionen zuständig. Zudem verwaltet systemd die Mounts, und beherrscht die Abhängigkeitsauflösung beim Starten von zusätzlichen Services.
Installation
systemd gehört unter Arch zur Standard-Installation und muss nicht explizit installiert werden.
Wenn eine sehr alte Arch-Installation aktualisiert werden soll, muss an irgendeinem speziellen Punkt während des Updates ein Wechsel von Sysvinit zu systemd erfolgen, da viele Standardprogramme inzwischen systemd voraussetzen. Für die Grundkonfiguration eines Systems für die Verwendung von systemd siehe dort.
Konfiguration
Über mehrere Konfigurationsdateien in /etc/systemd können die Eigenschaften von systemd vorgegeben werden. Über gleichnamige Manpages bekommt man ausführliche Informationen zu den einzelnen Optionen in den jeweiligen Konfigurationsdateien.
In /etc/systemd/system kann man eigene Service-Dateien ablegen. Dies sind Konfigurationsdateien im INI-Format, anhand derer von systemd verwaltbare Services erstellt werden können.
Wichtige systemd-Programme
Das Haupt-Programm systemds ist systemctl. Hierüber werden Services gestartet, gestoppt, deren Status geprüft, sie aktiviert oder deaktiviert, sowie Übersichtslisten über verschiedene Service-Gruppen angezeigt.
Des weiteres wird journalctl verwendet, um alle von systemd angelegten Logeinträge zu betrachten, zu filtern, zu exportieren und zu prüfen.
systemctl
Die vier wichtigsten Parameter für systemctl sind start, stop, enable und disable.
- systemctl
- start servicename startet einen Service einmalig
- stop servicename stoppt einen laufenden Service sauber
- enable servicename aktiviert den Service für den automatischen Start
- disable servicename deaktiviert den Autostart des Services
Über status kann man sich den Service-Status, sowie generelle Informationen über den betreffenden Service anzeigen lassen.
systemctl status sshd
● sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Thu 2014-06-05 05:54:09 CEST; 2 days ago
Main PID: 202 (sshd)
CGroup: /system.slice/sshd.service
└─202 /usr/bin/sshd -D
Hier wird am Beispiel des SSH-Services der aktuelle Status, sowie Systembezogene Informationen angezeigt. Der Service wurde vor zwei Tagen geladen, dazu wurde die Service-Datei /usr/lib/systemd/system/sshd.service, und der Service ist momentan aktiv und funktioniert. Zudem wird er automatisch gestartet (enabled in der Zeile „Loaded“).
systemctl status sshd
● sshd.service - OpenSSH Daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) Active: inactive (dead) since Sat 2014-06-07 21:47:14 CEST; 7min 14s ago Process: 202 ExecStart=/usr/bin/sshd -D (code=exited, status=0/SUCCESS) Main PID: 202 (code=exited, status=0/SUCCESS)
Hier wurde der SSH-Service vor knapp über 7 Minuten angehalten, ist aber nach wie vor für den automatischen Start vorgesehen.
systemctl status sshd
● sshd.service - OpenSSH Daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled) Active: inactive (dead)
Der Service ist gestoppt, und nicht für den automatischen Start vorgesehen.
Man kann sich zudem den Status von Mounts anzeigen lassen, indem man die entsprechende Bezeichnung oder Gerätedatei übergibt.
systemctl status /home
● home.mount - /home
Loaded: loaded (/etc/fstab)
Active: active (mounted) since Thu 2014-06-05 05:54:08 CEST; 2 days ago
Where: /home
What: /dev/sda3
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Hier wird angezeigt, dass /home über die fstab eingebunden wird, und vor zwei Tagen gemountet wurde.
systemctl status /dev/sda2
● dev-sda2.device - WDC_WD3200AAKS-75L9A0 swap Follow: unit currently follows state of sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device Loaded: loaded Active: active (plugged) Device: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2
Auf /dev/sda2 wird der Swap abgelegt, dieser wird von systemd verwaltet.
Systemverwaltung mit systemctl
Neben der Serviceverwaltung dient systemctl auch zur Systemverwaltung.
- systemctl
- halt hält das System an, ohne es auszuschalten
- poweroff hält das System an, und schaltet es aus
- reboot startet das System neu
- hibernate versetzt das System in den Ruhezustand
Je nach Konfiguration können diese Befehle auch mit Useraccounts ausgeführt werden, und bedürfen keinen root-Rechten.
journalctl
Das Programm journalctl dient als Schnittstelle zu journald, systemds Logeintragsservice. Je nach Konfiguration kann das Journal nur im Arbeitsspeicher abgelegt werden, auf ein entferntes Gerät geschrieben werden, ganz regulär in Dateien gesichert werden, oder auch signiert, und so gegen Manipulation geschützt werden.
Durch die Eingabe von nur journalctl wird das aktuell angelegte System-Log angezeigt, anhand dessen Fehler analysiert werden können. Darüber hinaus bietet das Programm noch eine Vielzahl an weiteren Optionen
journalctl --list-boots
[…] -3 4f8ea7eaf576422abeabbcf6bd01a482 Thu 2014-05-19 08:54:18 CEST—Sat 2014-05-25 22:15:54 CEST -2 8b3e482a56c04128902b3bc627221865 Thu 2014-05-27 05:54:04 CEST—Sat 2014-06-01 20:55:12 CEST -1 a39ac4caa1a84de9be632afe48d79021 Thu 2014-06-02 07:31:14 CEST—Sat 2014-06-03 16:38:21 CEST 0 42672184a2d7485ea7288c250f6d2dee Thu 2014-06-05 05:54:04 CEST—Sat 2014-06-07 21:50:26 CEST
Es wird eine Tabelle mit allen bisherigen Boots, sowie der Zeit, zu der das System heruntergefahren wurde ausgegeben. Damit diese Liste nicht unnötig lang wird, kann mittels -b ein Offset angegeben werden, zum Beispiel listet -b -5 die letzten fünf Boots auf, während -b 5 die ersten fünf Boots auflisten würde. Die Angabe vor dem Datum ist die Boot-ID, anhand derer alle Logeinträge des jeweiligen Zeitraums gefiltert werden können. Will man anhand des Beispiels alle Meldungen des Betriebszeitraums vom 27. Mai bis 01. Juni ansehen, geht dies wie folgt.
journalctl --boot 8b3e482a56c04128902b3bc627221865
Es werden dann alle diesen Zeitraum betreffenden Meldungen angezeigt. --boot kann in Mombination mit allen Funktionen von journalctl verwendet werden.
journalctl --boot a39ac4caa1a84de9be632afe48d79021 --unit ntpd --output json
Hiermit werden alle Logeinträge bezüglich des Services ntpd für den Beispielzeitraum vom 02. Juni bis zum 03. Juni als JSON formatiert ausgegeben. Mit der kombination verschiedener Optionen kann man sich also seine „Wunschformatierung“ nach belieben selbst erstellen.
Eigene Services erstellen
Eigene Services werden in /etc/systemd/system abgelegt, und sind einfache INI-Dateien, in denen die Anweisungen für systemd stehen. Dieses generiert aus der Datei eine Service-Unit, die mittels systemctl verwaltet werden kann, und deren Verhalten von journald geloggt und über journalctl eingesehen werden kann.
[Unit] Description=OpenSSH Daemon Wants=sshdgenkeys.service After=sshdgenkeys.service After=network.target [Service] ExecStart=/usr/bin/sshd -D ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=always [Install] WantedBy=multi-user.target
Die Service-Datei für den SSH-Daemon (eigentlich „Service“) beinhaltet drei Abschnitte. Zuerst werden Informationen für die Service-Unit verzeichnet. Darunter die Beschreibung, und welche anderen Units von dem Service benötigt werden, und wann der Service in Abhängigkeit zu anderen Units gestartet werden soll. Darunter befindet sich in diesem Fall die eine Target-Unit, nämlich die für das Netzwerk, das heißt, die Service-Unit für SSH startet erst dann den SSH-Service, wenn die Target-Unit für das Netzwerk gestartet wurde, und verlangt dann wiederum die Service-Unit sshdgenkeys, nach derer sie den SSH-Service erst startet.
Der Service selbst besteht im Abschnitt [Service] aus mehreren Befehlen, die auch mehrfach vorkommen können. Hier werden die eigentlichen Programme des Services, sowie sein Verhalten definiert. Zudem gibt es hier noch einen Abschnitt [Install], der Installationsinformationen für die Unit bereithält. Dieser Abschnitt ist nicht verpflichtend. Es müssen lediglich [Unit] und gemäß der Logik [Service] enthalten sein.
Die Manpages systemd.unit und systemd.service beinhalten ausführliche Informationen zum erstellen von eigenen Service-Units, sowie verweise auf weitere Manapges zum erstellen von anderen Units.
Variablen
Service-Dateien können Variablen enthalten. Einige wichtige Variablen zeigt die folgende Tabelle auf.
| Variable | Inhalt | Info |
|---|---|---|
%n
|
Name | Zugriff auf den vollständigen Unit-Namen |
%i
|
Instanzname | Units, die ein @ im Dateinamen haben, können mittels systemctl start name@wert gestartet werden, hiermit kann auf wert zugegriffen werden.
|
%u
|
Benutzername | Zugriff auf den namen des für diese Unit konfigurierten Useraccounts, oder – wenn nicht gesetzt – den Useraccountnamen des Users, unter dem systemd läuft. |
%b
|
Boot-ID | Die weiter oben beschriebene Boot-ID kann ebenfalls in Unit-Definitionen verwendet werden. |
Eine ausführliche Liste aller Variablen, sowie eine ausführliche Beschreibung eben dieser beinhaltet die Manpage systemd.unit.
Siehe auch
- Wechsel von Sysvinit zu systemd – wenn nicht bereits geschehen
- ArchLinux mit verschlüsseltem LVM und Systemd
