System verstehen und verwalten

Christopher Engelhard, Kamil Páral, Caleb McKee Version unknown Last review: 2020-08-05

Learn the basic principles of the systemd init system: how to configure it and use it to administer the system.

systemd verstehen

Systemd ist ein System- und Dienstmanager für Linux, der zu SysV- und LSB-Init-Skripten kompatibel ist. Systemd bietet:

Aggressive parallelization capabilities
Uses socket and D-Bus activation for starting services
Offers on-demand starting of daemons, keeps track of processes using Linux cgroups
Supports snapshotting and restoring of the system state
Maintains mount and automount points
Implementiert eine ausgefeilte, transaktionsbasierte Abhängigkeitslogik zur Steuerung von Diensten.

The systemctl command is the primary tool to manage systemd. It combines the functionality of SysVinit’s service and chkconfig commands into a single tool you can use to enable and disable services permanently or only for the current session.

Systemd manages so-called units, which are representations of system resources and services. This following list shows the unit types that systemd can manage:

service: A service on the system, including instructions for starting, restarting, and stopping the service.
socket: A network socket associated with a service.
device: A device specifically managed with systemd.
mount: A mountpoint managed with systemd.
automount: A mountpoint automatically mounted on boot.
swap: Swap space on the system.
target: A synchronization point for other units. Usually used to start enabled services on boot.
path: A path for path-based activation. For example, you can start services based on the state of a certain path, such as whether it exists or not.
timer: A timer to schedule activation of another unit.
snapshot: A snapshot of the current systemd state. Usually used to rollback after making temporary changes to systemd.
slice: Restriction of resources through Linux Control Group nodes (cgroups).
scope: Information from systemd bus interfaces. Usually used to manage external system processes.

Starten, Stoppen und Abfragen von systemd-Diensten

Mit dem Befehl systemctl können Sie verschiedene Verwaltungsaufgaben zur Steuerung von systemd-Diensten durchführen. Im Folgenden finden Sie einige Beispielbefehle, die die Verwendung von systemctl zur Verwaltung von systemd-Diensten veranschaulichen.

Voraussetzungen

You are logged in as a user with administrator-level permissions.

Vorgehensweise

Die folgenden Befehle steuern den Dienst foo:

Einen Dienst sofort aktivieren:
```
# systemctl start foo
```
Einen Dienst sofort beenden:
```
# systemctl stop foo
```
Einen Dienst neu starten:
```
# systemctl restart foo
```
Den Status eines Dienstes anzeigen, einschließlich der Information, ob er ausgeführt wird oder nicht:
```
# systemctl status foo
```
Aktivieren, dass ein Dienst beim Systemstart gestartet wird:
```
# systemctl enable foo
```
Einen Dienst deaktivieren, so dass er beim Systemstart nicht gestartet wird:
```
# systemctl disable foo
```
Verhindern, dass ein Dienst dynamisch oder auch manuell gestartet wird, sofern er nicht demaskiert ist:
```
# systemctl mask foo
```
Prüfen, ob ein Dienst aktiviert ist oder nicht:
```
# systemctl is-enabled foo
```

Modifizierung bestehender systemd-Dienste

Dieses Beispiel zeigt, wie ein bestehender Dienst modifiziert wird. Dienständerungen werden in /etc/systemd/system gespeichert, entweder in einer einzelnen Datei oder in einem nach dem Dienst benannten Unterverzeichnis. Beispielsweise modifiziert diese Vorgehensweise den Dienst httpd.

Voraussetzungen

You are logged in as a user with administrator-level permissions.
Sie haben einen konfigurierten httpd-Server, der über systemd läuft.

Vorgehensweise

Die Systemd-Dienste können mit dem Befehl systemctl edit geändert werden.
```
# systemctl edit httpd.service
```
Dadurch wird eine Außerkraftsetzungsdatei /etc/systemd/system/httpd.service.d/override.conf erstellt und in Ihrem Texteditor geöffnet. Alles, was Sie in diese Datei einfügen, wird der bestehenden Dienstkonfigurationsdatei hinzugefügt.
Fügen Sie Ihre benutzerdefinierte Konfiguration hinzu. Zum Beispiel:
```
[Service]
Restart=always
RestartSec=30
```
Um eine Option zu ersetzen, die mehrfach gesetzt werden kann, muss sie zuerst gelöscht werden, da die Außerkraftsetzungsdatei die Option sonst ein zweites Mal hinzufügt.
```
[Service]
ExecStart=
ExecStart=<neuer Befehl>
```
Speichern Sie die Datei. Systemd lädt die neue Dienstkonfiguration automatisch.
Starten Sie den httpd-Dienst neu:
```
# systemctl restart httpd
```

