Systemd/Grundlagen

Grundlagen

Aktuelle Versionen von Fedora, OpenSuse, Mandriva und einigen anderen Distributionen starten das System bereits mit Systemd

Das Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit und erfordert andere Kniffe als Sysvinit, wenn es Probleme gibt

Sysvinit- und Upstart

Einige von Sysvinit- und Upstart-Distributionen gewohnte Kommandos und Tricks arbeiten durch Kompatibilitätsmaßnahmen auch unter Systemd Um die Fähigkeiten von Systemd richtig zu nutzen, sollte der Administrator allerdings auch Werkzeuge und Parameter von Systemd kennen

systemctl

Wichtigstes Tool zur Interaktion mit Systemd ist das Kommandozeilenprogramm systemctl

Für Änderungen an der Konfiguration oder den Neustart von Hintergrunddiensten erfordert es Root-Rechte; einige Diagnose-Aufrufe dürfen auch einfache Anwender ausführen

Aufruf

Wer das Programm ohne jegliche Parameter aufruft, erhält eine Liste der "Units", die beim Systemstart anfallende Aufgaben erledigen

Dazu gehört neben dem Einbinden und Prüfen von Datenträgern auch das Starten von Hintergrunddiensten oder das Einrichten von Hardware

Bei einer Standardinstallation von Fedora 16 listet Systemctl rund hundertsechzig aktive Units in zehn verschiedenen Spielarten

Zu den wichtigsten zählen Service-Units
Sie kümmern sich um Hintergrunddienste, die eine Sysvinit-Distribution typischerweise über Init-Skripte startet
Mount- und Automount-Units binden Dateisysteme ein

Socket-Units

Socket-Units legen Sockets an; sie starten indirekt über Abhängigkeiten einen andere Unit, sobald auf den Socket zugegriffen wird. (Eine detaillierte Erläuterung des Unit-Konzepts finden Sie im ersten Teil des Artikels.)

Über einen Parameter kann man Systemctl anweisen, nur Units eines bestimmten Typs aufzulisten, etwa alle Service-Units:

systemctl --type=service

Systemctl leitet seine Ausgabe automatisch an less weiter; über die Pfeiltasten lässt sich nicht nur hoch- und runterscrollen, sondern auch nach rechts, denn dort verbergen sich manchmal weitere Informationen

In der ersten Spalte der Ausgabe findet sich der Unit-Name

Die zweite Spalte gibt an, ob Systemd die Unit-Definition laden konnte, die dritte, ob die Unit aktiv ist
Inaktive – installierte, aber nicht zum Start vorgesehene – Units gibt das Programm nur mit dem Schalter -a aus; dasselbe gilt für Units, die das Init-System etwa aufgrund eines Fehlers in der Unit-Datei nicht laden konnte

Spalte vier liefert den aktuellen Status. "exited" zeigt an, dass sich der Prozess ohne Fehler beendet hat

Das ist zum Beispiel bei Diensten der Fall, die im Hintergrund weiterlaufen – etwa bei der Service-Unit, die aus Kompatibilitätsgründen die von Sysvinit bekannte Datei /etc/rc.local beim Systemstart ausführt. "running" steht bei Diensten, die im Hintergrund laufen: cron, dbus, sshd, udev und andere

In der fünften Spalte folgt eine Beschreibung der Unit

Wenn sie mit "LSB" oder "SYSV" beginnt, hat Systemd die Unit automatisch erzeugt, um ein traditionelles Init-Skript abzuarbeiten

Bei Diensten, die nicht gestartet werden konnten oder später abgestürzt sind, steht in der vierten Spalte "failed" – rot hervorgehoben, sofern die Konsole farbige Ausgabe beherrscht

Das status-Kommando von sytemctl gibt den Zeitpunkt des Abbruchs und den zurückgelieferten Fehlercode des Programms aus, beispielsweise

systemctl status NetworkManager.service

Bei einem frisch installierten Fedora 16 listet Systemctl um die 60 Service-Units auf

Darunter sind auch die Login-Prozesse für die Textkonsolen (agetty), denn anders als Sysvinit handhabt Systemd diese über Service-Units wie einen normalen Hintergrunddienst

Units

Die Konfigurationsdateien zum Erzeugen der Units, die Systemd mitbringt, liegen in /lib/systemd/system/; eine gleichnamige Datei in /etc/systemd/system/ hat jedoch Vorrang

Unit-Definition sind meist deutlich kürzer als die klassischen Sys-V-Init-Skripte

