systemd & Service Management

systemd ist der Init-System- und Service-Manager für Ubuntu 26.04, verantwortlich für das Bootstrapping des Systems, die Verwaltung von Diensten und Daemons. Die Beherrschung von systemd ist eine wesentliche Fähigkeit für die Ubuntu-Systemadministration.

systemctl-Grundlagen

Verwalten des Dienststatus


# Start a service
sudo systemctl start nginx
 
# Stop a service
sudo systemctl stop nginx
 
# Restart a service
sudo systemctl restart nginx
 
# Reload configuration (without interrupting the service)
sudo systemctl reload nginx
 
# Reload if supported, otherwise restart
sudo systemctl reload-or-restart nginx
 
# Check service status
systemctl status nginx

Boot-Service-Management


# Enable a service at boot
sudo systemctl enable nginx
 
# Disable a service at boot
sudo systemctl disable nginx
 
# Enable and start immediately
sudo systemctl enable --now nginx
 
# Prevent a service from being started (including manually)
sudo systemctl mask nginx
 
# Remove the mask
sudo systemctl unmask nginx

Serviceinformationen anzeigen


# List all running services
systemctl list-units --type=service --state=running
 
# List all installed services
systemctl list-unit-files --type=service
 
# List failed services
systemctl list-units --failed
 
# View a service's dependencies
systemctl list-dependencies nginx
 
# View detailed service properties
systemctl show nginx
 
# Check if a service is active
systemctl is-active nginx
 
# Check if a service is enabled at boot
systemctl is-enabled nginx

Service-Unit-Dateien

Speicherorte der Einheitendateien

systemd-Service-Unit-Dateien werden in der Reihenfolge ihrer Priorität (von der höchsten zur niedrigsten) an den folgenden Speicherorten gespeichert:

Pfad	Beschreibung
`/etc/systemd/system/`	Benutzerdefinierte Admin-Konfigurationen, höchste Priorität
`/run/systemd/system/`	Zur Laufzeit generierte Unit-Dateien
`/lib/systemd/system/`	Von Paketen installierte Standard-Unit-Dateien

Einheitendateien anzeigen


# View a service's unit file contents
systemctl cat nginx.service
 
# View the unit file path
systemctl show -p FragmentPath nginx.service
 
# Edit a unit file (creates an override)
sudo systemctl edit nginx.service
 
# Edit the full unit file
sudo systemctl edit --full nginx.service

Struktur der Einheitendatei

Eine typische Service-Unit-Datei besteht aus drei Abschnitten:


[Unit]
Description=Service description
Documentation=https://example.com/docs
After=network.target
Wants=network-online.target
Requires=postgresql.service
 
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/myapp
ExecStartPre=/opt/myapp/pre-start.sh
ExecStart=/opt/myapp/start.sh
ExecStop=/opt/myapp/stop.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
Environment=NODE_ENV=production
EnvironmentFile=/opt/myapp/.env
 
[Install]
WantedBy=multi-user.target

Allgemeine Servicetypen

Typ	Beschreibung
`simple`	Standard; Der von ExecStart gestartete Prozess ist der Hauptprozess
`forking`	Der Dienst forkt einen untergeordneten Prozess; Der Startvorgang gilt als abgeschlossen, wenn das übergeordnete Element beendet wird
`oneshot`	Einmalige Aufgabe; als abgeschlossen betrachtet, wenn der Prozess beendet wird
`notify`	Der Dienst benachrichtigt systemd über sd_notify, wenn der Startvorgang abgeschlossen ist
`idle`	Ähnlich wie „einfach“, wartet jedoch vor dem Start auf den Abschluss anderer Aufgaben

Neustartrichtlinien

Option	Beschreibung
`no`	Nicht automatisch neu starten (Standard)
`on-success`	Beim normalen Beenden neu starten
`on-failure`	Bei abnormalem Beenden neu starten
`on-abnormal`	Starten Sie neu, wenn es durch ein Signal oder eine Zeitüberschreitung beendet wird
`on-abort`	Starten Sie neu, wenn Sie durch ein nicht erfasstes Signal getötet werden
`always`	Starten Sie immer neu, unabhängig vom Beendigungsgrund

