Systemd avancé : timers, path units et troubleshooting des services

Systemd est le système d'init par défaut sur la plupart des distributions Linux modernes. Au-delà des commandes basiques systemctl start/stop, il offre des fonctionnalités puissantes souvent méconnues : timers pour planifier des tâches, path units pour réagir aux changements de fichiers, et outils avancés de diagnostic. Si vous êtes nouveau à systemd, consultez d'abord notre guide sur les bases de systemd et la création de services.

• Systemd Timers : remplacer cron intelligemment
• Path Units : surveiller fichiers et répertoires
• Troubleshooting avancé avec journalctl et systemd-analyze
• Dépendances et ordre de démarrage des services
• Bonnes pratiques et optimisation
• Conclusion

Pourquoi préférer les timers à cron

Les systemd timers offrent plusieurs avantages sur cron :

• Logs centralisés dans le journal systemd
• Gestion des dépendances entre services
• Exécution garantie des tâches manquées (si le serveur était éteint)
• Précision à la seconde (vs minute avec cron)
• Délais aléatoires pour éviter les pics de charge

Pour en savoir plus sur les différences avec cron, consultez notre guide complet sur la planification de tâches.

Créer un timer : exemple pratique

Un timer nécessite deux fichiers : un .service (la tâche) et un .timer (la planification).

1. Le service /etc/systemd/system/backup-db.service :

[Unit]
Description=Sauvegarde quotidienne de la base de données

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh
User=backup

2. Le timer /etc/systemd/system/backup-db.timer :

[Unit]
Description=Planification sauvegarde base de données

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

3. Activation :

systemctl daemon-reload
systemctl enable --now backup-db.timer
systemctl list-timers  # Vérifier la planification

Options de planification

Timers monotoniques (relatifs)

OnBootSec=5min           # 5 min après le boot
OnUnitActiveSec=1h       # 1h après la dernière exécution
OnStartupSec=10min       # 10 min après le démarrage de systemd

Timers calendaires (absolus)

OnCalendar=daily                    # Tous les jours à 00:00
OnCalendar=*-*-* 04:00:00          # Tous les jours à 04:00
OnCalendar=Mon..Fri 09:00          # Lun-Ven à 09:00
OnCalendar=Mon *-*-* 00:00:00      # Tous les lundis
OnCalendar=*:0/15                   # Toutes les 15 minutes

Tester une expression :

systemd-analyze calendar "Mon..Fri *-*-* 10:00"
systemd-analyze calendar weekly

Options avancées

AccuracySec=1s              # Précision (défaut: 1min)
RandomizedDelaySec=5m       # Délai aléatoire (éviter les pics)
Persistent=true             # Rattraper les exécutions manquées

Les path units permettent de déclencher des actions sur des événements filesystem (création, modification, suppression). Pour une alternative basée sur inotify, découvrez comment surveiller des fichiers avec inotify.

Types de surveillance

