Offre Durée limitée : -10% sur tout le site avec le code WELCOME10
Elypse
Accueil

Créer un service systemd pour son serveur de jeu Linux : démarrage automatique et redémarrage sur crash

Mis à jour le 30 septembre 2026 10 min de lecture 11 sections

Votre serveur de jeu tourne en fond de tâche dans un terminal tmux, et à chaque reboot vous devez le relancer à la main. Un crash en pleine nuit reste sans réponse jusqu'au lendemain matin. Ce tutoriel vous explique comment créer un service systemd pour n'importe quel serveur de jeu Linux, afin qu'il démarre automatiquement au démarrage du VPS et se relance seul en cas de crash, sans aucune intervention manuelle. C'est la base pour administrer et configurer un serveur de jeu en production sur un serveur VPS Linux ou un serveur dédié.

Pourquoi utiliser systemd pour un serveur de jeu ?

systemd est le gestionnaire de services par défaut sur toutes les distributions Linux modernes (Ubuntu, Debian, Rocky Linux, Fedora, Arch). Il remplace les scripts init.d et les solutions artisanales comme nohup ou screen par un système robuste conçu pour administrer des services en production. Ses avantages pour un administrateur :

  • Démarrage automatique au boot du serveur VPS ou dédié, avant même que quiconque se connecte en SSH.
  • Redémarrage automatique sur crash avec un délai configurable, grâce à la directive Restart=on-failure.
  • Gestion centralisée des logs via journalctl, sans fichier de log custom à gérer, ni script shell de rotation.
  • Isolation des droits : le processus peut tourner sous un utilisateur dédié, sans droits root ni accès superutilisateur.
  • Contrôle des ressources : possibilité de limiter l'utilisation CPU et la consommation mémoire via les cgroups intégrés au noyau Linux.

Ces fonctionnalités s'appliquent aussi bien à un serveur FiveM, Minecraft, Rust ou tout autre daemon de jeu hébergé sur un VPS Linux ou un serveur dédié. Sur un serveur VPS administré en SSH, systemd est l'outil d'administration standard pour gérer les services et démons en production.

Prérequis

Avant de créer et configurer l'unit file sur votre serveur VPS ou serveur dédié, assurez-vous de disposer de :

  • Un VPS ou serveur dédié sous Linux (Ubuntu 22.04/24.04, Debian 12, Rocky Linux 9, etc.) accessible en SSH.
  • Un accès root ou sudo sur la ligne de commande SSH de l'administrateur.
  • Le binaire de votre serveur de jeu déjà installé et fonctionnel en lancement manuel depuis le terminal.
  • Un utilisateur Linux dédié (ici gameserver). Créez-le si nécessaire avec adduser --system --no-create-home gameserver. Un utilisateur dédié est indispensable pour isoler les droits du processus et éviter tout accès non autorisé aux fichiers système.

Si votre serveur de jeu dépend d'une base de données MySQL ou d'un autre service réseau démarré par systemd, vous pouvez l'indiquer dans la directive After= (voir ci-dessous). Ainsi le daemon de jeu attendra la disponibilité du service réseau avant de démarrer.

Structure d'un unit file systemd

Un fichier de service systemd est un fichier texte en syntaxe INI, placé dans /etc/systemd/system/. C'est là que les administrateurs placent leurs configurations de service personnalisées sur un serveur Linux. La conf d'un service standard comporte trois sections principales :

[Unit]
Description=Mon serveur de jeu
After=network.target

[Service]
Type=simple
User=gameserver
WorkingDirectory=/opt/gameserver
ExecStart=/opt/gameserver/start.sh
Restart=on-failure
RestartSec=10s

[Install]
WantedBy=multi-user.target
  • [Unit] : métadonnées et dépendances. After=network.target garantit que la carte réseau est configurée avant le lancement du jeu, ce qui est indispensable pour un serveur qui écoute sur un port réseau.
  • [Service] : comportement du processus daemon. Type=simple convient à la quasi-totalité des serveurs de jeu qui ne forkent pas en arrière-plan.
  • [Install] : configurations du démarrage automatique. WantedBy=multi-user.target active le service sur un serveur VPS sans interface graphique.

Les directives clés pour la fiabilité

Restart= et RestartSec=

Restart=on-failure demande à systemd de relancer le service uniquement si le processus se termine avec un code non nul (crash). Les arrêts propres via systemctl stop ne déclenchent pas de redémarrage. Cette directive est la base de la haute disponibilité d'un serveur de jeu en production.

