Lancer un script au démarrage avec systemd : guide complet et fiable

Pour lancer un script au démarrage avec systemd, créez un fichier .service dans /etc/systemd/system/, indiquez le chemin absolu du script avec ExecStart, puis rechargez systemd et activez le service avec systemctl enable. Cette méthode permet d’exécuter un script Linux automatiquement au démarrage tout en gardant un contrôle clair sur les dépendances, les journaux et les éventuels redémarrages.

Le point qui bloque le plus souvent n’est pas la commande systemctl enable, mais le contexte d’exécution : chemin relatif, script non exécutable, variable d’environnement absente ou privilèges trop larges. Ce tutoriel suit la séquence utile : préparer le script, créer le fichier unité systemd, activer le démarrage automatique, vérifier les journaux et corriger les erreurs courantes.

Comment fonctionne le lancement automatique avec systemd ?

Systemd est le gestionnaire de démarrage et de services utilisé par de nombreuses distributions Linux actuelles, notamment Debian, Ubuntu et Fedora. Pour exécuter un script au boot, systemd lit un fichier unité qui décrit quoi lancer, à quel moment, avec quelles dépendances et sous quel compte utilisateur.

Un service systemd est une définition déclarative, pas une simple ligne de commande ajoutée au démarrage. Le fichier unité rend le comportement du script observable : état, erreurs, journaux et politique de redémarrage restent accessibles avec les outils systemd. La syntaxe exacte et les directives disponibles sont documentées dans le manuel officiel systemd.service.

Pourquoi choisir systemd pour un script de démarrage ?

Systemd est adapté lorsqu’un script doit démarrer avec le système, attendre un élément précis du démarrage ou être relancé après un échec. La directive After= permet par exemple d’ordonner le lancement après un autre composant, tandis que Wants= exprime une dépendance souple.

• Service durable : un processus doit rester actif, comme un collecteur, un démon ou une boucle de surveillance.
• Action ponctuelle : un script prépare un dossier, monte une ressource ou génère un fichier au démarrage.
• Démarrage conditionné : un script doit attendre le réseau ou un autre service avant son exécution.

Systemd, cron et rc.local : quelle méthode choisir ?

La directive @reboot de cron peut lancer une commande au démarrage lorsque le démon cron est présent et configuré. Cette approche reste plus limitée pour diagnostiquer l’ordre de démarrage, les dépendances ou les redémarrages automatiques. Le fichier /etc/rc.local peut subsister comme mécanisme de compatibilité sur certains systèmes, mais sa prise en charge dépend de la distribution et de sa configuration.

Un service systemd s’exécute par défaut dans le contexte du gestionnaire système, donc généralement avec des privilèges administrateur si aucune directive User= n’est fournie. Le choix prudent consiste à déclarer explicitement un utilisateur non privilégié dès que le script n’a pas besoin d’accéder à des ressources système protégées.

Méthode	Usage adapté	Limite principale	Choix recommandé
Service systemd	Script critique, dépendances, journaux, redémarrage	Configuration initiale plus structurée	Oui pour un lancement automatique fiable
cron avec @reboot	Action simple liée au démon cron	Diagnostic et ordre de démarrage moins précis	Alternative ponctuelle
rc.local	Compatibilité sur système qui le prend en charge	Support variable selon la distribution	À éviter pour une nouvelle configuration

Un script qui fonctionne dans un terminal n’est pas automatiquement prêt pour systemd : son utilisateur, son répertoire courant et son environnement peuvent changer.

Préparer le script avant de créer le service

La préparation consiste à rendre le script autonome avant de confier son lancement à systemd. Un script Bash de démarrage doit indiquer son interpréteur, utiliser des chemins absolus et disposer du droit d’exécution ; sans ces trois éléments, l’erreur se situe souvent dans le script plutôt que dans le fichier .service.