Erstellen benutzerdefinierter Dienste

Beispiel: Node.js-Anwendungsdienst

Erstellen Sie eine Unit-Datei:


sudo nano /etc/systemd/system/myapp.service

Fügen Sie den folgenden Inhalt hinzu:


[Unit]
Description=My Node.js Application
After=network.target
 
[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node /opt/myapp/server.js
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp
Environment=NODE_ENV=production PORT=3000
 
# Security hardening
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/opt/myapp/data
PrivateTmp=yes
 
[Install]
WantedBy=multi-user.target

Aktivieren und starten Sie den Dienst:


# Reload systemd configuration
sudo systemctl daemon-reload
 
# Start the service
sudo systemctl enable --now myapp.service
 
# Check status
systemctl status myapp.service
 
# View logs
journalctl -u myapp.service -f

Beispiel: Python-Anwendungsdienst


[Unit]
Description=Python Flask Application
After=network.target
 
[Service]
Type=simple
User=flask
Group=flask
WorkingDirectory=/opt/flask-app
ExecStart=/opt/flask-app/venv/bin/gunicorn -w 4 -b 0.0.0.0:8000 app:app
Restart=always
RestartSec=5
Environment=FLASK_ENV=production
 
[Install]
WantedBy=multi-user.target

Beispiel: Dienst mit Watchdog


[Unit]
Description=Critical Service with Watchdog
After=network.target
 
[Service]
Type=notify
ExecStart=/opt/critical/run.sh
WatchdogSec=30
Restart=on-failure
RestartSec=5
 
# Auto-restart on failure, up to 5 attempts
StartLimitIntervalSec=300
StartLimitBurst=5
 
[Install]
WantedBy=multi-user.target

Verwenden von Außerkraftsetzungen zum Ändern vorhandener Dienste

Es wird nicht empfohlen, Dateien in /lib/systemd/system/ direkt zu ändern. Verwenden Sie stattdessen Überschreibungen:


# Create an override file
sudo systemctl edit nginx.service

Dadurch wird ein Editor geöffnet, in dem Sie Konfigurationsüberschreibungen hinzufügen können:


[Service]
# Add memory limit
MemoryMax=512M
 
# Change restart policy
Restart=always
RestartSec=3

Die Überschreibungsdatei wird unter /etc/systemd/system/nginx.service.d/override.conf gespeichert.


# View the merged full configuration
systemctl cat nginx.service
 
# Reload configuration
sudo systemctl daemon-reload
sudo systemctl restart nginx

Systemverwaltungsbefehle


# View boot time
systemd-analyze
 
# View boot time per service (sorted)
systemd-analyze blame
 
# View the boot critical chain
systemd-analyze critical-chain
 
# View the current default target
systemctl get-default
 
# Set the default target
sudo systemctl set-default multi-user.target   # Command-line mode
sudo systemctl set-default graphical.target     # Graphical mode
 
# Shutdown and reboot
sudo systemctl poweroff
sudo systemctl reboot
 
# Suspend and hibernate
sudo systemctl suspend
sudo systemctl hibernate

Ressourcengrenzen

Sie können Ressourcenlimits in Service-Unit-Dateien festlegen:


[Service]
# CPU limit
CPUQuota=50%
 
# Memory limit
MemoryMax=1G
MemoryHigh=800M
 
# I/O limit
IOWeight=100
IOReadBandwidthMax=/dev/sda 10M
 
# Process count limit
TasksMax=100
 
# File descriptor limit
LimitNOFILE=65535

Fehlerbehebung


# View the reason a service failed
systemctl status myapp.service
journalctl -u myapp.service --no-pager -n 50
 
# Validate unit file syntax
systemd-analyze verify /etc/systemd/system/myapp.service
 
# View systemd's own logs
journalctl -b _PID=1
 
# Reset the failure count
sudo systemctl reset-failed myapp.service