RestartSec=10s impose un délai de 10 secondes entre le crash et le relancement. Ce délai est important pour éviter une boucle de redémarrages rapides en cas d'erreur persistante au démarrage : fichier de configurations manquant, port réseau déjà utilisé par un autre service, espace disque insuffisant sur le SSD, etc.

Pour une protection encore plus robuste, vous pouvez limiter le nombre de redémarrages avec :

StartLimitIntervalSec=120s
StartLimitBurst=3

Ces deux directives se placent dans la section [Unit] (pas dans [Service]) et empêchent une boucle infinie : après 3 crashes en moins de 120 secondes, systemd déclare le service en échec plutôt que de boucler indéfiniment sur le VPS.

User= et WorkingDirectory=

Faire tourner un serveur de jeu en root est inutile et risqué pour la sécurité du serveur VPS. User=gameserver assure que le daemon n'a pas de droits superutilisateur. WorkingDirectory= fixe le répertoire courant du processus, indispensable pour les serveurs qui cherchent leurs ressources en chemin relatif. Un administrateur utilise systématiquement ces deux directives pour un service en production.

Passer des variables d'environnement

Si votre serveur de jeu a besoin de variables d'environnement (clés d'API, adresses IP internes, chemins custom, paramètres réseau), ajoutez dans la section [Service] :

Environment="GAME_PORT=30120"
Environment="GAME_DATA=/opt/gameserver/data"

Pour les secrets, préférez EnvironmentFile=/etc/gameserver/env pointant vers un fichier lisible uniquement par root (chmod 600). C'est une bonne pratique de sécurité pour tout service en production hébergé sur un serveur VPS ou dédié, et évite d'exposer des informations sensibles dans les logs ou dans ps aux.

Limiter l'utilisation CPU et mémoire

systemd s'appuie sur les cgroups Linux pour contraindre les ressources d'un service daemon. Utile quand plusieurs serveurs de jeu cohabitent sur le même VPS Linux avec des ressources SSD et RAM partagées :

CPUQuota=80%
MemoryLimit=4G

Ces directives s'ajoutent dans la section [Service]. Elles évitent qu'un serveur de jeu monopolise l'ensemble du CPU ou sature la RAM au détriment des autres services présents sur la machine, comme un serveur web Nginx ou une instance de base de données.

Déclarer des dépendances réseau et services

Si votre serveur de jeu dépend d'un service réseau comme une base de données MySQL ou un serveur de cache démarré par systemd, utilisez After= et Requires= :

[Unit]
Description=Serveur FiveM GTA RP
After=network.target mysql.service
Requires=mysql.service

Avec Requires=, si le service MySQL s'arrête, systemd arrêtera automatiquement le daemon de jeu aussi. After= seul garantit seulement l'ordre de démarrage. Pour un serveur FiveM qui utilise une adresse IP et un port réseau spécifiques, cette configuration assure que la pile réseau et la base de données sont disponibles avant le lancement.

Exemple complet : service FiveM

Voici un unit file complet pour un serveur FiveM hébergé dans /opt/fivem sur un serveur VPS Linux :

[Unit]
Description=Serveur FiveM GTA RP
After=network.target
StartLimitIntervalSec=120s
StartLimitBurst=3