Eine Unit-Datei für den Dienst zur Netzwerkzeit-Synchronisierung via NTP ist nur wenige Zeilen lang:

[Unit] Description=Network Time Service [Service] ExecStart=/usr/bin/ntpd -n -u ntp:ntp -g [Install] WantedBy=multi-user.target

Alle Unit-Dateien enthalten einen durch [Unit] eingeleiteten Abschnitt mit allgemeinen Einstellungen, darunter eine kurze Beschreibung

Im Abschnitt [Service] folgen dienstspezifische Angaben; bei NTP ist das lediglich das Kommando, um den Dienst zu starten
Falls ein spezieller Befehl zum Beenden nötig ist, kann man diesen über eine ExecStop-Anweisung festlegen

Beim NTP-Daemon ist das unnötig, weil er sich in guter Unix-Tradition durch ein SIGTERM-Signal beenden lässt; das sendet Systemd zum Beenden, wenn kein anderer Befehl spezifiziert ist

Der Abschnitt [Install] enthält Anweisungen, die Systemd bei der (De-)Installation interpretiert; der Eintrag im NTP-Beispiel bedeutet, dass die Zeitsynchronisation beim Ansteuern des Targets "Multi-User" aufgerufen werden soll

Targets

Die Targets-Units bieten ein Konzept, das den Runlevels von Sysvinit ähnelt; aus Kompatibilitätsgründen versteht Systemd sogar die Runlevel-Namen zur Ansteuerung äquivalenter Targets

Wie gewohnt kann man daher bei Fedora 16 dem Kernel im Boot-Loader den Parameter single mitgeben; Systemd steuert daraufhin rescue.target an, das eine minimale, dem Single-User-Modus entsprechende Umgebung bietet

Auch 3 funktioniert, um den Multi-User-Modus ohne grafischen Anmeldemanager anzusteuern

Repräsentiert wird dieser Modus in Systemd durch die Target-Unit multi-user
Um multi-user.target zum Standard zu machen, reicht ein Links:

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Soll der grafische Anmeldemanager später doch wieder standardmäßig starten, kann man auf die gleiche Weise graphical.target zum Standardziel erheben; es ist das Äquivalent zum Runlevel 5 von Fedora und OpenSuse

Alternativ zu den alten Runlevel-Bezeichnungen kann man dem Kernel auch die Namen der zu startenden Target-Unit mitgeben:

systemd.unit=multi-user.target

Um im Betrieb eine andere Target-Unit anzusteuern, dient das isolate-Kommando von Systemctl:

systemctl isolate rescue.target

Der Wechsel in das Rescue-Target ist für Administrationsaufgaben interessant, denn dabei beendet Systemd alle User-Logins und Hintergrunddienste, sodass nur noch Systemdienste laufen – etwa jene zur Überwachung von Logical Volumes (lvm2-monitor)

Manchmal müssen auch diese für Umbauten heruntergefahren werden, was mit dem Notfall-Modus emergency.target gelingt; hier laufen nur noch die Kernel-Threads

Verlangen

Das show-Kommando von Systemctl liefert einige Interna zu den laufenden Units und den über sie ausgeführten Arbeiten

Mit ihm lässt sich auch ausgeben, welche Units Systemd beim Ansteuern des Multi-User-Targets aufruft:

systemctl show -p Wants multi-user.target

In der Ausgabe können sich andere Targets finden – beim multi-user.target etwa basic.target

Das wiederum hängt vom sysinit.target ab, das local-fs.target voraussetzt

Diese drei Targets kümmern sich um die Grundeinrichtung des Systems; dazu zählen das Einbinden der Dateisysteme und der Start von Udev

Zum Spezifizieren der Abhängigkeit vom Basic-Target enthält die Unit-Konfigurationsdatei multi-user.target folgende Angaben:

Requires=basic.target
After=basic.target

Durch die After-Angabe erfährt Systemd, dass es das Target nicht nur aufrufen, sondern auch den seinen vollständigen Start abwarten muss

Neben Requires gibt es auch noch das schwächere Wants

Darüber angegebene Units ruft Systemd ebenfalls auf, setzt den Start aber auch fort, wenn eine von ihnen nicht startet

Diese Art der Abhängigkeit lässt sich auch über Links zu Unit-Dateien spezifizieren, die in einem Verzeichnis angelegt werden, dessen Name sich aus dem Namen der target-Unit und angehängtem .wants zusammensetzen, etwa

.../systemd/system/multi-user.target.wants/

