Cours Ubuntu 26.04 / Modifier la configuration d’un service avec validation et drop-ins

Pour changer une configuration de service Ubuntu, relevez la source et les valeurs effectives, préparez une modification locale distincte, validez-la puis contrôlez le résultat réel après application. Relire les unités systemd, demander à l’application de relire ses réglages et redémarrer son processus sont trois opérations différentes.

Identifier le fichier source, les surcharges et l’état appliqué

Une unité systemd décrit la façon de gérer un service ; un drop-in est un fragment local qui complète ou remplace certaines valeurs sans réécrire le fichier d’origine. Retrouvez le nom exact par votre lecture des services et journaux systemd, puis utilisez systemctl cat suivi de ce nom et systemctl show avec les propriétés FragmentPath et DropInPaths.

cat présente les fichiers sur disque. Si vous venez de les modifier sans daemon-reload, ils peuvent différer de ce que le gestionnaire a en mémoire. show permet d’examiner ses propriétés ; le comportement du processus déjà lancé constitue encore une vérification distincte.

Préservez les fichiers distribués par les paquets, habituellement sous /usr/lib/systemd/system. Placez la modification locale appropriée sous /etc/systemd/system. Les règles des unités et des drop-ins expliquent les chemins et l’ordre de fusion ; certaines directives de liste demandent une remise à zéro avant remplacement. Ne généralisez pas le comportement d’un champ à tous les autres.

Vérifier que le nom du service d’exercice est libre

Ce laboratoire utilise une nouvelle unité ubuntu-course-lab.service qui se contente d’afficher une variable puis de terminer. Il ne modifie pas un serveur web, un réseau ou un service de production. Travaillez dans la VM prévue et vérifiez la disponibilité de /usr/bin/printenv.

systemctl cat ubuntu-course-lab.service
systemctl show ubuntu-course-lab.service -p LoadState -p FragmentPath -p DropInPaths
command -v printenv

Pour ce nom neuf, l’unité ne doit pas être trouvée et aucun fichier ni drop-in préexistant ne doit être sélectionné. Un problème de connexion au gestionnaire systemd n’est pas une preuve que le nom est libre : résolvez-le avant de continuer. Si une unité, un masque ou une configuration existe déjà, choisissez un autre nom et adaptez tous les chemins et commandes.

Notez les fichiers que vous allez créer. Les redirections des blocs suivants utilisent noclobber, set -C, pour refuser l’écrasement d’un fichier existant ; elles ne remplacent pas l’inventaire préalable du nom et des surcharges.

Créer une unité complète et constater la valeur initiale

Exécutez ce bloc seulement après les contrôles précédents. Les marqueurs EOF doivent rester seuls sur leur ligne :

(
set -eu
sudo sh -c 'set -C; cat > /etc/systemd/system/ubuntu-course-lab.service' <<'EOF'
[Unit]
Description=Ubuntu course configuration lab

[Service]
Type=oneshot
Environment=LAB_MODE=baseline
ExecStart=/usr/bin/printenv LAB_MODE
EOF
sudo systemd-analyze --recursive-errors=yes verify /etc/systemd/system/ubuntu-course-lab.service
sudo systemctl daemon-reload
sudo systemctl start ubuntu-course-lab.service
sudo journalctl -u ubuntu-course-lab.service --since '5 minutes ago' --no-pager
systemctl show ubuntu-course-lab.service -p Result -p ExecMainStatus
)

La sortie récente du programme doit contenir baseline, avec un résultat réussi et un code de sortie 0. Le type oneshot attend la fin du programme puis peut revenir à inactive lorsque RemainAfterExit n’est pas activé. Cet état ne constitue donc pas, à lui seul, un échec ; un nouveau start exécute de nouveau l’action.

Le contrôle systemd-analyze verify recherche notamment des directives inconnues, dépendances manquantes et exécutables introuvables. --recursive-errors=yes fait produire un code non nul si des avertissements surviennent pour l’unité ou ses dépendances. Lisez néanmoins toute la sortie : une vérification structurelle ne teste pas la logique d’une application.

Si la création échoue, ne poursuivez pas la séquence manuellement sans savoir quel fichier existe. Une erreur de vérification peut laisser le fichier créé sur disque ; corrigez cette seule source avant de la charger. Ne remplacez pas l’échec par une suppression large de la configuration systemd.

