Démarrage automatique d'un service Linux au boot (systemctl enable)

Le service tourne, vous redémarrez la machine, il est arrêté. Rien n'est cassé : il n'a jamais été activé au boot. La commande qui règle ça tient en une ligne, sudo systemctl enable --now nginx, et la seule vérification qui compte ensuite est systemctl is-enabled. Cette page couvre le démarrage automatique d'un service Linux avec systemd : activer, désactiver, masquer, lire les états d'activation, comprendre la cible qui déclenche le service, et savoir ce que is-enabled prouve réellement.

Ce que vous allez apprendre

• Rendre un service automatique au démarrage avec systemctl enable
• Vérifier l'activation avec systemctl is-enabled et lire la sortie sans se tromper
• Distinguer les états enabled, enabled-runtime, disabled, static, masked et alias
• Comprendre le mécanisme WantedBy et les cibles (targets) qui déclenchent un service au boot
• Masquer un service pour interdire tout démarrage, y compris manuel
• Diagnostiquer un service qui ne repart pas après un redémarrage

LFCS / RHCSA

L'autostart des services est un objectif explicite des deux certifications. Vous devez savoir manier systemctl enable, disable, mask et prouver l'état avec is-enabled. Les correcteurs rebootent la machine : un service démarré à la main sans enable compte pour zéro.

Toutes les sorties de cette page proviennent d'un système Debian 13 (trixie) avec systemd 257 et Nginx comme service réel. Elles peuvent différer légèrement chez vous selon la distribution, et cette différence est justement un des pièges expliqués plus bas.

Démarré maintenant, automatique au boot : deux choses différentes

C'est la confusion qui envoie le plus de monde sur cette page. Un service systemd a deux états totalement indépendants : est-ce qu'il tourne en ce moment, et est-ce qu'il redémarrera tout seul au prochain boot. start répond au premier, enable répond au second.

Question	État	Commande
Le service tourne-t-il maintenant ?	active / inactive	systemctl is-active nginx
Le service repartira-t-il au prochain boot ?	enabled / disabled	systemctl is-enabled nginx

Glissez pour voir

Les deux se combinent librement, et chaque combinaison correspond à une situation réelle d'exploitation :

Combinaison	Ce que ça veut dire
active + enabled	Tourne et repartira au boot. L'état normal d'un service de production.
active + disabled	Tourne, mais disparaîtra au reboot. Le piège classique après une installation.
inactive + enabled	Arrêté maintenant, démarrera au prochain boot. Typique après un stop de maintenance.
inactive + disabled	Arrêté et ne reviendra pas. L'état d'un service volontairement écarté.

Glissez pour voir

La faute qui coûte un incident

systemctl start nginx démarre le service immédiatement et rien d'autre. Aucune trace n'est écrite sur le disque, donc aucun autostart. Le serveur redémarre trois semaines plus tard pour un patch noyau, Nginx ne remonte pas, et personne ne fait le lien avec l'installation. enable est ce qui rend l'activation persistante.

Activer le démarrage automatique d'un service

L'activation consiste à demander à systemd de se souvenir qu'il faut lancer ce service à chaque boot. Concrètement, systemd écrit un lien symbolique dans le répertoire de la cible qui déclenche le service. Ce lien vit sur le disque, donc il survit à un redémarrage.

Activer sans démarrer tout de suite

Cas d'usage : vous préparez un serveur, le service doit être automatique au boot mais vous ne voulez pas encore l'exposer.

sudo systemctl enable nginx

Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx
Created symlink '/etc/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.service'.

Trois lignes, et deux d'entre elles ne parlent pas de systemd. Les paquets Debian et Ubuntu qui embarquent encore un script SysV (l'ancien système d'init) déclenchent une couche de compatibilité, systemd-sysv-install, dont les deux premières lignes sont le bavardage. La ligne utile est la troisième : le lien symbolique créé dans multi-user.target.wants/.

Pourquoi vous ne voyez pas toujours « Created symlink »