Deaktivieren

Wer die NTPD-Service-Unit deaktivieren will, damit die Systemzeit beim Booten nicht via NTP synchronisiert wird, kann das folgenden Befehl tun:

systemctl disable ntpd.service

Dabei macht Systemctl nichts anderes, als den Link auf die Service-Unit-Datei in den Wants-Verzeichnissen zu entfernen; beim Aktivieren eines Dienstes mit enable erstellt das Tool einen Link

Beides kann man auch manuell tun, um Units zu (de)aktiviern

Wird ein Dienst nicht von einer Unit, sondern über ein traditionelles Init-Skript gestartet, leitet Systemctl die Aufforderung zum Aktivieren an das Programm chkconfig weiter

Bei Fedora ist das etwa der Fall, wenn man Apache installiert und via Systemctl aktiviert

Das (De)Aktivieren eines Dienstes wirkt sich erst beim nächsten Start oder Beenden des Systems aus

Folgendes Kommando startet einen Dienst einmalig sofort:

systemctl start ntpd.service

Der Parameter stop beendet den Dienst

Mit dem Kommando status liefert Systemctl Information über die Unit, darunter ihren derzeitigen Zustand und den Namen der sie spezifizierenden Datei
Zudem gibt das Programm aus, ob und wie lange der Dienst bereits läuft und welche Prozesse zu ihm gehören; den Hauptprozess weist Systemctl dabei explizit aus

Über die Zugehörigkeit zu den von Systemd angelegten Control Groups lässt sich recht einfach herausfinden, welche Prozesse von welchem Dienst gestartet wurden

Die von Systemd angelegte Cgroup-Hierarchie gibt der Befehl systemd-cgls aus; alternativ zeigt ps die Gruppenzugehörigkeit an:

ps xaw -eo pid,args,cgroup

Systemstart Probleme

Falls beim Systemstart Probleme auftreten, an denen Systemd direkt oder indirekt beteiligt scheint, sollten Sie dem Kernel die folgenden Parameter im Boot-Loader mitgeben:

systemd.log_target=kmsg systemd.log_level=debug

Systemd schreibt dann ausführliche Informationen zur Fehlersuche auf die Konsole und in den Puffer der Kernel-Meldungen, den man später mit dmesg auslesen kann

Zu Systemd gehören die Kommandozeilenprogramme poweroff, halt und reboot; alternativ kann man das System über die gleichlautenden Systemctl-Kommandos herunterfahren oder neu starten

Einen Neustart erreicht man auch mit dem Kommando

systemctl kexec

Nach dem Stoppen aller Dienste weist Systemd den laufenden Kernel an, einen zuvor konfigurierten Linux-Kernel direkt zu starten – ohne BIOS-Selbsttest und Boot-Loader

Ist kein Kexec-Kernel konfiguriert, erfolgt ein normaler Neustart

Administrationsaufgaben

Bei gängigen Administrationsaufgaben kommt man nur mit den Service- und Target-Units direkt in Kontakt; die anderen Units sind vor allem für spezielle Funktionen von Systemd wichtig oder erledigen beim Systemstart all jene Dinge, um die sich bei Sysvinit- und Upstart-Distributionen distributionsspezifische Skripte gekümmert haben

Dazu gehört etwa das Einbinden der in /etc/fstab spezifizierten Dateisysteme, das Aktivieren von Auslagerungsspeicher oder das gelegentliche Aufräumen des /tmp-Verzeichnisses

Für einige dieser Arbeiten bringt Systemd eine Automount-Funktion mit, die Pseudo-Einhängepunkte für in /etc/fstab konfigurierte Dateisysteme anlegen kann; tatsächlich eingebunden werden sie allerdings erst beim ersten Zugriff

Das Hinzufügen von "comment=systemd.automount" in /etc/fstab verwandelt einen beliebigen Mount-Punkt in einen Automount-Punkt

Das kann den Startvorgang beschleunigen und ist beispielsweise für Netzwerkfreigaben nützlich, wenn die Netzverbindung über den NetworkManager erst beim Einloggen eines Users aufgebaut wird

Fehleranalyse

Über Systemctl kann man Systemd zum Senden eines Signals auffordern, ohne die Prozess-ID des Dienstes zu kennen

Der folgende Befehl versetzt Rsyslogd in den Debug-Modus; dieser wird beendet, wenn man den Befehl ein zweites Mal aufruft:

systemctl kill --signal=USR1 rsyslogd.service

