Linux / Commande systemctl : état, démarrage et activation des services

systemctl consulte et contrôle les unités gérées par systemd, notamment les services. start démarre une unité maintenant ; enable configure son activation selon sa section d’installation, généralement au démarrage. Vérifiez séparément l’état actif et l’état d’activation : un service peut être arrêté tout en restant activé pour un prochain démarrage.

Identifier l’unité et consulter son état

Une unité est un objet géré par systemd : service, socket, timer ou autre ressource. Ce guide vise le gestionnaire système. Les unités du gestionnaire utilisateur se consultent séparément avec --user ; ne mélangez pas ces contextes. La leçon sur les services systemd et les journaux de démarrage présente leur organisation.

systemctl status sshd.service
systemctl is-active sshd.service
systemctl is-enabled sshd.service

sshd.service est un nom d’exemple ; certaines distributions utilisent un autre nom. Consultez les unités installées avec systemctl list-unit-files --type=service. status affiche notamment l’état, des processus associés et des journaux récents accessibles. Un service inactif peut faire renvoyer un statut non nul à cette commande sans que systemctl soit cassé.

is-active peut afficher active pour une unité active. Cela ne signifie pas nécessairement qu’un processus tourne toujours : un service oneshot avec RemainAfterExit=yes peut rester actif après la fin réussie de sa commande. is-enabled concerne l’installation de l’unité, avec des états tels que enabled, disabled, static ou masked ; tous ne se réduisent pas à un oui/non de démarrage automatique.

Dans un script, ciblez une seule unité et examinez la sortie et le statut de retour. Avec plusieurs unités, un succès peut seulement signifier qu’au moins l’une satisfait le critère. Pour les journaux détaillés de l’exemple :

journalctl -u sshd.service -b

Distinguer exécution, installation et rechargement

enable ne remplace pas start. --now combiné à enable demande aussi le démarrage ; combiné à disable, il demande aussi l’arrêt. Une unité disabled peut encore être démarrée explicitement ou par une dépendance : disabled ne signifie pas une interdiction générale.

reload et daemon-reload visent des configurations différentes. Si vous modifiez un fichier d’unité, faites relire sa définition avec sudo systemctl daemon-reload, puis appliquez à l’unité concernée le changement approprié. daemon-reload ne redémarre pas le service. Une configuration propre à l’application peut nécessiter son propre contrôle de validité et son mécanisme de rechargement.

Arrêter ou redémarrer SSH, un serveur web ou une base de données peut interrompre des connexions. Vérifiez le nom, les dépendances, la fenêtre d’intervention et le moyen de rétablir l’accès avant une modification. Le laboratoire suivant utilise une nouvelle unité dédiée dans une machine virtuelle de test.

Comparer active et enabled dans une VM dédiée

Utilisez une VM de laboratoire démarrée avec systemd comme processus PID 1, disposant de sudo, de systemd-analyze et de /usr/bin/true. Le bloc crée une unité oneshot sans service réseau, puis change temporairement sa configuration de démarrage. Il refuse un nom de fichier ou d’unité déjà présent. Ne l’exécutez pas sur un serveur en production.

(
set -eu
unit=lf-systemctl-lab.service
file=/etc/systemd/system/$unit
known=$(systemctl list-unit-files "$unit" --no-legend --no-pager) || exit 1
if [ -n "$known" ] ||
   sudo test -e "$file" || sudo test -L "$file" ||
   sudo test -e "$file.d" || sudo test -L "$file.d"; then
    printf 'Nom de laboratoire existant : choisissez un autre nom.\n' >&2
    exit 1
fi
[ -x /usr/bin/true ] || exit 1
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Linux Factory systemctl state lab
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
systemctl is-active "$unit"
sudo systemctl enable "$unit"
systemctl is-enabled "$unit"
sudo systemctl stop "$unit"
systemctl is-active "$unit" || true
systemctl is-enabled "$unit"
sudo systemctl disable "$unit"
systemctl is-enabled "$unit" || true
)

La création utilise noclobber, activé par set -C, pour refuser d’écraser un fichier qui serait apparu entre le contrôle et l’écriture. Si une étape échoue, examinez son diagnostic avant de poursuivre ; le fichier ou les liens créés auparavant peuvent encore être présents. Les deux contrôles suivis de || true permettent ici d’afficher des états négatifs attendus sans arrêter le bloc ; ne les prenez pas pour une validation automatique de toute erreur.

RemainAfterExit=yes explique le premier état : /usr/bin/true termine aussitôt avec succès, mais systemd conserve l’unité active. Il n’y a pas de processus long à observer dans cet exemple. Pour voir le détail, consultez systemctl status lf-systemctl-lab.service.

Nettoyer uniquement l’unité créée et vérifier

Vérifiez d’abord que le fichier est toujours exactement la définition du laboratoire, sans modification réalisée par ailleurs :

sudo cat /etc/systemd/system/lf-systemctl-lab.service

Après cette vérification, arrêtez et désactivez uniquement cette unité, retirez uniquement son fichier puis faites relire les unités :

sudo systemctl disable --now lf-systemctl-lab.service
sudo rm -- /etc/systemd/system/lf-systemctl-lab.service
sudo systemctl daemon-reload
systemctl list-unit-files lf-systemctl-lab.service --no-legend --no-pager

Après le retrait, aucune ligne d’unité installée ne doit rester pour ce nom dans ce laboratoire. Si le nom existait avant la tentative, le bloc initial devait s’arrêter : ne nettoyez pas un fichier préexistant. En cas d’interruption, inspectez le même fichier et la même unité avant d’appliquer ce nettoyage ; ne supprimez aucun répertoire de services ni une autre unité.

Le manuel systemctl de systemd décrit les états, l’installation et le rechargement. Le manuel des unités de service explique Type=oneshot et RemainAfterExit.