Beaucoup de lecteurs relancent la commande, ne voient plus que les deux lignes SysV, et croient à un échec. Il n'y en a aucun : enable est idempotent. Si le lien existe déjà, systemd n'a rien à créer et n'affiche rien de plus.

sudo systemctl enable nginx

Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx

Sur une unité sans script SysV (la majorité des services modernes, et le cas général sur RHEL ou Fedora), les deux lignes de compatibilité disparaissent et il ne reste que le Created symlink. Retenez la règle : le message affiché dépend du paquet et de l'état antérieur, il ne prouve rien. La seule sortie qui fait autorité est celle de is-enabled.

Activer et démarrer en une commande

C'est la forme à utiliser dans 99 % des installations, parce qu'elle supprime l'oubli le plus fréquent.

sudo systemctl enable --now nginx

Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx
Created symlink '/etc/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.service'.

Le drapeau --now ajoute un start à l'activation. Vérifiez les deux états derrière, pas un seul :

systemctl is-active nginx && systemctl is-enabled nginx

active
enabled

Vérifier l'activation, y compris dans un script

is-enabled affiche l'état et positionne aussi un code de retour exploitable en automatisation. Avec --quiet, la commande n'affiche rien et se contente de rendre 0 si le service est activé.

systemctl is-enabled --quiet nginx; echo "code=$?"

code=0

Ce couple sortie plus code retour est la base des contrôles de conformité : une boucle sur la liste des services critiques d'un serveur suffit à détecter celui qui a été démarré à la main et jamais activé.

Attention à un piège en automatisation : is-enabled renvoie aussi 0 pour les états static, alias, indirect, generated et transient, pas seulement pour enabled. Une boucle qui teste uniquement le code retour peut donc valider une unité static qui ne démarrera pourtant pas d'elle-même au boot. Pour un vrai contrôle, comparez la chaîne affichée à enabled (ou enabled-runtime), pas seulement le $?.

Désactiver et masquer un service

Désactiver retire le démarrage automatique sans toucher au service en cours. Masquer va beaucoup plus loin : le service devient impossible à démarrer, y compris à la main. Les deux répondent à des besoins différents, et les confondre mène soit à un service qui revient tout seul, soit à un service que plus personne n'arrive à relancer.

Désactiver l'autostart

sudo systemctl disable nginx

Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install disable nginx
Removed '/etc/systemd/system/multi-user.target.wants/nginx.service'.

Le lien symbolique disparaît, donc le service ne repartira plus au boot. En revanche il continue de tourner s'il était actif : disable ne coupe rien. Pour désactiver et arrêter d'un coup, sudo systemctl disable --now nginx. Contrôlez avec systemctl is-enabled nginx, qui doit afficher disabled.

Masquer pour interdire tout démarrage

Masquer remplace l'unité par un lien vers /dev/null. Plus rien ne peut la démarrer : ni vous, ni une dépendance d'un autre service, ni un paquet qui se met à jour.

sudo systemctl mask nginx

Created symlink '/etc/systemd/system/nginx.service' → '/dev/null'.

Toute tentative de démarrage échoue franchement, avec un message qui nomme la cause :

sudo systemctl start nginx

Failed to start nginx.service: Unit nginx.service is masked.

Un enable sur une unité masquée échoue lui aussi, avec un code retour 1 : Failed to enable unit: Unit /etc/systemd/system/nginx.service is masked. Pour revenir en arrière, sudo systemctl unmask nginx supprime le lien vers /dev/null et rend l'unité de nouveau gérable.

Masquer, oui, mais en connaissance de cause

Réservez mask aux services que vous voulez interdire durablement : cups.service sur un serveur sans imprimante, un service remplacé par un autre, une unité tirée par un paquet dont vous ne voulez pas. Sur un service dont d'autres unités dépendent, le masquage peut faire échouer leur démarrage en cascade au prochain boot. Un disable suffit dans la plupart des cas.