Wenn man die Angabe des zu sendenden Signals weglässt, schickt Systemctl ein normales Term-Signal, woraufhin sich alle Prozesse beenden sollten, die zu einem Dienst gehören

Der Befehl systemd-analyze gibt aus, wie lange der Systemstart gedauert hat und wie viel Zeit davon auf Kosten von Kernel, Initramfs und die Einrichtung des Userlands durch Systemd entfallen

Der Befehl systemd-analyze blame gibt die Startzeiten der einzelnen Units aus
Zur genaueren Betrachtung des Boot-Prozesses kann das Programm eine SVG-Datei erzeugen, die den Start der Units visualisert:

systemd-analyze plot > plot.svg

Manchmal kommt man so Units auf die Spur, die den Systemstart stark in die Länge ziehen

Einige Hinweise zur korrekten Interpretation dieser Ergebnisse liefert der siebte Teil der Blog-Reihe "Systemd for Administrators"

Die bislang zwölf Teile umfassende Serie enthält auch noch viele andere Tipps und Hinweise für den Praxiseinsatz vom Systemd: # Verifying Bootup

Which Service Owns Which Processes?
How Do I Convert A SysV Init Script Into A systemd Service File?
Killing Services
The Three Levels of "Off"
Changing Roots
The Blame Game
The New Configuration Files
On /etc/sysconfig and /etc/default
Instantiated Services
Converting inetd Services
Securing Your Services

Lennart Poettering

Über die Homepage von Lennart Poettering finden sich zudem zahlreiche weitere Artikel mit Hintergründen zum Init-System

Im dritten "Systemd Status Update" hat Poettering zudem vor Kurzem einige der Neuerungen aufgelistet, die in den letzten eineinhalb Jahren in Systemd eingeflossen sind

Dienste konfigurieren

Systemd startet im Bootprozess unter anderem einen SSH-Daemon, hängt eine Partition ein und konfiguriert eine Netzwerkschnittstelle

Alle diese einzelnen kleinen Aufgaben bezeichnet Systemd als Units

Die wiederum lassen sich noch einmal nach ihrem jeweiligen Einsatzzweck klassifizieren

So kümmern sich Service-Units um das Starten und Stoppen von Diensten, Mount- und Automount-Units helfen beim Ein- und Aushängen von Dateisystemen, während wiederum Socket-Units die benötigten Sockets öffnen

Für jede dieser Units muss der Administrator eine eigene kleine Konfigurationsdatei erstellen

Ihr Dateiname setzt sich aus dem Namen der Unit und dem entsprechenden Unit-Typ zusammen

Beim SSH-Daemon handelt es sich zweifelsohne um einen Dienst, weshalb die Konfigurationsdatei sshd.service heißt

Systemd bringt bereits Unit-Dateien für die wichtigsten Systemdienste mit

Diese lagern normalerweise im Unterverzeichnis "/usr/lib/systemd/system/" (in früheren Systemd-Versionen "/lib/systemd/system")

Zusätzlich existiert noch das Verzeichnis "/etc/systemd/system/"

In ihm sollen Administratoren ihre eigenen Unit-Dateien speichern
Alle dort gelagerten Unit-Dateien haben Vorrang vor den Einstellungen ihrer gleichnamigen Kolleginnen unter "/usr/lib/systemd/system/"

Diese Trennung hat den Vorteil, dass ein Update der Distribution keine geänderte Unit-Datei überschreibt

Listing sshd.service

