Leçon 59 : systemctl daemon-reload, mask et liens symboliques

Quand tu modifies un fichier unit systemd ou que tu installes un service, systemd ne le sait pas toujours tout seul. Cette leçon couvre les commandes essentielles pour recharger la configuration, protéger des services, et organiser tes unit files avec des liens symboliques.

Recharger la configuration systemd

Pourquoi daemon-reload ?

Systemd lit sa configuration au démarrage. Si tu modifies un fichier unit ou si tu installes un nouveau service, systemd ne le remarque pas automatiquement. La commande daemon-reload recharger la configuration complète.

Syntaxe

sudo systemctl daemon-reload

Cas d'utilisation

Tu as modifié un fichier unit dans /etc/systemd/system/
Tu as installé un nouveau service (ex: Nginx, MariaDB)
Tu as supprimé un fichier unit manuellement
Tu as ajouté un drop-in snippet

Exemple concret

# 1. Tu modifies le fichier unit
sudo nano /etc/systemd/system/mon-service.service

# 2. systemd ne le sait pas encore, tu recharges
sudo systemctl daemon-reload

# 3. Puis tu redémarres le service
sudo systemctl restart mon-service

Quand est-ce vraiment nécessaire ?

Action	daemon-reload nécessaire ?
Modifier un fichier .service existant	Oui
Ajouter un nouveau fichier .service	Oui
Modifier un timer systemd	Oui
Utiliser `systemctl edit`	Non (fait automatiquement)
Modifier via `/etc/systemd/system/`	Oui

Comprendre les emplacements des unit files

Systemd cherche les unit files dans plusieurs répertoires, dans un ordre de priorité précis :

Emplacement	Description	Priorité
`/etc/systemd/system/`	Units personnalisés (admin)	1 (最高)
`/run/systemd/system/`	Units temporaires runtime	2
`/usr/lib/systemd/system/`	Units installés par les paquets	3

Visualiser la priorité

# Voir où systemd trouve un service
systemctl show nginx | grep FragmentPath

Le premier trouvé wins. Si tu crées un unit dans /etc/systemd/system/, il cache celui de /usr/lib/systemd/system/.

Masquer un service (mask)

Pourquoi masquer ?

Un service masqué ne peut absolument pas être démarré, même par root. C'est plus fort qu'un simple stop ou disable. Utile pour :

Désactiver un service qui entre en conflit avec un autre
Bloquer un service qu'on ne veut jamais démarrer
Empêcher un service de démarrer accidentellement

Masquer un service

sudo systemctl mask nginx

Résultat : un lien symbolique est créé :

/etc/systemd/system/nginx.service -> /dev/null

Toutes les tentatives de démarrage échoueront, même avec sudo systemctl start nginx.

Vérifier qu'un service est masqué

systemctl is-active nginx
# Affiche : masked

systemctl status nginx
# Affiche : Loaded: loaded (/dev/null; masked)

Démasquer un service

sudo systemctl unmask nginx

Le lien symbolique est supprimé et le service redevient normal.

Liste des services masqués

systemctl list-units --type=service --state=masked

Exemple : masquer cups (impression)

# Vérifier d'abord
systemctl status cups

# Masquer pour empêcher tout démarrage
sudo systemctl mask cups

# Le service est maintenant bloqué
systemctl is-enabled cups
# Affiche : masked

Créer un service via lien symbolique

Principe

Plutôt que de copier un fichier unit, on crée un lien symbolique. Avantages :

Modification unique = affecte tous les liens
Moins de duplication
Organisation claire des services actifs

Créer un lien symbolique pour un service

# Méthode 1 : avec ln
sudo ln -s /usr/lib/systemd/system/mon-service.service \
       /etc/systemd/system/mon-service.service

# Méthode 2 : avec systemctl enable (automatic)
sudo systemctl enable mon-service
# Cela crée automatiquement les liens nécessaires

Voir les liens symboliques actifs

