Systemd
systemd ist ein Ersatz für den System V init Daemon in Linux.
Besonderheiten
- Abwärtskompatibilität zu SysVinit-Scripten
- systemd ist abwärtskompatibel, jedoch werden Features benutzt, welche nur unter Linux verfügbar sind.
- Somit ist er nur auf Systemen mit Linux-Kernel lauffähig.
- Parallelisierung
- Es werden möglichst viele Prozesse gleichzeitig beim Booten gestartet um das System optimal aus zulasten.
- Abhängigkeits-Regeln
- Um bei der Parallelisierung dennoch sicher zustellen dass Dienste welche von anderen Diensten benötigt werden rechtzeitig vor diesen zu starten. (z.B. D-Bus)
- cgroups
- Anstelle von ProzessIDs werden cgroups benutzt. Dies bedeutet, dass Dienste nicht mehr "Abhauen" können. Selbst durch doppeltes Forken.
- Ereignis basiertes Starten von Diensten
- Ähnlich inetd kann systemd Dienste bei Bedarf starten.
- Dies kann z.B. über einen Socket oder Bus geschehen.
- Binärscripte
- Langfristig sollen Shell-Skripte komplett verschwinden und anstelle eines Init-Skripts jeder Dienst eine Konfigurationsdatei erhalten in welcher definiert wird wie dieser zu starten ist.
Verfügbarkeit (01/2015)
| Distribution | Status |
|---|---|
| Fedora | Fedora seit version 15 Standard |
| openSUSE | openSUSE seit 12.1 Standard |
| Mandriva | seit Mandriva 2011 Standart |
| Debian | seit debian 8 jessie Standart |
| Ubuntu | seit 15.04 |
| Arch | seit Oktoper 2012 |
| Red Hat | seit version 7 |
systemd wurde als externe Abhängigkeit für GNOME 3.2 vorgeschlagen.
Units
Systemd wird über Dateien mit einem INI-Datei ähnlichen Format konfiguriert. In der Terminologie von systemd sind dies "Units". Bei Ubuntu vorinstallierte Units sind im Ordner /lib/systemd/system/ gespeichert. Falls sich jedoch eine Unit mit gleichem Namen im Verzeichnis /etc/systemd/system/ befindet, so wird diese bevorzugt und jene unterhalb von /lib ignoriert. Damit hat man die Möglichkeit, eine Unit an eigene Gegebenheiten anzupassen, ohne dass man befürchten muss, dass sie bei einer Systemaktualisierung überschrieben wird. Es existieren verschiedene Typen von Units, die von systemd je nach Endung des Dateinamens unterschiedlich behandelt werden:
| Gegenstand | Typ | Beschreibung |
|---|---|---|
| Orange | 10 | 7.00 |
| Brot | 4 | 3.00 |
| Butter | 1 | 5.00 |
| Total | 15.00 |
{{{#!vorlage Tabelle
<rowclass="kopf">Typ
Beschreibung
+++
`.device`
Legt Gerätedateien an
+++
`.mount`
Ein- und Aushängen von [:mount:Dateisystemen]
+++
`.path`
Startet die Unit via [:inotify:]
+++
`.service`
Für [:Dienste:]
+++
`.socket`
Stellt Verbindungen zwischen Prozessen her
+++
`.target`
Definiert eine Gruppe von Units
+++
`.timer`
Für wiederkehrende Aufgaben, ähnlich [:cron:]-Jobs
}}}
Administration
Runlevel / Targets
| SystemVinit Runlevel | Systemd Target | Kommentar |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | System herunterfahren |
| 1, s, single | runlevel1.target, rescue.target | Einzelnuzer Modus |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Benuzerdefiniert, Standardmäsig identisch zu 3 |
| 3 | runlevel3.target, multi-user.target | Multi-user, Shell. Anmeldung über mehrere Consolen und7oder netzwerk |
| 5 | runlevel5.target, graphical.target | Multi-user, Grafisch. Gewöhnlich alle Dienste aus 3 sowie grafische Oberfläche |
| 6 | runlevel6.target, reboot.target | Reboot |
| emergency | emergency.target | Notfall Shell |
systemctl
aktivieren/deaktivieren systemstart
- systemctl enable
- systemctl disable
service steuern
- systemctl start
- systemctl stop
- systemctl status
- systemctl reload
- systemctl restart
service files anzeigen
- systemctl list-units
- systemctl list-unit-files
Service File
Beispiel:
- /etc/systemd/system/firewall.service
Description=firewall After=network.target syslog.target [Service] RemainAfterExit=yes ExecStart=/usr/local/sbin/firewall start ExecStop=/usr/local/sbin/firewall stop User=root [Install] WantedBy=multi-user.target
Änderungen
Nach Änderungen
- systemctl daemon-reload
journalctl
systemd verwendet standardmäßig ein zentrales Protokoll bzw. Journal, in das von journald alle Logmeldungen geschrieben werden. Zur Abfrage des Journals dient der Befehl journalctl.
FAQ
- Wie setze ich das Runlevel beim Booten?
- Unter systemd werden Runlevel als Targets bezeichnet. Um das Boot "Target" beim Booten zu setzen hängt man z.B. einen der folgenden Kernel Parameter an.
systemd.unit=multi-user.target(entspricht Runlevel 3)systemd.unit=rescue.target(entspricht Runlevel 1)
- Wie setze ich das Standard Target?
- Für Runlevel 3
# systemctl -f enable multi-user.target
- Für Runlevel 5
# systemctl -f enable graphical.target