Le script d’exemple ci-dessous écrit une ligne dans un fichier de journal local. Le résultat attendu est un fichier /var/log/mon-script-demarrage.log contenant une date à chaque démarrage réussi du service. Adaptez le chemin de sortie selon les droits du compte choisi.

Étape 1 : créer un script avec un interpréteur explicite

Créez le fichier /usr/local/bin/mon-script-demarrage.sh. Le répertoire /usr/local/bin convient aux scripts locaux administrés sur la machine, mais le chemin peut être différent si votre politique système l’exige.

#!/usr/bin/env bash
set -eu

printf 'Script lancé le %s\n' "$(date -Is)" >> /var/log/mon-script-demarrage.log

La ligne #!/usr/bin/env bash indique que le script doit être exécuté par Bash. L’option set -eu interrompt le script en cas d’erreur ou de variable non définie, ce qui facilite le diagnostic au lieu de masquer un échec.

Étape 2 : rendre le script exécutable et vérifier son chemin

Attribuez le droit d’exécution, puis vérifiez que le fichier existe bien à l’emplacement déclaré. Exécutez ces commandes avec un compte autorisé à modifier le répertoire choisi.

sudo chmod +x /usr/local/bin/mon-script-demarrage.sh
ls -l /usr/local/bin/mon-script-demarrage.sh

Le résultat de ls -l doit montrer au moins un droit x sur le fichier. Testez ensuite le script directement avec son chemin absolu avant de créer le service.

sudo /usr/local/bin/mon-script-demarrage.sh

Le test manuel ne prouve pas encore que systemd pourra l’exécuter, car le compte et les variables d’environnement peuvent différer. Il vérifie toutefois que le script est lisible, exécutable et syntaxiquement acceptable dans le contexte utilisé.

Étape 3 : remplacer les chemins relatifs et les secrets intégrés

Remplacez les chemins tels que ./config.json ou logs/sortie.log par des chemins absolus. Systemd ne démarre pas nécessairement dans le dossier depuis lequel vous avez testé le script dans votre terminal.

Un script qui traite des données de localisation, par exemple des relevés transmis par un appareil, gagne aussi à séparer clairement le programme, les données et les droits d’accès. Pour comprendre le principe des données de position qu’un script peut exploiter, consultez le calcul de position par GPS, sans confondre la collecte de données et leur protection.

Comment créer un fichier de service systemd pour un script ?

Pour créer un fichier unité systemd, ajoutez un fichier nommé mon-script-demarrage.service dans /etc/systemd/system/. Le fichier doit contenir les sections [Unit], [Service] et [Install], avec une directive ExecStart qui désigne le script par son chemin absolu.

Le nom du fichier devient le nom du service utilisé avec systemctl. Un service nommé mon-script-demarrage.service se gère donc avec systemctl status mon-script-demarrage.service, systemctl start mon-script-demarrage.service et les commandes associées.

Étape 4 : écrire une unité minimale et lisible

Ouvrez le fichier avec un éditeur disponible sur votre système. La commande suivante utilise nano, mais un autre éditeur de texte convient si vous maîtrisez son usage.

sudo nano /etc/systemd/system/mon-script-demarrage.service

Collez ensuite cette unité. Le type oneshot convient à un script qui exécute une action puis se termine ; il ne convient pas à un programme qui doit rester actif en continu.

[Unit]
Description=Exécution du script local au démarrage
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mon-script-demarrage.sh

[Install]
WantedBy=multi-user.target

La section [Unit] porte la description et les relations de démarrage. La section [Service] définit l’exécution réelle. La section [Install] indique comment le service s’intègre au démarrage normal grâce à WantedBy=multi-user.target.

Étape 5 : choisir le bon type de service et les dépendances utiles

Le type oneshot est cohérent pour une tâche courte, comme créer une ressource ou initialiser une configuration. Pour un script qui reste ouvert dans une boucle ou lance un processus permanent au premier plan, Type=simple constitue souvent le point de départ.