Um eine bestehende Dienstdatei vollständig zu ersetzen (anstatt sie nur zu ergänzen oder zu ändern), verwenden Sie systemctl edit --full, z. B. systemctl edit --full httpd.service. Dadurch wird die Datei /etc/systemctl/system/httpd.service erstellt, die anstelle der bestehenden Dienstdatei verwendet wird.

Erstellen neuer systemd-Dienste

Dieses Beispiel zeigt, wie eine Unit-Datei für einen benutzerdefinierten Dienst erstellt wird. Benutzerdefinierte Unit-Dateien befinden sich im Verzeichnis /etc/systemd/system/ und haben die Dateiendung .service. Beispielsweise verwendet ein benutzerdefinierter Dienst foo die Unit-Datei /etc/systemd/system/foo.service.

Voraussetzungen

You are logged in as a user with administrator-level permissions.

Vorgehensweise

Dieses Verfahren erstellt eine Basiskonfigurationsdatei zur Steuerung des Dienstes foo.

Erstellen und bearbeiten Sie die neue Konfigurationsdatei:
```
# nano /etc/systemd/system/foo.service
```
Die folgenden Schritte beschreiben jeden Abschnitt und dessen Parameter, die zur Datei hinzugefügt werden müssen:
1. Der Abschnitt [Unit] enthält grundlegende Informationen zum Dienst. Der Dienst foo verwendet die folgenden Parameter:
  Description
  
  Eine Zeichenkette, die die Unit beschreibt. Systemd zeigt diese Beschreibung neben dem Unit-Namen in der Benutzerschnittstelle an.
  
  After
  
  Definiert eine Beziehung zu einer zweiten Unit. Wenn Sie die Unit aktivieren, aktiviert systemd sie erst nach der zweiten. Beispielsweise benötigt der Dienst foo möglicherweise eine Netzwerkverbindung, was bedeutet, dass der Dienst foo network.target als After=-Bedingung angibt.
  
  Der resultierende Abschnitt [Unit] sieht folgendermaßen aus:
  
  [Unit] Description=Mein benutzerdefinierter Dienst After=network.target
2. Der Abschnitt [Service] enthält Anweisungen zur Steuerung des Dienstes. Der Dienst foo verwendet die folgenden Parameter:
  Type
  
  Definiert den Typ des systemd-Dienstes. In diesem Beispiel ist der foo-Dienst ein simple-Dienst, der ohne besondere Berücksichtigung gestartet wird.
  
  ExecStart
  
  Der Befehl, der zum Starten des Dienstes ausgeführt werden soll. Dieser enthält den vollständigen Pfad zum Befehl und Argumente zur Anpassung des Dienstes.
  
  Der resultierende Abschnitt [Service] sieht folgendermaßen aus:
  
  [Service] Type=simple ExecStart=/usr/bin/sleep infinity
3. Der Abschnitt [Install] enthält Anweisungen zur Installation des Dienstes durch systemd. Der Dienst foo verwendet die folgenden Parameter:
  
  WantedBy
  
  Definiert, welcher Dienst den benutzerdefinierten Dienst auslöst, wenn dieser mit systemctl enable aktiviert wird. Dies wird hauptsächlich verwendet, um den benutzerdefinierten Dienst beim Systemstart zu starten. In diesem Beispiel verwendet foo.service das Ziel multi-user.target, welches foo.service startet, sobald systemd beim Systemstart multi-user.target lädt.

Die vollständige Datei foo.service hat folgenden Inhalt:

[Unit]
Description=Mein benutzerdefinierter Dienst
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/sleep infinity

[Install]
WantedBy=multi-user.target

Speichern Sie die Datei.

Um systemd über den neuen Dienst zu informieren, laden Sie dessen Dienstdateien neu:
```
# systemctl daemon-reload
```
Starten Sie den benutzerdefinierten foo-Dienst:
```
# systemctl start foo
```

Überprüfen Sie den Status des Dienstes, um sicherzustellen, dass der Dienst ausgeführt wird:

$ systemctl status foo
● foo.service - My custom service
   Loaded: loaded (/etc/systemd/system/foo.service; static; vendor preset: disabled)
   Active: active (running) since Thu 2017-12-14 14:09:12 AEST; 6s ago
 Main PID: 31837 (sleep)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/foo.service
           └─31837 /usr/bin/sleep infinity