Lire les états d'activation

systemctl is-enabled ne répond pas seulement enabled ou disabled. Les états ci-dessous sont ceux que vous croiserez réellement sur un serveur, tous relevés sur le même système Debian 13. Les connaître évite de conclure trop vite qu'un service « n'est pas activé » alors qu'il est simplement conçu autrement.

État	Ce que ça signifie	Exemple relevé
enabled	Activé au boot, lien symbolique présent dans /etc/systemd/system/	nginx.service
enabled-runtime	Activé jusqu'au prochain reboot seulement, lien créé dans /run/, donc en mémoire	systemd-remount-fs.service
disabled	Pas d'autostart, aucun lien, mais le service reste démarrable à la main	debug-shell.service
static	Aucune section [Install], l'unité ne s'active pas, elle est tirée comme dépendance	systemd-tmpfiles-clean.service
masked	Démarrage interdit, l'unité pointe sur /dev/null	console-getty.service
alias	Le nom n'est qu'un autre nom pour une unité existante	kmod.service

Glissez pour voir

L'état enabled-runtime, celui que tout le monde oublie

systemctl enable --runtime active un service sans rien écrire sur le disque : le lien symbolique atterrit dans /run/systemd/system/, un système de fichiers en mémoire vidé à chaque redémarrage.

sudo systemctl enable --runtime nginx
systemctl is-enabled nginx

Created symlink '/run/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.service'.
enabled-runtime

C'est utile pour une activation temporaire pendant une intervention, quand vous voulez la garantie que l'état d'origine revient au reboot. C'est un piège redoutable dans le cas contraire : un is-enabled qui répond enabled-runtime ressemble à s'y méprendre à enabled, alors que le service ne repartira pas après un redémarrage. Si vous vouliez une activation durable, rejouez un sudo systemctl enable nginx sans --runtime.

Un service static ne s'active pas, et c'est normal

Une unité static n'a pas de section [Install], donc systemd ne sait pas où accrocher le lien symbolique. Elle est prévue pour être tirée par une dépendance, un timer ou une activation à la demande.

sudo systemctl enable systemd-tmpfiles-clean.service

The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.

systemd vous explique lui-même la situation et ne crée aucun lien. Rien à réparer : si vous vouliez rendre ce service automatique au boot, c'est le fichier unité qu'il faut compléter, pas la commande qu'il faut changer.

Ce qui déclenche réellement le service au boot

Un service ne démarre pas « au boot » dans l'absolu. Il démarre parce qu'une cible (target) atteinte pendant le démarrage le réclame. La section [Install] du fichier unité indique laquelle, et c'est exactement ce que enable lit pour savoir dans quel répertoire poser le lien.

systemctl cat nginx.service

[Unit]
Description=A high performance web server and a reverse proxy server
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
ConditionFileIsExecutable=/usr/sbin/nginx

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'

[Install]
WantedBy=multi-user.target

Directive de [Install]	Rôle à l'activation
WantedBy=multi-user.target	Crée le lien dans multi-user.target.wants/, dépendance souple : si le service échoue, la cible est quand même atteinte
RequiredBy=	Même principe en dépendance forte : l'échec du service fait échouer la cible
Also=	Enable d'autres unités en même temps (sans les démarrer), typiquement un socket associé. Joue aussi au disable

Glissez pour voir

Les cibles qui comptent sur un serveur

Les targets ont remplacé les runlevels de SysV, et les anciens noms survivent en simples alias : runlevel3.target pointe sur multi-user.target, runlevel5.target sur graphical.target, runlevel1.target sur rescue.target. Voir cette équivalence aide à lire les vieux scripts d'exploitation.

Cible	Ancien runlevel	Quand elle est atteinte
multi-user.target	3	Serveur en réseau sans interface graphique, le cas normal en production
graphical.target	5	Poste ou serveur avec environnement graphique
rescue.target	1	Mode maintenance, un minimum de services, souvent mono-utilisateur

