systemctl ist das Befehlszeilen-Tool zur System- und Dienstverwaltung von systemd. Auf fast allen modernen Linux-Distributionen (AlmaLinux, Rocky Linux, CloudLinux, Ubuntu, Debian) können damit im Hintergrund laufende Dienste wie beispielsweise der Webserver, die Datenbank oder der SSH-Server gestartet, gestoppt und überwacht werden. Für die Verwaltung der Dienste sind root- oder sudo-Rechte erforderlich; daher richtet sich dieser Artikel an Betreiber eigener VPS- oder dedizierter Server.

Starten, Beenden, Neustarten

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

Ein „restart“ stoppt den Dienst und startet ihn neu, was zu einer kurzen Unterbrechung führt. Ein „reload“ lädt lediglich die Einstellungen neu, ohne den Dienst zu unterbrechen; dies wird jedoch nicht von allen Diensten unterstützt. In solchen Fällen ist „systemctl reload-or-restart“ die sichere Wahl. Vor einer Konfigurationsänderung empfiehlt es sich, die Einstellungen mit dem jeweiligen Testbefehl des Dienstes zu überprüfen (z. B. „nginx -t“, „apachectl configtest“ oder „sshd -t“), da der Dienst bei einer fehlerhaften Konfigurationsdatei nicht neu gestartet werden kann.

Die Endung „.service“ muss nicht angegeben werden; die Befehle „systemctl restart nginx“ und „systemctl restart nginx.service“ haben dieselbe Bedeutung.

Status prüfen

systemctl status nginx
systemctl is-active nginx
systemctl --failed

Der status zeigt an, ob der Dienst läuft (active (running)), seit wann, mit welcher Prozess-ID (PID) sowie die letzten Protokolleinträge. Der Befehl „is-active“ gibt ein einziges Wort als Antwort zurück und ist daher in Skripten nützlich. Der Befehl „systemctl --failed“ listet alle Dienste auf, die sich im Fehlerzustand befinden.

Automatischer Start beim Systemstart

sudo systemctl enable nginx
sudo systemctl enable --now nginx
sudo systemctl disable nginx
systemctl is-enabled nginx

Der Befehl „enable“ sorgt dafür, dass der Dienst nach einem Neustart des Servers automatisch gestartet wird, startet den Dienst jedoch nicht selbst. Der Befehl „enable --now“ aktiviert und startet den Dienst in einem Schritt. Der Befehl „disable“ deaktiviert den automatischen Start. Mit dem Befehl „mask“ kann ein Dienst vollständig gesperrt werden, sodass er auch manuell nicht gestartet werden kann, bis die Sperre mit „unmask“ aufgehoben wird. Bei einem Test ergab der Versuch, einen gesperrten Dienst zu starten, folgende Meldung: „Failed to start crond.service: Unit crond.service is masked.“

Häufige Dienstnamen

Die Bezeichnungen der Dienste können je nach Distribution variieren:

Dienstleistung	AlmaLinux, Rocky Linux	Debian, Ubuntu
Apache-Webserver	httpd	apache2
MariaDB-Datenbank	mariadb	mariadb
SSH-Server	sshd	ssh
Geplante Aufgaben	crond	cron
Firewall	firewalld	ufw

Auf den Testrechnern (AlmaLinux 10.2, Ubuntu 24.04, Debian 12 Cloud-Image) gibt es einige Abweichungen:

• Unter Debian funktioniert auch der Name „sshd“, da dies ein ssh.service des Dienstes „alias“ ist.
• Unter Ubuntu 24.04 wird SSH über die Socket-Aktivierung gestartet: Der Dienst „ssh.service“ befindet sich im Status „disabled“, der Dienst „ssh.socket“ überwacht Port 22 und startet den Dienst bei der ersten Verbindung. Dies ist bei einer Änderung des SSH-Ports von Bedeutung (siehe: Sicherheitseinstellungen des SSH-Servers).
• Auf Ubuntu ist ufw installiert, jedoch standardmäßig nicht aktiviert; auf dem Debian-Cloud-Image sind weder ufw noch firewalld vorhanden, und auch cron ist nicht installiert (sudo apt install cron).

Eine Liste aller geladenen Dienste erhalten Sie mit dem Befehl „systemctl list-units --type=service“. Weitere Informationen zu SSH finden Sie in unserem Artikel „Linux Secure Shell (SSH)“.

Was können Sie tun, wenn ein Dienst nicht startet?

1. Sehen Sie sich die Ausgabe von „systemctl status szolgaltatas“ an: Oftmals wird die Fehlermeldung bereits hier angezeigt.
2. Rufen Sie das gesamte Protokoll des Dienstes ab: journalctl -u szolgaltatas -n 50 --no-pager. Informationen zum Lesen der Protokolle finden Sie in unserem Artikel, in dem wir journalctl und das Verzeichnis /var/log vorstellen.
3. Häufige Ursachen: Syntaxfehler in der Konfigurationsdatei, ein bereits von einem anderen Programm belegter Port (der Befehl „ss -tlnp“ zeigt an, was auf dem jeweiligen Port läuft), erschöpfter Speicherplatz oder fehlerhafte Dateiberechtigungen.
4. Wenn Sie eine Unit-Datei (/etc/systemd/system/*.service) geändert haben, führen Sie den Befehl „sudo systemctl daemon-reload“ aus, da systemd andernfalls weiterhin die alte Konfiguration verwendet.