[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target

Target-Auswahl

Systemd startet immer automatisch das "default.target"

Ein anderes Target können Sie am Bootprompt über den Parameter "systemd.unit" vorgeben

Mit "systemd.unit=rescue.target" würde Systemd beispielsweise ein Rettungssystem starten. "default.target" ist zudem für gewöhnlich nur ein symbolischer Link auf ein anderes Target, bei einem Desktop-System etwa auf "graphical.target"

Wer ein anderes Target zum Standard küren möchte, muss somit lediglich den Link umbiegen

In folgendem Fall würde Systemd zukünftig immer in das "multi-user.target" starten:

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

Um den Prozess eines Dienstes abzuschießen, müssen Sie lediglich den Namen der Service-Unit kennen, um den Rest kümmert sich "systemctl"

Im folgenden Beispiel sendet Systemd ein SIGTERM-Signal an den SSH-Daemon:

systemctl kill --signal=SIGTERM sshd.service

Das Kommando "systemctl reboot" startet das System neu, "systemctl poweroff" fährt das System kontrolliert herunter und schaltet es aus

Ergänzend zu "poweroff" gibt es noch "suspend", "hibernate" und "hybrid-sleep", die in die entsprechenden Schlafzustände wechseln

Zu diesen Befehlen gibt es noch handliche Kurzformen, anstelle von "systemctl reboot" funktioniert beispielsweise auch einfach "reboot"

Datei:Bild2.png

Bild 3: Dieses System mit CentOS 7 hat knapp 50 Sekunden für den kompletten Start benötigt

Gebremst haben vor allem Plymouth und die Firewall (in Form von "firewalld")

Changing the Default Boot Target

$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

This line makes the multi user target (i.e

full system, but no graphical UI) the default target to boot into
This is kinda equivalent to setting runlevel 3 as the default runlevel on Fedora/sysvinit systems

$ ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

This line makes the graphical target (i.e

full system, including graphical UI) the default target to boot into
Kinda equivalent to runlevel 5 on fedora/sysvinit systems
This is how things are shipped by default

Unit Files

Ein zentrales Konzept von systemd sind die Unit-Files

Diese ersetzen die Init-Skripte von anderen Systemen und sind wesentlich einfacher aufgebaut

Unit Typen

Es gibt verschiedene Arten von Unit Files, nachfolgend ein paar Beispiele:

Unit Files
Dienste	Typen
.service	Typ für normale Dienste
.target	Zieltyp, dient zum Beispiel als Ersatz für Runlevels (graphical.target), aber auch für Zwischenschritte (network.target, local-fs.target, ...)
.mount	Typ für Mountpoints, meist automatisch durch systemd-fstab-generator erzeugt
.socket	Typ für Socket Activation von Diensten

Units gleichzeitig starten

Ein neu gestarteter Server sollte ein funktionierendes Netzwerk bieten, den Multiuser-Betrieb unterstützen und schließlich auch noch den SSH-Daemon zünden

Systemd muss folglich automatisch ein paar fest vorgegebene Units starten

Um das zu erleichtern, lassen sich mehrere Units zu einer Gruppe zusammenfassen, dem sogenannten Target

Systemd kann dann alle Units aus einem Target auf einen Schlag starten beziehungsweise aktivieren

Einige praxisrelevante Targets liegen Systemd bereits bei

So umfasst das Target "multi-user.target" alle Units, die für den Multiuser-Netzwerkbetrieb notwendig sind, während das Target "graphical.target" zu einem Desktop mit grafischer Benutzeroberfläche führt

Die Targets ersetzen damit gleichzeitig die alten Runlevel von SysV-Init: Weist der Administrator Systemd an, das Target "graphical.target" zu aktivieren, sitzt er anschließend vor einem System mit grafischer Benutzeroberfläche, wie es üblicherweise der Runlevel 5 zur Verfügung stellt

Targets sind selbst wieder normale Units

Das hat den Vorteil, dass ein Target ein anderes verwenden beziehungsweise starten kann

Das nutzen die mitgelieferten Targets massiv aus: "graphical.target" aktiviert etwa erst dann die grafische Benutzeroberfläche, wenn "multi-user.target" das restliche System eingerichtet hat

What units does a unit depend on?

For example, if you want to figure out which services a target like multi-user.target pulls in, use something like this:

$ systemctl show -p "Wants" multi-user.target

Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service netfs.service

Instead of "Wants" you might also try "WantedBy", "Requires", "RequiredBy", "Conflicts", "ConflictedBy", "Before", "After" for the respective types of dependencies and their inverse

Aufbau der Unit-Dateien

Unit-Dateien sind recht einfach aufgebaut

Das Listing "sshd.service" zeigt als Beispiel die Unit-Datei des SSH-Daemons aus CentOS 7 und damit schon einen etwas umfangreicheren Vertreter
Jede Unit-Datei ist in mehrere Abschnitte unterteilt, jede Zeile enthält genau eine Einstellung

Im Abschnitt "[Unit]" liefert "Description=" zunächst eine kurze Beschreibung der Unit

Hinter "After=" folgen, jeweils durch ein Leerzeichen getrennt, alle Units und Targets, die der Dienst zwingend für seine Arbeit benötigt

Im Beispiel startet der SSH-Daemon erst dann (und wirklich erst dann), wenn die Logging-Dienste ("syslog.target"), das Netzwerk ("network.target") und der Audit-Dienst ("auditd.service") verfügbar sind

Neben "After" gibt es noch die etwas weniger restriktiven "Requires" und "Wants": Alle Units hinter "Requires=" startet Systemd parallel mit der neu definierten Unit

Deaktiviert der Administrator eine der aufgeführten Units, knipst Systemd auch automatisch der neuen Unit das Licht aus

Sämtliche hinter "Wants=" gelisteten Units startet Systemd ebenfalls parallel mit der neu definierten Unit

Letztgenannte aktiviert Systemd aber selbst dann, wenn eine der anderen Units abstürzt oder aus einem anderen Grund nicht verfügbar ist

Im Abschnitt "[Service]" folgen alle Informationen, die Systemd zum Aktivieren des Dienstes benötigt

Der Befehl zum Starten des SSH-Daemons findet sich hinter "ExecStart=", alle anderen Angaben sind optional
Im Listing "sshd.service" holt zunächst "EnvironmentFile=" ein paar Umgebungsvariablen aus der angegebenen Datei hinzu
Das Programm hinter "ExecStartPre=" führt Systemd immer direkt vor dem eigentlichen Dienst aus

Wenn Systemd den Dienst beenden muss, schickt er ihm ein SIGTERM-Signal, auf das alle guten Prozesse reagieren sollten

Im Listing "sshd.service" sorgt "KillMode=process" noch dafür, dass Systemd nur den SSH-Daemon selbst, nicht aber seine Kindprozesse abwürgt
Lässt sich der Dienst anders als der SSH-Daemon nur mit einem speziellen Befehl herunterfahren, notiert man diesen hinter "ExecStop="

Mit welchem Kommando Systemd den Dienst neu startet, verrät "ExecReload="

Wann das passiert, bestimmt der Wert hinter "Restart="
In Listing "sshd.service" passiert das automatisch, wenn sich der SSH-Daemon unerwartet beendet ("on-failure")

Mit dem Neustart wartet Systemd zudem sicherheitshalber 42 Sekunden ("RestartSec=42s")

Diese Verzögerung soll unter anderem verhindern, dass der Dienst immer wieder schnell hintereinander neu startet und so unnötig Rechenzeit frisst

Der Abschnitt "[Install]" verrät schließlich noch, zu welchen Targets die Unit gehört

Im Listing sorgt die letzte Zeile dafür, dass der SSH-Daemon immer zusammen mit dem Target "multi-user.target" startet

Alternativ können Sie die Zugehörigkeit auch über symbolische Links vorgeben

Dazu erstellen Sie zunächst im Verzeichnis "/etc/systemd/system/" ein neues Unterverzeichnis
Dieses erhält den Namen des Targets mit einem angehängten ".wants"

Möchten Sie beispielsweise den SSH-Daemon im Target "multi-user.target" starten lassen, erstellen Sie das Unterverzeichnis "multi-user.target.wants"

In ihm setzen Sie dann wiederum einen symbolischen Link auf die Unit-Datei des Dienstes, im Beispiel also auf /lib/systemd/system/sshd.service

Damit startet dann der SSH-Daemon immer dann, wenn Systemd das Target "multi-user.target" aktiviert

Change a service file

rpm keeps overwriting it in /usr/lib/systemd/system all the time

How to handle this?

The recommended way is to copy the service file from /usr/lib/systemd/system to /etc/systemd/system and edit it there

The latter directory takes precedence over the former, and rpm will never overwrite it

If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again

My service foo.service

as distributed by my operating system vendor is only started when (a connection comes in or some hardware is plugged in)

I want to have it started always on boot, too
What should I do?

Simply place a symlink from that service file in the multi-user.target.wants/ directory (which is where you should symlink everything you want to run in the old runlevel 3, i.e

the normal boot-up without graphical UI

It is pulled in by graphical.target too, so will be started for graphical boot-ups, too):

ln -sf /usr/lib/systemd/system/foobar.service /etc/systemd/system/multi-user.target.wants/foobar.service
systemctl daemon-reload

Services After the Network is up

My service is ordered after network.target but at boot it is still called before the network is up

What's going on?

That's a long story, and that's why we have a wiki page of its own about this: Running Services After the Network is up (http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget)

RT scheduling

Whenever my service tries to acquire RT scheduling for one of its threads this is refused with EPERM even though my service is running with full privileges

This works fine on my non-systemd system!

By default, systemd places all systemd daemons in their own cgroup in the "cpu" hierarchy

Unfortunately, due to a kernel limitation, this has the effect of disallowing RT entirely for the service

See My Service Can't Get Realtime! for a longer discussion and what to do about this