systemd & Service-Management

26.10 Versionsunterschiede

26.10 verwendet systemd 261.3 und entfernt systemd-sysv-generator. Benutzerdefinierte /etc/init.d-Skripte können sich nicht mehr auf generierte Dienste verlassen. Migrieren Sie auf native systemd-Einheiten und testen Sie die Start-, Stopp-, Neustart- und Boot-Aktivierung. Offizielle Versionshinweise

systemd ist der Init-System- und Dienstmanager 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 Systemadministration von Ubuntu.

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:

Weg	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 empfangenes 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