systemd

Aus wiki.archlinux.de
Version vom 13. Oktober 2014, 13:06 Uhr von Tapsiturtle (Diskussion | Beiträge) (Das Kapitel == Weitere systemd-Programme == inkl. systemd-timesyncd hinzugefügt)

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.

Systemkonfiguration

Folgende Dateien und systemd-Programme und -Services werden für die Systemkonfiguration bei der Verwendung von systemd benutzt.

Datei systemd-Programm Verwendungszweck
systemctl Administration und Prüfung der verwendeten Services
journalctl Logeinträge prüfen
/etc/hostname hostnamectl Festlegen des Computer-Namens im Netzwerk
/etc/localtime timedatectl Festlegen des Datums, der Uhrzeit, und der Zeitzone
/etc/locale.{conf,gen} localectl Definiert die verwendete Locale des Systems
loginctl Verwaltung der Logins und deren Berechtigungen

Weitergehende Informationen zur Konfiguration enthält der Abschnitt zur Systemkonfiguration der Einsteigeranleitung.

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.

Weitere systemd-Programme

systemd-timesyncd

Aus der systemd mailing list:

systemd-timesyncd is a daemon that been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd.

systemd-timesyncd gehört ab Version 213 zu systemd und steht damit automatisch zur Verfügung.

Damit systemd-timesyncd automatisch gestartet wird, muss der Service entsprechend konfiguriert werden. Näheres hierzu unter #systemctl.

systemctl enable systemd-timesyncd # Für den automatischen Start vormerken …
systemctl start systemd-timesyncd # … und direkt starten

Ein Neustart ist dabei nicht erforderlich.

Zu beachten ist hierbei allerdings, das der Dienst für den Netzzugriff auch den Dienst systemd-networkd benötigt. systemd-networkd wird aber nur benötigt zur Überwachung ob die Netzwerkschnittstelle aktiv ist oder nicht. systemd-networkd kann also parallel zu bereits vorhanden Netwerkdiensten wie netctl betrieben werden.

Konfiguration

Die Konfigurationsdatei befindet sich unter /etc/systemd/timesyncd.conf. Es kann der vorhandene Servers Eintag einkommentiert werden.

/etc/systemd/timesyncd.conf
[Time]
Servers=time1.google.com time2.google.com time3.google.com time4.google.com

Sollten einem die voreingestellten Google Server nicht gefallen, können auch andere NTP Server eingetragen werden.


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 Manpages 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

Weblinks