Appliquer une surcharge locale et vérifier une nouvelle exécution

Gardez la valeur baseline dans le fichier principal. Créez seulement ce nouveau fragment pour l’exercice ; si 10-lab.conf existe déjà, le bloc refuse de l’écraser :

(
set -eu
sudo mkdir -p /etc/systemd/system/ubuntu-course-lab.service.d
sudo sh -c 'set -C; cat > /etc/systemd/system/ubuntu-course-lab.service.d/10-lab.conf' <<'EOF'
[Service]
Environment=LAB_MODE=changed
EOF
sudo systemd-analyze --recursive-errors=yes verify /etc/systemd/system/ubuntu-course-lab.service
sudo systemctl daemon-reload
systemctl cat ubuntu-course-lab.service
systemctl show ubuntu-course-lab.service -p Environment -p DropInPaths
sudo systemctl start ubuntu-course-lab.service
sudo journalctl -u ubuntu-course-lab.service --since '5 minutes ago' --no-pager
systemctl show ubuntu-course-lab.service -p Result -p ExecMainStatus
)

Vérifiez que DropInPaths contient le fragment attendu, que l’environnement effectif présente LAB_MODE=changed et que la nouvelle exécution affiche changed. Le journal peut encore contenir l’ancien baseline dans la même fenêtre : comparez les heures et la dernière exécution au lieu de considérer toute occurrence comme le résultat actuel.

Pour cette variable, la surcharge tardive remplace la valeur de même nom. La configuration de l’environnement d’exécution systemd décrit Environment et les autres sources de valeurs. Un secret ne doit pas être traité comme une simple variable affichée dans un journal ; ce laboratoire utilise uniquement une chaîne sans caractère sensible.

Choisir la bonne action entre daemon-reload, reload et restart

Le manuel systemctl distingue ces opérations. Dans l’exercice, le programme oneshot est déjà terminé, donc start suffit à observer une nouvelle valeur après daemon-reload. Sur un serveur qui continue à tourner, une modification d’Environment exige généralement une nouvelle exécution du processus, pas seulement daemon-reload.

Un changement du fichier de configuration d’une application suit encore son propre validateur, par exemple nginx -t pour Nginx, et son mécanisme de relecture documenté. Une unité valide n’établit pas que l’application accepte sa configuration, peut accéder à ses fichiers ou écoute sur le bon port.

Avant un changement réel, relevez source, paramètres effectifs, sauvegarde et commande de validation spécifique, puis choisissez la fenêtre d’application. Vérifiez ensuite un résultat utile depuis le client : réponse attendue, droits et données, en plus de l’état du processus et de ses journaux.

Retirer uniquement le fragment créé et retrouver baseline

Le fichier suivant doit être exactement celui créé pendant cet exercice. Contrôlez son contenu et son origine avant de le retirer ; ne lancez pas ce bloc sur un fragment qui existait auparavant :

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-course-lab.service.d/10-lab.conf
sudo systemd-analyze --recursive-errors=yes verify /etc/systemd/system/ubuntu-course-lab.service
sudo systemctl daemon-reload
sudo systemctl start ubuntu-course-lab.service
sudo journalctl -u ubuntu-course-lab.service --since '5 minutes ago' --no-pager
systemctl show ubuntu-course-lab.service -p Environment -p Result -p ExecMainStatus
)

La nouvelle exécution doit de nouveau afficher baseline, et le fragment retiré ne doit plus apparaître dans les sources retenues. Cette suppression ne touche que le fichier d’exercice. systemctl revert peut supprimer d’autres surcharges locales ; ne l’utilisez pas comme équivalent automatique d’un retour ciblé.

Pour terminer, le fichier principal ubuntu-course-lab.service peut aussi être retiré après confirmation qu’il a été créé par ce laboratoire et qu’aucune tâche n’est en cours. Retirez seulement ce fichier et, si vous le souhaitez, son répertoire de fragment devenu vide, puis faites daemon-reload. Aucun enable n’a été demandé ici et l’unité n’a pas de section d’installation pour un démarrage automatique.

Si le résultat ne revient pas à la valeur attendue, relisez cat, DropInPaths, Environment et les heures du journal. Une autre surcharge ou une application qui n’a pas relu ses données demande un diagnostic précis ; répéter des redémarrages sans identifier la source ne restaure pas nécessairement le bon état.