# Lister les liens dans /etc/systemd/system/
ls -la /etc/systemd/system/*.wants/

Cas pratique : service multi-instances

# Tu as un template service : nginx@.service
# Tu veux deux instances : nginx@1 et nginx@2

sudo systemctl enable nginx@1
sudo systemctl enable nginx@2

# Les liens créés :
# /etc/systemd/system/nginx@1.service -> /usr/lib/systemd/system/nginx@.service
# /etc/systemd/system/nginx@2.service -> /usr/lib/systemd/system/nginx@.service

Organiser ses services avec les répertoires .wants

Les répertoires .wants

Quand tu fais systemctl enable service, systemd crée un lien dans un répertoire *.wants. Ces répertoires définissent les dépendances.

/etc/systemd/system/multi-user.target.wants/
/etc/systemd/system/sockets.target.wants/
/etc/systemd/system/timers.target.wants/

Comprendre les targets

Target	Description
`multi-user.target`	Système multi-utilisateur (mode texte)
`graphical.target`	Système avec interface graphique
`network.target`	Réseau disponible
`remote-fs.target`	Systèmes de fichiers distants montés

Ajouter manuellement une dépendance

# Faire en sorte que mon-service démarre après le réseau
sudo ln -s /etc/systemd/system/mon-service.service \
       /etc/systemd/system/network.target.wants/mon-service.service

Workflow complet : créer et activer un service

# 1. Créer le fichier unit
sudo nano /etc/systemd/system/mon-script.service

[Unit]
Description=Mon script de surveillance
After=network.target

[Service]
Type=simple
ExecStart=/home/david/scripts/mon-script.sh
Restart=always
User=david

[Install]
WantedBy=multi-user.target

# 2. Recharger systemd
sudo systemctl daemon-reload

# 3. Activer (créer les liens)
sudo systemctl enable mon-script.service

# 4. Démarrer le service
sudo systemctl start mon-script.service

# 5. Vérifier
systemctl status mon-script.service

Commandes de diagnostic

Voir la configuration chargée

# Voir le fichier unit actif (et sa source)
systemctl cat nginx

Voir les propriétés d'un service

systemctl show nginx --no-pager

Voir pourquoi un service a échoué

systemctl status nginx
journalctl -u nginx -n 50 --no-pager

Lister tous les services et leur état

# Services actifs
systemctl list-units --type=service --state=running

# Tous les services
systemctl list-units --type=service --all

Erreurs courantes et solutions

Erreur : "Unit file does not exist"

# Tu as supprimé le fichier ou fait une faute de frappe
sudo systemctl daemon-reload
systemctl reset-failed

Erreur : "Service is masked"

# Il faut démasquer avant de démarrer
sudo systemctl unmask nom-service
sudo systemctl start nom-service

Erreur : "Process exited"

# Le script s'est terminé trop vite
# Ajoute Type=oneshot ou RemainAfterExit=yes

[Service]
Type=oneshot
ExecStart=/chemin/vers/script.sh
RemainAfterExit=yes

Modifications non appliquées

# Toujours faire :
sudo systemctl daemon-reload
sudo systemctl restart nom-service

Bonnes pratiques

Toujours utiliser sudo pour les commandes systemctl
Après toute modification de fichier unit, faire daemon-reload
Vérifier avec systemctl status après chaque action
Utiliser journalctl -u service -n 50 pour diagnostiquer
Masquer plutôt que désactiver quand on veut empêcher tout démarrage
Préférer les liens symboliques aux copies pour maintenir une seule source de vérité
Ne jamais éditer directement les fichiers dans /usr/lib/systemd/

Résumé

Commande	Usage
`systemctl daemon-reload`	Recharger la configuration systemd après modification
`systemctl mask service`	Bloquer définitivement un service (même root ne peut pas le démarrer)
`systemctl unmask service`	Retirer le masque d'un service
`systemctl cat service`	Voir le fichier unit chargé
`systemctl show service`	Voir toutes les propriétés d'un service
`systemctl list-units --state=masked`	Lister les services masqués