Lancer automatiquement des programmes au démarrage du serveur (systemd et cron)

Relancer tous les services à la main après chaque redémarrage du serveur : cela prend du temps et finit toujours par mal tourner. Linux dispose d'un mécanisme prévu exactement pour cela. Dans ce guide, nous vous montrons comment lancer automatiquement vos propres applications, serveurs de jeu, bots ou scripts au démarrage du serveur.

Nous passons en revue deux méthodes : une unité de service systemd, la solution courante aujourd'hui, et la voie plus ancienne d'une entrée cron avec @reboot. Les deux fonctionnent indépendamment de la distribution, donc aussi bien sur Debian, Ubuntu, AlmaLinux que sur Rocky Linux.

systemd ou cron : quelle méthode choisir ?

systemd est le standard pour la gestion des services sur toutes les distributions Linux actuelles. Une entrée cron avec @reboot lance elle aussi votre application, mais elle ne sait rien faire de plus.

Pour tout ce qui doit tourner en permanence, l'unité systemd est le meilleur choix. L'entrée cron reste un dépannage rapide, réservé aux commandes simples à exécuter une seule fois.

Prérequis

• Un accès root à votre vServer ou serveur root via SSH.
• Un script de démarrage ou un programme qui se lance déjà proprement en ligne de commande. Testez-le d'abord à la main, avant de l'automatiser.
• Le chemin absolu vers ce script. Les chemins relatifs ne fonctionnent pas de façon fiable au démarrage du système.

Créer une unité de service systemd

Vos propres unités se placent dans /etc/systemd/system/ et portent l'extension .service. Créez le fichier :

nano /etc/systemd/system/monservice.service

Voici un squelette simple, directement utilisable :

[Unit]
Description=Mon propre service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=monutilisateur
WorkingDirectory=/opt/monservice
ExecStart=/bin/bash /opt/monservice/start.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Ce que signifie chaque ligne

• Description : le nom en clair qu'affiche systemctl status.
• After et Wants : le service ne démarre qu'une fois le réseau disponible. Cela rend inutile l'astuce du sleep que l'on connaît de cron.
• Type=simple : le programme reste au premier plan. Si votre script de démarrage bascule lui-même en arrière-plan, il vous faut à la place Type=forking et une directive PIDFile.
• User : l'utilisateur sous lequel le service tourne. Ne faites jamais tourner une application en root sans nécessité.
• WorkingDirectory : remplace le cd d'un script de démarrage.
• Restart=on-failure : systemd relance le service après un plantage. Avec Restart=always, il le relance également quand le programme se termine normalement.
• WantedBy=multi-user.target : garantit que le service est lancé avec le démarrage normal du système.

Activer et tester le service

Après chaque modification d'un fichier d'unité, systemd doit le relire. Vous activez ensuite le service pour le démarrage du système, puis vous le lancez immédiatement :

systemctl daemon-reload
systemctl enable --now monservice.service

Pour vérifier que tout tourne :

systemctl status monservice.service

Les sorties de l'application atterrissent dans le journal. La commande suivante vous permet de les suivre en direct, ce qui reste le moyen le plus rapide de diagnostiquer un problème :

journalctl -u monservice.service -f

Pour arrêter, redémarrer ou désactiver durablement le service :

systemctl stop monservice.service
systemctl restart monservice.service
systemctl disable monservice.service

Exemple : démarrer automatiquement un serveur TeamSpeak 3

Le script de démarrage fourni par TeamSpeak bascule lui-même en arrière-plan et crée un fichier PID. C'est donc bien Type=forking qu'il faut utiliser ici :

[Unit]
Description=TeamSpeak 3 Server
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
User=teamspeak
WorkingDirectory=/home/teamspeak
ExecStart=/home/teamspeak/ts3server_startscript.sh start
ExecStop=/home/teamspeak/ts3server_startscript.sh stop
PIDFile=/home/teamspeak/ts3server.pid
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

Adaptez le nom d'utilisateur et le répertoire à votre installation. Il est important que l'utilisateur indiqué soit réellement propriétaire du répertoire.

Exemple : serveur de jeu ou bot via un script de démarrage

Pour Minecraft, ARK, Arma 3, un serveur LinuxGSM ou un bot que vous avez écrit vous-même, la variante simple suffit en règle générale. Le service tourne au premier plan, systemd se charge de la surveillance et du redémarrage :

[Unit]
Description=Serveur de jeu
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=gameserver
WorkingDirectory=/home/gameserver/server
ExecStart=/bin/bash /home/gameserver/server/start.sh
Restart=always
RestartSec=15

[Install]
WantedBy=multi-user.target

Si plusieurs services démarrent en même temps et se ralentissent mutuellement, échelonnez le démarrage avec des valeurs différentes pour RestartSec, ou complétez After= avec le nom de l'unité qui doit tourner en premier.

Alternative : démarrage automatique via cron avec @reboot

Si vous souhaitez seulement exécuter une commande unique au démarrage et que vous n'avez pas besoin de surveillance, une entrée cron suffit. Définissez d'abord l'éditeur, puis ouvrez la crontab :

export VISUAL=nano; crontab -e

Ajoutez-y une ligne avec @reboot :

@reboot sleep 60 && cd /<DOSSIER-DU-SCRIPT>/ && bash <VOTRE-SCRIPT>.sh

Le @reboot fait en sorte que la commande soit exécutée une fois à chaque démarrage du système. La partie sleep 60 attend 60 secondes, le temps que le réseau et la base de données soient prêts. La commande se place ensuite dans le répertoire de votre script et le lance.

Voici un exemple pour un serveur vocal qui doit tourner sous son propre utilisateur :

@reboot sleep 45 && cd /home/<DOSSIER-TEAMSPEAK>/ && sudo -u <UTILISATEUR-TEAMSPEAK> bash ts3server_startscript.sh start

Si vous ajoutez plusieurs lignes, donnez à chacune une valeur sleep différente (au moins 45), pour que tous les services ne démarrent pas au même instant. La valeur s'exprime en secondes.

Erreurs fréquentes

• Le service ne démarre pas alors qu'il fonctionne à la main : il manque le plus souvent un chemin absolu. Dans une unité comme dans cron, la variable d'environnement PATH est très réduite, écrivez donc toujours /bin/bash /chemin/complet/script.sh.
• « Unit not found » juste après la création : vous avez oublié systemctl daemon-reload.
• Le service s'arrête aussitôt après son lancement : le programme bascule en arrière-plan. Utilisez Type=forking avec le PIDFile correspondant, ou lancez le programme en mode premier plan.
• Erreur de permissions au démarrage : l'utilisateur indiqué dans User= n'a pas le droit d'accéder au répertoire. Vérifiez le propriétaire avec ls -la.
• Rien ne tourne après le boot : le service a bien été démarré, mais pas activé. systemctl enable est l'étape qui l'inscrit durablement.

Pour finir, le meilleur test qui soit : redémarrez une fois le serveur avec reboot, puis vérifiez avec systemctl status que tous les services tournent comme prévu.