La directive After=network.target impose un ordre après l’initialisation générale du réseau, mais elle ne garantit pas qu’une connexion externe soit réellement disponible. Pour un besoin dépendant d’un réseau opérationnel, vérifiez dans la documentation de votre distribution si network-online.target et le service d’attente associé sont configurés.

Étape 6 : exécuter le service avec un compte dédié

Ajoutez User=nom-utilisateur et, si nécessaire, Group=nom-groupe dans la section [Service] lorsque le script ne demande pas les droits administrateur. Le compte choisi doit pouvoir lire le script et écrire dans les répertoires qu’il utilise.

[Service]
Type=oneshot
User=moncompte
Group=moncompte
ExecStart=/usr/local/bin/mon-script-demarrage.sh

Un script lancé avec un compte non privilégié ne pourra pas écrire dans /var/log sans autorisation adaptée. Préférez alors un journal dans un répertoire appartenant à ce compte, ou exploitez directement les journaux systemd plutôt que de multiplier les fichiers.

Comment activer un script au démarrage avec systemctl ?

Pour activer un service systemd au démarrage, rechargez d’abord la configuration avec systemctl daemon-reload, puis exécutez systemctl enable mon-script-demarrage.service. Lancez ensuite le service immédiatement avec systemctl start mon-script-demarrage.service afin de vérifier la configuration sans attendre le prochain redémarrage.

La commande enable prépare le lancement automatique, tandis que la commande start lance le service dans la session courante. Utiliser les deux commandes séparément évite de confondre un service activé pour plus tard avec un service déjà exécuté maintenant.

Étape 7 : recharger systemd après la création ou la modification

Systemd ne relit pas automatiquement un fichier unité modifié. Rechargez sa configuration à chaque changement du fichier .service.

sudo systemctl daemon-reload

Cette commande ne démarre pas le script. Elle informe uniquement systemd qu’une nouvelle définition de service est disponible, ce qui évite de diagnostiquer une ancienne configuration par erreur.

Étape 8 : activer le démarrage automatique et lancer le service

Activez le service pour les prochains démarrages, puis démarrez-le immédiatement. Le suffixe .service est explicite et recommandé dans un tutoriel, même si systemctl peut parfois l’inférer.

1. Activez le service : sudo systemctl enable mon-script-demarrage.service.
2. Démarrez-le sans redémarrer la machine : sudo systemctl start mon-script-demarrage.service.
3. Contrôlez son état : sudo systemctl status mon-script-demarrage.service.

Le manuel officiel systemctl détaille les différences entre activation, démarrage, arrêt et désactivation. Gardez ces opérations distinctes : elles répondent à des besoins différents.

Après une modification, la séquence fiable est simple : modifier, recharger systemd, redémarrer le service, lire son état et consulter son journal si nécessaire.

Vérifier le fonctionnement du service et lire les journaux

La vérification d’un service systemd repose sur deux commandes : systemctl status donne l’état synthétique et journalctl -u affiche les messages associés au service. Ces commandes permettent de savoir si systemd n’a pas lancé le script, si le script a échoué ou si l’action s’est terminée normalement.

Un service Type=oneshot peut afficher l’état inactive (dead) après une exécution réussie, car il n’a pas vocation à rester actif. Pour ce type de service, le code de sortie affiché et les journaux comptent davantage que la seule mention « active ».

Étape 9 : lire l’état actuel du service

Exécutez la commande suivante après un démarrage manuel ou après le redémarrage de la machine.

sudo systemctl status mon-script-demarrage.service

Recherchez les lignes indiquant Active:, Result: et le code de sortie. Une erreur status=203/EXEC, par exemple, oriente souvent vers un chemin ExecStart incorrect, un script non exécutable ou un interpréteur absent.

Étape 10 : consulter le journal du service

Affichez les messages du dernier démarrage avec la commande suivante. L’option -b limite la sortie au démarrage en cours, ce qui évite de mélanger des échecs anciens et récents.

sudo journalctl -u mon-script-demarrage.service -b