[Path]
PathExists=/tmp/trigger          # Fichier existe
PathExistsGlob=/tmp/*.pdf        # Au moins un fichier match
PathChanged=/etc/config.conf     # Fichier modifié (fermeture)
PathModified=/var/log/app.log    # Fichier modifié (chaque write)
DirectoryNotEmpty=/var/spool/    # Répertoire non vide

Exemple : alerter sur modification de /etc/passwd

1. Script d'alerte /usr/local/bin/alert-passwd.sh :

#!/bin/bash
logger -t passwd-monitor "ALERTE: /etc/passwd a été modifié"
mail -s "Modification /etc/passwd sur $(hostname)" admin@example.com <<< "Vérification nécessaire"

2. Service /etc/systemd/system/passwd-monitor.service :

[Unit]
Description=Alerte modification passwd

[Service]
Type=oneshot
ExecStart=/usr/local/bin/alert-passwd.sh

3. Path unit /etc/systemd/system/passwd-monitor.path :

[Unit]
Description=Surveillance du fichier passwd

[Path]
PathModified=/etc/passwd
Unit=passwd-monitor.service

[Install]
WantedBy=multi-user.target

4. Activation :

chmod +x /usr/local/bin/alert-passwd.sh
systemctl daemon-reload
systemctl enable --now passwd-monitor.path
systemctl status passwd-monitor.path

Options supplémentaires

MakeDirectory=true              # Créer le répertoire à surveiller
DirectoryMode=0755              # Permissions si création
TriggerLimitBurst=10            # Max 10 activations par intervalle
TriggerLimitIntervalSec=60s     # Intervalle de limitation

Pour une gestion complète des logs système, consultez notre guide sur les logs Linux avec journalctl et découvrez comment monitorer vos systèmes avec des outils avancés.

Analyser les logs avec journalctl

# Logs d'un service spécifique
journalctl -u nginx.service

# Dernières 50 lignes + suivi temps réel
journalctl -u nginx.service -n 50 -f

# Logs depuis un timestamp
journalctl -u nginx.service --since "2025-01-10 14:00"
journalctl --since "1 hour ago"

# Filtrer par priorité (0=emerg, 3=err, 6=info)
journalctl -p err

# Logs kernel uniquement
journalctl -k

# Logs du dernier boot
journalctl -b

# Logs d'un utilisateur spécifique
journalctl _UID=1000

# Format JSON pour parsing
journalctl -u app.service -o json-pretty

Diagnostiquer le démarrage avec systemd-analyze

# Temps total de boot
systemd-analyze

# Services les plus lents
systemd-analyze blame

# Chaîne critique de démarrage
systemd-analyze critical-chain

# Graphique SVG du boot
systemd-analyze plot > boot.svg

# Vérifier la syntaxe d'un unit file
systemd-analyze verify /etc/systemd/system/myapp.service

Pour un guide complet sur l'optimisation du temps de démarrage, consultez notre article spécialisé.

Débugger un service qui échoue

# Status détaillé
systemctl status myapp.service

# Dernières lignes de log
journalctl -u myapp.service -n 100 --no-pager

# Voir la conf effective (après includes/overrides)
systemctl cat myapp.service

# Lister les dépendances
systemctl list-dependencies myapp.service

# Recharger après modification
systemctl daemon-reload
systemctl restart myapp.service

Variables d'environnement et chemins

Vérifier l'environnement d'exécution :

systemctl show-environment
systemctl show myapp.service

Directives de dépendances

[Unit]
# Dépendance forte : si nginx échoue, ce service échoue aussi
Requires=nginx.service

# Dépendance faible : souhaite nginx, mais continue sans
Wants=redis.service

# Conflit : ne peut pas tourner en même temps
Conflicts=another-app.service

# Ordre de démarrage (sans dépendance obligatoire)
Before=webapp.service
After=network.target postgresql.service

Cibles (targets) courantes

# Lister toutes les targets
systemctl list-units --type=target

# Targets principales
multi-user.target     # Équivalent runlevel 3 (multi-utilisateur sans GUI)
graphical.target      # Équivalent runlevel 5 (avec GUI)
network.target        # Réseau disponible
timers.target         # Pour les timers

Exemple de service avec dépendances

[Unit]
Description=Application web
After=network.target postgresql.service redis.service
Wants=redis.service
Requires=postgresql.service

[Service]
Type=simple
ExecStart=/usr/bin/webapp
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Sécurisation des services

[Service]
# Isolation
PrivateTmp=true                 # /tmp isolé
ProtectSystem=strict            # Filesystem en read-only
ProtectHome=true                # /home inaccessible
NoNewPrivileges=true            # Pas d'escalade de privilèges

# Capabilities
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# User/Group
User=appuser
Group=appgroup

Gestion des ressources

[Service]
# Limites CPU
CPUQuota=50%

# Limites mémoire
MemoryHigh=512M
MemoryMax=1G

# Limites I/O
IOWeight=500

Restart policies

[Service]
# Politiques de redémarrage
Restart=on-failure      # Redémarre uniquement si échec
Restart=always          # Redémarre toujours (même si succès)
Restart=on-abnormal     # Redémarre sur signal/timeout

RestartSec=10s          # Délai avant restart
StartLimitBurst=5       # Max 5 redémarrages
StartLimitIntervalSec=300s  # Dans les 5 minutes

Drop-in configs (overrides)

Éviter de modifier les unit files système, utiliser des overrides :

# Créer un override
systemctl edit nginx.service

# Contenu du fichier /etc/systemd/system/nginx.service.d/override.conf
[Service]
Environment="CUSTOM_VAR=value"
RestartSec=30s

Systemd offre bien plus que start et stop. Les timers remplacent avantageusement cron avec une meilleure gestion des logs et dépendances. Les path units automatisent des actions sur événements filesystem. Les outils de troubleshooting comme journalctl et systemd-analyze permettent un diagnostic précis et rapide.

Maîtriser ces fonctionnalités avancées vous rend plus efficace dans l'administration quotidienne et le debug de services Linux en production.