[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/opt/fivem
ExecStart=/opt/fivem/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fivem-server

[Install]
WantedBy=multi-user.target

Les directives StandardOutput=journal et SyslogIdentifier=fivem-server redirigent toute la sortie du daemon vers journald, consultable ensuite avec journalctl -u fivem-server -f. C'est nettement plus pratique qu'un fichier de log rotatif à gérer manuellement sur le serveur dédié ou VPS.

Exemple complet : service Minecraft

Pour un serveur Minecraft Paper ou Vanilla dans /opt/minecraft sur un VPS Linux :

[Unit]
Description=Serveur Minecraft Java
After=network.target
StartLimitIntervalSec=120s
StartLimitBurst=3

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms2G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=minecraft-server

[Install]
WantedBy=multi-user.target

Adaptez -Xms et -Xmx à la RAM disponible sur votre VPS. Si vous avez besoin d'aide pour dimensionner la mémoire, consultez notre guide sur la réduction de la consommation mémoire d'un serveur de jeu Linux.

Activer et démarrer le service

Une fois le fichier créé dans /etc/systemd/system/fivem-server.service, exécutez ces commandes depuis votre ligne de commande en tant que root ou avec sudo sur votre serveur VPS ou dédié :

# Recharger la configuration systemd pour prendre en compte le nouveau fichier
systemctl daemon-reload

# Activer le service (démarre au prochain boot du serveur)
systemctl enable fivem-server.service

# Démarrer le service immédiatement
systemctl start fivem-server.service

# Vérifier l'état du daemon
systemctl status fivem-server.service

La commande enable crée un lien symbolique dans le répertoire cible multi-user.target.wants/, ce qui déclenche le démarrage automatique à chaque boot. Si vous omettez enable, le daemon démarrera bien maintenant mais pas après un reboot du serveur VPS ou dédié.

Arrêt propre, backup et maintenance

Un arrêt propre est important avant de lancer des sauvegardes des données de jeu ou une mise à jour. Procédez toujours dans cet ordre : arrêtez le service daemon, lancez vos sauvegardes vers un stockage distant, puis appliquez la mise à jour. Pour stopper temporairement le serveur sans le désactiver au boot :

systemctl stop fivem-server.service

Pour désactiver le démarrage automatique tout en conservant la possibilité de le démarrer manuellement :

systemctl disable fivem-server.service

Pour redémarrer après une mise à jour des configurations :

systemctl restart fivem-server.service

Pour les mises à jour du serveur sans perte de données, consultez notre guide sur la mise à jour d'un serveur de jeu Linux. Concernant les backups, automatisez des exports réguliers de votre répertoire /opt/gameserver vers un stockage externe ou hors site, idéalement avant chaque mise à jour majeure du serveur VPS.

Consulter les logs et diagnostiquer un crash

systemd stocke tous les logs du daemon dans journald. Les commandes essentielles depuis la ligne de commande SSH :

# Afficher les 100 dernières lignes et suivre en temps réel
journalctl -u fivem-server.service -n 100 -f

# Afficher les logs depuis le dernier boot uniquement
journalctl -u fivem-server.service -b

# Afficher les logs entre deux dates
journalctl -u fivem-server.service --since "2026-09-28 18:00" --until "2026-09-28 19:00"

Pour connaître le nombre de redémarrages depuis l'activation du daemon :

systemctl show fivem-server.service -p NRestarts

Pour une analyse approfondie des journaux système du serveur VPS, consultez notre guide sur l'analyse des logs avec journalctl.

Dépannage des problèmes courants

Le service ne démarre pas

Si systemctl status affiche failed, consultez les logs récents du daemon :

journalctl -u fivem-server.service -n 50 --no-pager

Causes fréquentes : chemin ExecStart incorrect, script non exécutable (chmod +x /opt/fivem/run.sh), ou utilisateur gameserver sans droits de lecture sur le répertoire. Vérifiez aussi que le pare-feu (UFW ou nftables) autorise bien le port de jeu sur votre VPS Linux. Un pare-feu mal configuré peut silencieusement bloquer les connexions entrantes sans générer d'erreur côté service. Pour configurer votre pare-feu VPS, consultez notre guide sur l'ouverture des ports avec UFW.

Boucle de redémarrage

Si le service crashe en boucle et que systemctl status affiche start-limit-hit, réinitialisez le compteur de crashes :

systemctl reset-failed fivem-server.service
systemctl start fivem-server.service

Puis analysez la cause racine dans les logs avant de relancer le daemon. Un espace disque plein sur le SSD ou une RAM saturée sont des causes fréquentes de crash en boucle sur un serveur VPS Linux.

Problèmes de permissions

Si le service tourne sous un utilisateur dédié mais que les fichiers de configuration et données appartiennent à root, corrigez les permissions :

chown -R gameserver:gameserver /opt/gameserver

Vérifiez aussi les droits d'exécution sur le script de lancement (ls -la /opt/gameserver/start.sh) et les droits d'écriture sur les répertoires de logs et de données. Une erreur de permissions est souvent la cause principale d'un service qui échoue au démarrage sans message d'erreur explicite.

Aller plus loin

Un service systemd bien configuré résout la majorité des problèmes de disponibilité d'un serveur de jeu hébergé sur un VPS Linux ou serveur dédié. Pour compléter votre infrastructure d'administration :

Vous souhaitez héberger votre serveur de jeu sur une infrastructure fiable, avec un VPS Linux SSD, un réseau 1 Gbit/s et une disponibilité garantie par SLA ?

Voir les offres VPS Linux ElypseCloud

À voir aussi

Analyser les logs avec journalctl Détecter un serveur hors service Mettre à jour sans perdre sa config Réduire la consommation mémoire Sessions persistantes avec tmux Analyser les échecs SSH