Ajoutez -e pour atteindre directement la fin du journal, ou -f pour suivre les messages en direct lors d’un redémarrage du service. La documentation officielle journalctl précise les filtres disponibles.

Étape 11 : valider après un redémarrage réel

Redémarrez uniquement lorsque le démarrage manuel fonctionne et que le journal ne montre pas d’erreur. Après le redémarrage, contrôlez de nouveau le service et le résultat attendu, par exemple la ligne ajoutée au fichier de journal du script.

sudo reboot

La commande redémarre immédiatement la machine et coupe les sessions en cours. En environnement distant ou de production, planifiez cette opération et assurez-vous de disposer d’un moyen de reconnexion avant de l’exécuter.

Erreurs fréquentes lors du lancement d’un script avec systemd

Les erreurs de démarrage viennent souvent d’une différence entre le terminal interactif et l’environnement minimal de systemd. Les chemins, les permissions, le répertoire de travail et l’utilisateur effectif doivent être explicitement vérifiés au lieu d’être supposés.

Un message d’erreur ne désigne pas toujours la ligne fautive, mais il donne une direction. La méthode la plus courte consiste à corriger une seule hypothèse à la fois, puis à recharger systemd et à relancer le service avant toute nouvelle modification.

Le script fonctionne dans le terminal mais échoue comme service

Le terminal charge souvent des variables comme PATH, HOME ou des configurations de shell que systemd ne charge pas. Utilisez le chemin absolu de chaque exécutable important, définissez WorkingDirectory= si le script dépend d’un dossier précis et évitez les alias shell.

Le service ne démarre pas après une modification

Un fichier unité modifié sans systemctl daemon-reload laisse systemd utiliser l’ancienne définition. Lancez d’abord la commande de rechargement, puis vérifiez la syntaxe et l’état avec systemctl status.

Le service s’arrête immédiatement

Un arrêt immédiat est normal pour Type=oneshot si le script a fini son travail. Pour un script censé rester actif, vérifiez qu’il ne se termine pas après avoir lancé un processus en arrière-plan ; systemd suit surtout le processus déclaré dans ExecStart.

Le script est lancé avec trop de privilèges

Un service système sans User= peut disposer de privilèges élevés. Ajoutez un utilisateur dédié lorsque cela est compatible avec les accès nécessaires, puis ajustez les droits des répertoires de données plutôt que d’élargir les permissions du système entier.

Le script doit attendre une ressource réseau

La présence d’un réseau local ne signifie pas qu’un serveur distant, un DNS ou une API est déjà disponible. Déclarez une dépendance cohérente, puis ajoutez dans le script une vérification explicite de la ressource dont dépend réellement votre tâche.

Gérer le service systemd au quotidien

La gestion quotidienne d’un service se fait avec les mêmes commandes que son activation initiale. Arrêter un service ne le désactive pas au prochain boot ; désactiver un service ne l’arrête pas forcément dans l’instant. Cette distinction évite les résultats inattendus pendant une maintenance.

Pour appliquer une modification, modifiez le script ou l’unité, rechargez systemd si le fichier .service a changé, puis redémarrez le service. Redémarrer sans relire l’unité est insuffisant après un changement de directives systemd.

• sudo systemctl stop mon-script-demarrage.service : arrête le service en cours.
• sudo systemctl restart mon-script-demarrage.service : relance le service avec sa définition déjà chargée.
• sudo systemctl disable mon-script-demarrage.service : retire le démarrage automatique.
• sudo systemctl enable mon-script-demarrage.service : réactive le lancement au démarrage.
• sudo systemctl mask mon-script-demarrage.service : empêche explicitement tout démarrage, y compris manuel, jusqu’à un unmask.

La commande mask est plus restrictive que disable. Réservez-la à un service qui ne doit vraiment pas pouvoir être lancé temporairement, car elle peut compliquer un diagnostic si elle est oubliée.

Rendre le service plus robuste et plus sûr