Glissez pour voir

La quasi-totalité des services serveur déclarent WantedBy=multi-user.target. Et même si la machine boote en graphical.target, ils démarrent quand même : graphical.target déclare Requires=multi-user.target, donc elle englobe la cible multi-utilisateur. La cible visée au boot se lit avec systemctl get-default.

Voir qui sera lancé, et l'inventaire complet

Deux commandes suffisent à répondre à « qu'est-ce qui démarre sur cette machine ». La première liste les services accrochés à la cible, la seconde donne l'état d'activation de tout ce qui est installé :

systemctl list-dependencies multi-user.target --type=service

multi-user.target
  nginx.service
  systemd-logind.service
  systemd-user-sessions.service

systemctl list-unit-files --type=service --state=enabled

UNIT FILE              STATE   PRESET
getty@.service         enabled enabled
nginx.service          enabled enabled
systemd-pstore.service enabled enabled

3 unit files listed.

La colonne PRESET n'est pas l'état courant : c'est ce que la distribution recommande par défaut. Un enabled en PRESET et un disabled en STATE signalent un service que quelqu'un a désactivé volontairement, information précieuse quand vous reprenez un serveur que vous n'avez pas installé.

Attention, deux commandes qui se ressemblent

systemctl list-units liste ce qui est chargé en mémoire en ce moment. systemctl list-unit-files liste ce qui est installé sur le disque, avec l'état d'activation. Pour l'autostart, c'est la seconde qu'il faut. Le détail du listing et du cycle de vie est traité dans Démarrer et diagnostiquer un service avec systemctl.

Presets et reenable : réparer une activation bancale

Deux commandes servent quand l'activation ne ressemble plus à ce qu'elle devrait être, typiquement après avoir modifié un fichier unité à la main.

systemctl reenable supprime puis recrée les liens à partir de la section [Install] courante. C'est le réflexe après avoir changé un WantedBy= : sans lui, l'ancien lien reste en place et le service continue d'être accroché à la mauvaise cible.

sudo systemctl reenable nginx

Removed '/etc/systemd/system/multi-user.target.wants/nginx.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.service'.

systemctl preset nginx remet le service dans l'état voulu par la distribution (la colonne PRESET). Debian et Ubuntu activent la plupart des services dès l'installation du paquet, RHEL est nettement plus conservateur. La commande ne dit rien quand il n'y a rien à changer, ce qui est le cas le plus fréquent ; vérifiez le résultat avec systemctl is-enabled nginx.

Vérifier que le service repart vraiment

Une page honnête doit le dire clairement : is-enabled ne prouve pas que le service démarrera. Il prouve que l'intention d'activation est correctement enregistrée, c'est-à-dire que le lien symbolique existe au bon endroit. Le service peut parfaitement être enabled et échouer au boot, parce que sa configuration est cassée, parce qu'il attend un montage réseau qui n'est pas encore là, ou parce qu'une dépendance a été masquée.

La vérification qui fait foi est donc un vrai redémarrage, sur une machine où vous pouvez vous le permettre :

sudo reboot

À la reconnexion, contrôlez les deux choses qui comptent, l'état du service et l'absence d'unité en échec :

systemctl is-active nginx
systemctl --failed

active

Une sortie vide de systemctl --failed signifie qu'aucune unité n'a échoué au démarrage. Si votre service est activé mais absent après le reboot, le diagnostic se poursuit avec journalctl -b -u nginx, qui montre le journal du boot courant pour cette unité, et se prolonge dans Dépanner un service qui ne démarre pas.

Dépannage

Les symptômes ci-dessous couvrent l'essentiel de ce qui bloque une activation au démarrage. Le point commun de ces situations : la commande a l'air d'avoir fonctionné, seul is-enabled révèle la vérité.

