systemd et gestion des services

Différences de version 26.10

26.10 utilise systemd 261.3 et supprime systemd-sysv-generator. Les scripts /etc/init.d personnalisés ne peuvent plus s’appuyer sur les services générés. Migrez vers les unités natives systemd et testez l’activation du démarrage, de l’arrêt, du redémarrage et du démarrage. Notes de version officielles

systemd est le système d’initialisation et le gestionnaire de services pour Ubuntu 26.04, responsable du démarrage du système, de la gestion des services et des démons. La maîtrise de systemd est une compétence essentielle pour l’administration du système Ubuntu.

Les bases de systemctl

Gestion de l’état du service


# 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

Gestion des services de démarrage


# 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

Affichage des informations sur les services


# 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

Fichiers d’unité de service

Emplacements des fichiers d’unité

Les fichiers d’unité de service systemd sont stockés aux emplacements suivants, par ordre de priorité (du plus élevé au plus bas) :

Chemin	Description
`/etc/systemd/system/`	Configurations d’administrateur personnalisées, priorité la plus élevée
`/run/systemd/system/`	Fichiers unitaires générés par l’exécution
`/lib/systemd/system/`	Fichiers d’unité par défaut installés par les packages

Affichage des fichiers d’unité


# 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

Structure du fichier d’unité

Un fichier d’unité de service typique comporte trois sections :


[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

Types de services courants

Taper	Description
`simple`	Défaut; le processus démarré par ExecStart est le processus principal
`forking`	Le service crée un processus enfant ; le démarrage est considéré comme terminé lorsque le parent quitte
`oneshot`	Tâche ponctuelle ; considéré comme terminé lorsque le processus se termine
`notify`	Le service informe systemd via sd_notify lorsque le démarrage est terminé
`idle`	Similaire à simple, mais attend que les autres tâches soient terminées avant de commencer

Politiques de redémarrage

Option	Description
`no`	Ne pas redémarrer automatiquement (par défaut)
`on-success`	Redémarrer en sortie normale
`on-failure`	Redémarrer sur sortie anormale
`on-abnormal`	Redémarrer lorsqu’il est tué par un signal ou un délai d’attente
`on-abort`	Redémarrez lorsque vous êtes tué par un signal non capté
`always`	Redémarrez toujours quelle que soit la raison de la sortie

Création de services personnalisés

Exemple : Service d’application Node.js

Créez un fichier unité :


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

Ajoutez le contenu suivant :


[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

Activez et démarrez le service :


# 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

Exemple : Service d’application Python


[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

Exemple : Service avec 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

Utilisation de remplacements pour modifier des services existants

Il n’est pas recommandé de modifier directement les fichiers dans /lib/systemd/system/. Utilisez plutôt les remplacements :


# Create an override file
sudo systemctl edit nginx.service

Cela ouvre un éditeur dans lequel vous pouvez ajouter des remplacements de configuration :


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

Le fichier de remplacement est enregistré sous /etc/systemd/system/nginx.service.d/override.conf.


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

Commandes de gestion du système


# 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

Limites des ressources

Vous pouvez définir des limites de ressources dans les fichiers d’unités de service :


[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

Dépannage


# 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