Dec 14 14:09:12 dansmachine systemd[1]: Started Mein benutzerdefinierter Dienst.

Umstellung der SysVinit-Dienste auf systemd

Ältere Fedora-Versionen verwenden SysVinit-Skripte zur Verwaltung von Diensten. Dieser Abschnitt enthält einige Richtlinien zur Konvertierung eines SysVinit-Skripts in ein entsprechendes systemd-Skript.

Voraussetzungen

You are logged in as a user with administrator-level permissions.
Sie haben ein benutzerdefiniertes SysVinit-Skript, das in eine systemd-Konfiguration konvertiert werden soll.

Vorgehensweise

Ermitteln Sie die Runlevel in Ihrem SysVinit-Skript. Diese werden üblicherweise mit der chkconfig-Direktive im auskommentierten Abschnitt am Anfang des Skripts definiert. Beispielsweise zeigt Folgendes an, dass der Dienst die Runlevel 3, 4 und 5 verwendet:
```
# chkconfig: 235 20 80
```
Systemd verwendet Ziele anstelle von Runleveln. Verwenden Sie die Tabelle in [converting-sysvinit-services], um die Runlevel den Zielen zuzuordnen. In diesem Beispiel sind die Runlevel 2, 3 und 5 allesamt Mehrbenutzer-Runlevel, daher kann der systemd-Dienst Folgendes verwenden:
```
[Install]
WantedBy=multi-user.target
```
Wenn Sie den benutzerdefinierten systemd-Dienst so aktivieren, dass er beim Systemstart gestartet wird (systemctl enable foo.service), lädt systemd den Dienst beim Laden des multi-user.target beim Systemstart.
Identifizieren Sie die abhängigen Dienste und Ziele. Wenn der benutzerdefinierte Dienst beispielsweise eine Netzwerkverbindung benötigt, geben Sie network.target als Abhängigkeit an:
```
[Unit]
Description=Mein benutzerdefinierter Dienst
After=network.target
```
Identifizieren Sie den Befehl, mit dem der Dienst im SysVinit-Skript gestartet wird, und wandeln Sie diesen in das entsprechende systemd-Befehlsformat um. Das Skript könnte beispielsweise eine start-Funktion im folgenden Format enthalten:
```
start() {
  echo "Starting Mein benutzerdefinierter Dienst..."
  /usr/bin/myservice -D
}
```
In diesem Beispiel ist der Befehl /usr/bin/myservice der benutzerdefinierte Dienstbefehl, der mit der Option -D als Daemon ausgeführt wird. Setzen Sie den Parameter ExecStart, um diesen Befehl zu verwenden:
```
[Service]
ExecStart=/usr/bin/myservice -D
```
Überprüfen Sie das SysVinit-Skript, um festzustellen, ob der Dienst einen speziellen Befehl zum Neustart verwendet. Beispielsweise könnte das Skript eine reboot-Funktion enthalten, die den Dienst neu lädt:
```
reboot() {
  echo "Reloading Mein benutzerdefinierter Dienst..."
  /usr/bin/myservice reload
}
```
In diesem Beispiel ist der Befehl /usr/bin/myservice der benutzerdefinierte Dienstbefehl und lädt den Dienst mithilfe des Unterbefehls reload neu. Setzen Sie den Parameter ExecReload, um diesen Befehl zu verwenden:
```
[Service]
ExecReload=/usr/bin/myservice reload
```
Alternativ können Sie ExecReload weglassen und das Standardverhalten verwenden, das den Dienst beendet und neu startet.
Überprüfen Sie das SysVinit-Skript, um festzustellen, ob der Dienst einen speziellen Befehl zum Beenden verwendet. Beispielsweise könnte das Skript eine stop-Funktion enthalten, die den Dienst neu lädt:
```
reboot() {
  echo "Stopping Mein benutzerdefinierter Dienst..."
  /usr/bin/myservice shutdown
}
```
In diesem Beispiel ist der Befehl /usr/bin/myservice der benutzerdefinierte Dienstbefehl. Der Dienst wird mithilfe des Unterbefehls shutdown ordnungsgemäß beendet. Setzen Sie den Parameter ExecStop, um diesen Befehl zu verwenden:
```
[Service]
ExecStop=/usr/bin/myservice shutdown
```
Alternativ können Sie ExecStop weglassen und das Standardverhalten verwenden, das den Dienst beendet.
Überprüfen Sie das SysVinit-Skript und identifizieren Sie alle zusätzlichen Parameter oder Funktionen. Verwenden Sie systemd-Parameter, um alle identifizierten SysVinit-Funktionen nachzubilden, die für Ihren Dienst relevant sein könnten.