Symptôme	Cause probable	Correction
Le service est arrêté après chaque reboot	enable n'a jamais été exécuté, seulement start	sudo systemctl enable --now nginx puis systemctl is-enabled nginx
is-enabled répond enabled-runtime	Activation faite avec --runtime, elle vit en mémoire	Rejouer sudo systemctl enable nginx sans --runtime
Failed to enable unit: ... is masked	Le service est masqué	sudo systemctl unmask nginx puis sudo systemctl enable --now nginx
enable affiche « no installation config »	Unité static, pas de section [Install]	Rien à corriger, le service est tiré par une dépendance ; sinon ajouter [Install] au fichier unité
Pas de « Created symlink » à l'écran	Service déjà activé (commande idempotente) ou paquet à script SysV	Ne pas se fier au message, trancher avec systemctl is-enabled nginx
Le service démarre mais pas dans le bon contexte de boot	WantedBy= pointe la mauvaise cible	Corriger la section [Install] puis sudo systemctl reenable nginx
enabled mais absent après reboot	L'activation est bonne, c'est le démarrage qui échoue	journalctl -b -u nginx pour lire l'erreur réelle

Glissez pour voir

Le trio de diagnostic tient en trois commandes : l'état d'activation, le contenu de l'unité, et les liens réellement posés sur le disque.

systemctl is-enabled nginx
systemctl cat nginx.service
ls -l /etc/systemd/system/multi-user.target.wants/

Bonnes pratiques et sécurité

L'activation au boot n'est pas qu'une commodité d'exploitation, c'est aussi une décision de surface d'attaque. Chaque service activé est un processus qui démarrera sans que personne le demande, souvent en écoutant sur le réseau.

• Utiliser --now systématiquement à l'installation : enable --now pour mettre en service, disable --now pour retirer. L'oubli d'une des deux moitiés est l'erreur la plus courante.
• Désactiver explicitement ce dont le serveur n'a pas besoin plutôt que de le laisser activé par le preset de la distribution, particulièrement sur Debian et Ubuntu qui activent presque tout à l'installation.
• Masquer les services que vous voulez interdire pour de bon, en vérifiant d'abord qu'aucune autre unité n'en dépend.
• Inventorier l'existant avec systemctl list-unit-files --state=enabled sur un serveur repris : c'est la liste exacte de ce qui remontera au prochain redémarrage.
• Tester par un vrai reboot avant la mise en production. Un serveur qui n'a jamais rebooté depuis son installation est un serveur dont personne ne connaît le comportement au boot.
• Automatiser l'activation dans votre gestion de configuration plutôt que de la refaire à la main sur chaque machine, ce qui garantit que l'état d'activation est le même partout.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• systemctl enable rend un service automatique au démarrage en créant un lien symbolique ; disable le retire ; --now ajoute le start ou le stop correspondant.
• Un service peut être actif sans être activé, et inversement : is-active et is-enabled répondent à deux questions différentes.
• Le message affiché par enable dépend du paquet et de l'état antérieur : les lignes Synchronizing state ... SysV sont de la compatibilité Debian, et Created symlink n'apparaît que si un lien est réellement créé. Seul is-enabled fait autorité.
• enabled-runtime signifie activé jusqu'au prochain reboot seulement : le lien est dans /run/, il ne survit pas au redémarrage.
• Une unité static n'a pas de section [Install] et ne s'active pas : elle est tirée comme dépendance.
• mask interdit tout démarrage, y compris manuel et y compris par une dépendance ; c'est plus fort que disable.
• L'activation repose sur WantedBy= dans la section [Install], et la cible multi-user.target est celle de la quasi-totalité des services serveur.
• Seul un vrai reboot fait foi : is-enabled prouve l'intention d'activation, pas le succès du démarrage.

Pour aller plus loin

• Durcir un service systemd avec le sandboxing : réduire ce qu'un service activé au boot peut atteindre sur le système.
• Module systemd_service d'Ansible : automatiser enabled, state et masked sur un parc de serveurs.
• RHCSA : compétences essentielles : replacer l'activation des services dans les objectifs de la certification.

×

📖 Voir la documentation →