Un fichier service fiable réduit les privilèges, limite les dépendances implicites et prévoit le comportement attendu après un échec. La robustesse ne consiste pas à redémarrer sans fin un script défaillant : elle commence par des journaux lisibles et une cause d’échec identifiable.

La directive Restart=on-failure demande à systemd de relancer le service lorsqu’il se termine en erreur. Avec RestartSec=10, systemd attend 10 secondes avant une nouvelle tentative ; ce délai évite une succession trop rapide d’échecs.

Ajouter un redémarrage automatique pour un processus durable

Utilisez cette configuration pour un script qui doit rester actif, pas pour une simple tâche oneshot. Une tâche ponctuelle en échec mérite généralement une analyse avant toute répétition automatique.

[Service]
Type=simple
User=moncompte
ExecStart=/usr/local/bin/mon-script-permanent.sh
Restart=on-failure
RestartSec=10

Limiter l’exposition des données sensibles

Ne placez pas de mot de passe, de jeton d’API ou de clé privée directement dans ExecStart. Passez plutôt par un fichier de configuration lisible uniquement par le compte adapté, ou par un mécanisme de gestion des secrets prévu dans votre environnement.

Le service doit aussi écrire ses données dans un répertoire dont les droits correspondent au compte défini par User=. Vérifiez enfin que les journaux ne divulguent pas de paramètres sensibles, car journalctl centralise les sorties du service.

Quelles alternatives à systemd pour exécuter un script Linux au démarrage ?

Les alternatives à systemd existent, mais elles ne fournissent pas toutes le même niveau de contrôle. Cron avec @reboot peut suffire à une commande simple dépendante d’un utilisateur, tandis que rc.local relève surtout de la compatibilité sur les systèmes qui l’activent encore.

Systemd reste le choix le plus cohérent lorsqu’il faut gérer un service systemd à démarrage automatique, des journaux structurés, des dépendances ou une politique de reprise. Utilisez cron pour la planification temporelle ; utilisez systemd lorsque le lancement doit s’inscrire dans le cycle de démarrage du système.

Exemple prudent avec cron @reboot

Une entrée crontab peut contenir une commande @reboot. Cette solution dépend du compte dont la crontab est modifiée et de la disponibilité du démon cron ; elle ne reproduit donc pas exactement le comportement d’un service système.

@reboot /usr/local/bin/mon-script-demarrage.sh

Avant de retenir cette méthode, vérifiez que votre besoin ne porte pas plutôt sur une tâche planifiée à heure fixe. Les timers systemd constituent aussi une piste à examiner pour des exécutions récurrentes, sans confondre planification et démarrage initial.

Questions fréquentes

Comment lancer un script Bash au démarrage de Linux ?

Créez un script Bash exécutable avec une ligne d’interpréteur, puis créez un fichier .service dans /etc/systemd/system/. Déclarez le script dans ExecStart, rechargez systemd avec daemon-reload et activez le service avec systemctl enable.

Où placer un fichier de service systemd personnalisé ?

Un service système personnalisé se place généralement dans /etc/systemd/system/. Cet emplacement est conçu pour les unités administrées localement et évite de modifier directement les fichiers fournis par les paquets logiciels.

Comment empêcher un script de se lancer au démarrage ?

Exécutez sudo systemctl disable nom-du-service.service pour retirer l’activation au démarrage. Ajoutez sudo systemctl stop nom-du-service.service si vous souhaitez aussi arrêter le service immédiatement.

Comment relancer automatiquement un script après une erreur ?

Pour un script qui doit rester actif, ajoutez Restart=on-failure et un délai avec RestartSec=10 dans la section [Service]. Consultez les journaux avant d’activer cette reprise, car un redémarrage automatique ne corrige pas une erreur de configuration.

Pourquoi systemctl status indique-t-il inactive après l’exécution ?

Un service configuré avec Type=oneshot peut devenir inactif après avoir fini son action avec succès. Vérifiez le code de sortie et les messages via journalctl -u nom-du-service.service pour confirmer que le script a bien été exécuté.