Allgemeine Dienstparameter

Unit-Parameter

Dieser Abschnitt enthält Parameter, die Sie im Abschnitt [Unit] eines Dienstes verwenden können. Diese Parameter gelten auch für andere systemd-Units.

Diese Liste ist eine Kurzfassung. Eine vollständige Liste dieser Parameter und ihrer Beschreibungen erhalten Sie mit dem Befehl man systemd.unit.

Description: Eine frei formulierte Zeichenkette, die den Dienst beschreibt.
Documentation: Eine durch Leerzeichen getrennte Liste von URIs, die auf die Dokumentation dieses Dienstes oder seiner Konfiguration verweisen. Zulässig sind nur URIs der folgenden Typen: http://, https://, file:, info:, man:.
Requires: Konfiguriert die Abhängigkeiten von anderen Diensten. Wird dieser Dienst aktiviert, werden auch die hier aufgeführten Units aktiviert. Schlägt die Aktivierung eines der abhängigen Dienste fehl, startet systemd diesen Dienst nicht. Diese Option kann mehrfach angegeben werden, oder Sie können mehrere, durch Leerzeichen getrennte Units angeben.
Wants: Ähnlich wie bei Requires, nur dass fehlgeschlagene Units keine Auswirkungen auf den Dienst haben.
BindsTo: Ähnlich wie bei Requires, nur dass beim Stoppen der abhängigen Units auch der Dienst gestoppt wird.
PartOf: Ähnlich wie bei Requires, nur dass beim Stoppen und Neustarten abhängiger Units auch der Dienst gestoppt und neu gestartet wird.
Conflicts: Eine durch Leerzeichen getrennte Liste von Unit-Namen, die, falls sie ausgeführt werden, dazu führen, dass der Dienst nicht ausgeführt wird.
Before, After: Eine durch Leerzeichen getrennte Liste von Unit-Namen, die die Reihenfolge der Abhängigkeiten zwischen Diensten konfiguriert.
OnFailure: Eine durch Leerzeichen getrennte Liste von Unit-Namen, die aktiviert werden, wenn dieser Dienst in einen Fehlerzustand gerät.

Parameter für die Installation

Dieser Abschnitt enthält Parameter, die Sie im Abschnitt [Install] eines Dienstes verwenden können. Diese Parameter gelten auch für andere systemd-Units.

Diese Liste ist eine Kurzfassung. Eine vollständige Liste dieser Parameter und ihrer Beschreibungen erhalten Sie mit dem Befehl man systemd.unit.

Alias: Eine durch Leerzeichen getrennte Liste zusätzlicher Namen, unter denen dieser Dienst installiert werden soll. Die hier aufgeführten Namen müssen dieselbe Endung (d. h. denselben Typ) wie der Dateiname des Dienstes aufweisen.
RequiredBy, WantedBy: Definiert den Dienst als abhängig von einem anderen Dienst. Dies definiert üblicherweise das Ziel, das den Start eines aktivierten Dienstes auslöst. Diese Optionen sind analog zu den Optionen Requires und Wants im Abschnitt [Units].
Also: Zusätzliche Units, die bei der Installation oder Deinstallation dieses Dienstes installiert oder deinstalliert werden sollen.

Parameter für Dienste

Dieser Abschnitt enthält Parameter, die Sie im Abschnitt [Service] einer Dienste-Unit verwenden können. Diese Parameter sind spezifisch für systemd-Dienste-Units.

Diese Liste ist eine Kurzfassung. Eine vollständige Liste dieser Parameter und ihrer Beschreibungen erhalten Sie mit dem Befehl man systemd.unit.

Type

Konfiguriert den Starttyp des Prozesses für diesen Dienst:

simple – Der Dienst startet als Hauptprozess. Dies ist die Standardeinstellung.
forking - Der Dienst ruft geforkte Prozesse auf und wird als Teil des Hauptdaemons ausgeführt.
oneshot - Ähnlich wie simple, nur dass der Prozess beendet werden muss, bevor systemd Folgedienste startet.
dbus - Ähnlich wie simple, nur dass der Daemon den Namen des D-Bus-Busses annimmt.
notify - Ähnlich wie simple, nur dass der Daemon nach dem Start eine Benachrichtigungsmeldung mit sd_notify oder einem entsprechenden Aufruf sendet.
idle - Ähnlich wie simple, nur dass die Ausführung des Dienstes verzögert wird, bis alle aktiven Aufträge abgearbeitet sind.

RemainAfterExit

Ein boolescher Wert, der angibt, ob der Dienst auch dann noch als aktiv gelten soll, wenn alle seine Prozesse beendet wurden. Standardwert: no.

GuessMainPID

A boolean value that specifies whether systemd should guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile is not set. Defaults to yes.

PIDFile

An absolute filename pointing to the PID file of this daemon. Use of this option is recommended for services where Type=forking. Systemd reads the PID of the main process of the daemon after start-up of the service. Systemd does not write to the file configured here, although it removes the file after the service has shut down.

BusName

A D-Bus bus name to reach this service. This option is mandatory for services where Type=dbus.

ExecStart

Die Befehle und Argumente, die beim Start des Dienstes ausgeführt werden.

ExecStartPre, ExecStartPost

Additional commands that are executed before or after the command in ExecStart.

ExecReload

The commands and arguments to execute when the service reloads.

ExecStop

The commands and arguments to execute when the service stops.

ExecStopPost

Additional commands to execute after the service stops.

RestartSec

The time in seconds to sleep before restarting a service.

TimeoutStartSec

The time in seconds to wait for the service to start.

TimeoutStopSec

The time in seconds to wait for the service to stop.

TimeoutSec

A shorthand for configuring both TimeoutStartSec and TimeoutStopSec simultaneously.

RuntimeMaxSec

A maximum time in seconds for the service to run. Pass infinity (the default) to configure no runtime limit.

Restart

Configures whether to restart the service when the service’s process exits, is killed, or reaches a timeout:

no – Der Dienst wird nicht neu gestartet. Dies ist die Standardeinstellung.
on-success - Neustart nur dann, wenn der Dienstprozess ordnungsgemäß beendet wird (Exit-Code 0).
on-failure - Restart only when the service process does not exit cleanly (node-zero exit code).
on-abnormal - Restart if the process terminates with a signal or when a timeout occurs.
on-abort - Neustart, falls der Prozess aufgrund eines nicht abgefangenen Signals beendet wird, das nicht als sauberer Exit-Status angegeben ist.
always - Immer neu starten.

Mapping runlevels to targets

Systemd-Ziele erfüllen einen ähnlichen Zweck wie SysVinit-Runlevel, verhalten sich aber etwas anders. Jedes Ziel hat einen Namen anstelle einer Nummer und dient einem spezifischen Zweck. Systemd implementiert einige Ziele, indem es alle Dienste eines anderen Ziels erbt und zusätzliche Dienste hinzufügt. Manche Systemd-Ziele ahmen die gängigen SysVinit-Runlevel nach, sodass Sie mit dem bekannten Befehl telinit RUNLEVEL zwischen den Zielen wechseln können. Die Runlevel, denen bei Standardinstallationen von Fedora ein bestimmter Zweck zugewiesen ist (0, 1, 3, 5 und 6), entsprechen jeweils einem spezifischen Systemd-Ziel.

However, this is not the case for user-defined runlevels 2 and 4. To make use of those runlevels, create a new named systemd target such as /etc/systemd/system/$YOURTARGET that takes one of the existing runlevels as a base, make a directory /etc/systemd/system/$YOURTARGET.wants, and then symlink the additional services to enable into that directory.

The following is a mapping of SysVinit runlevels to systemd targets.

Tabelle 1. Runlevel to target mapping
Sysvinit Runlevel	systemd Target	Notes
0	runlevel0.target, poweroff.target	Halt the system.
1, s, single	runlevel1.target, rescue.target	Single user mode.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	User-defined/Site-specific runlevels. By default, identical to 3.
3	runlevel3.target, multi-user.target	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5	runlevel5.target, graphical.target	Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
6	runlevel6.target, reboot.target	Reboot
emergency	emergency.target	Emergency shell

Mapping service commands

Die folgende Tabelle zeigt die systemd-Entsprechungen der SysVinit-Befehle.

All recent versions of systemctl assume the .service suffix if left off the service name. For example, systemctl start frobozz.service is the same as systemctl start frobozz.

Sysvinit Command systemd Command Notes

Sysvinit Command	systemd Command	Notes
`service frobozz start`	`systemctl start frobozz`	Used to start a service (not reboot persistent)
`service frobozz stop`	`systemctl stop frobozz`	Used to stop a service (not reboot persistent)
`service frobozz restart`	`systemctl restart frobozz`	Used to stop and then start a service
`service frobozz reload`	`systemctl reload frobozz`	When supported, reloads the config file without interrupting pending operations.
`service frobozz condrestart`	`systemctl condrestart frobozz`	Restarts if the service is already running.
`service frobozz status`	`systemctl status frobozz`	Tells whether a service is currently running.
`ls /etc/rc.d/init.d/`	`systemctl` or `systemctl list-unit-files --type=service` or `ls /lib/systemd/system/.service /etc/systemd/system/.service`	Used to list the services that can be started or stopped Used to list all the services and other units
`chkconfig frobozz on`	`systemctl enable frobozz`	Turn the service on, for start at next boot, or other trigger.
`chkconfig frobozz off`	`systemctl disable frobozz`	Turn the service off for the next reboot, or any other trigger.
`chkconfig frobozz`	`systemctl is-enabled frobozz`	Used to check whether a service is configured to start or not in the current environment.
`chkconfig --list`	`systemctl list-unit-files --type=service` or `ls /etc/systemd/system/*.wants/`	Print a table of services that lists which runlevels each is configured on or off
`chkconfig --list \| grep 5:on`	`systemctl list-dependencies graphical.target`	Print a table of services that will be started when booting into graphical mode
`chkconfig frobozz --list`	`ls /etc/systemd/system/*.wants/frobozz.service`	Used to list what levels this service is configured on or off
`chkconfig frobozz --add`	`systemctl daemon-reload`	Used when you create a new service file or modify any configuration

service frobozz start

systemctl start frobozz

Used to start a service (not reboot persistent)

service frobozz stop

systemctl stop frobozz

Used to stop a service (not reboot persistent)

service frobozz restart

systemctl restart frobozz

Used to stop and then start a service

service frobozz reload

systemctl reload frobozz

When supported, reloads the config file without interrupting pending operations.

service frobozz condrestart

systemctl condrestart frobozz

Restarts if the service is already running.

service frobozz status

systemctl status frobozz

Tells whether a service is currently running.

ls /etc/rc.d/init.d/

systemctl or systemctl list-unit-files --type=service or
ls /lib/systemd/system/*.service /etc/systemd/system/*.service

Used to list the services that can be started or stopped
Used to list all the services and other units

chkconfig frobozz on

systemctl enable frobozz

Turn the service on, for start at next boot, or other trigger.

chkconfig frobozz off

systemctl disable frobozz

Turn the service off for the next reboot, or any other trigger.

chkconfig frobozz

systemctl is-enabled frobozz

Used to check whether a service is configured to start or not in the current environment.

chkconfig --list

systemctl list-unit-files --type=service or ls /etc/systemd/system/*.wants/

Print a table of services that lists which runlevels each is configured on or off

chkconfig --list | grep 5:on

systemctl list-dependencies graphical.target

Print a table of services that will be started when booting into graphical mode

chkconfig frobozz --list

ls /etc/systemd/system/*.wants/frobozz.service

Used to list what levels this service is configured on or off

chkconfig frobozz --add

systemctl daemon-reload

Used when you create a new service file or modify any configuration

All /sbin/service and /sbin/chkconfig commands listed in the table continue to work on systemd-based systems and are translated to native equivalents as necessary. The only exception is chkconfig --list.

Weitere Ressourcen

Project homepage
Lennart Poettering’s blog with lots of information about systemd. Lennart is the primary systemd developer
freedesktop.org’s systemd FAQ
freedesktop.org’s systemd Tips & Tricks
Interview mit dem Entwickler

Want to help? Learn how to contribute to Fedora Docs ›

System verstehen und verwalten

systemd verstehen

Starten, Stoppen und Abfragen von systemd-Diensten

Voraussetzungen

Vorgehensweise

Verwandte Informationen

Modifizierung bestehender systemd-Dienste

Voraussetzungen

Vorgehensweise

Verwandte Informationen

Erstellen neuer systemd-Dienste

Voraussetzungen

Vorgehensweise

Verwandte Informationen

Umstellung der SysVinit-Dienste auf systemd

Voraussetzungen

Vorgehensweise

Verwandte Informationen

Allgemeine Dienstparameter

Unit-Parameter

Parameter für die Installation

Parameter für Dienste

Mapping runlevels to targets

Mapping service commands

Weitere Ressourcen