Augmenter la limite de fichiers ouverts d’un serveur de jeu Linux

Un serveur de jeu Linux peut afficher Too many open files alors que le disque, la mémoire RAM et le processeur semblent encore disponibles. Cette erreur signifie que le processus a atteint une limite de descripteurs de fichiers. Les descripteurs servent notamment aux fichiers, aux sockets réseau et aux journaux ouverts par le serveur.

Ce guide explique comment mesurer la limite réellement appliquée, l’augmenter pour un service systemd et vérifier le résultat sans modifier toute la machine inutilement. La méthode convient à un serveur de jeu administré sur un VPS Linux, une machine virtuelle Ubuntu ou Debian, ou sur un serveur dédié.

Reconnaître l’erreur Too many open files

Les symptômes les plus fréquents sont des connexions refusées, des fichiers de configuration impossibles à ouvrir, des erreurs dans les logs ou un service qui fonctionne après redémarrage puis échoue à nouveau sous charge. Le message peut venir du jeu, d’un proxy, d’un conteneur ou d’un composant de supervision.

Ne modifiez pas la limite au hasard. Commencez par identifier le processus concerné et vérifiez sa limite effective. La valeur de votre session SSH n’est pas forcément celle du service lancé par systemd, Docker ou un panneau de contrôle.

La limite de fichiers est différente de l’espace disque, de la bande passante et de la mémoire disponible sur le VPS. Un serveur virtuel peut avoir encore de la RAM et des SSD disponibles tout en refusant une nouvelle socket réseau parce que son processus a atteint nofile.

Vérifier les limites de la session et du processus

Dans une session shell, lancez :

ulimit -n
ulimit -Hn

La première commande affiche la limite souple, utilisée par défaut par les programmes lancés dans cette session. La seconde affiche la limite stricte, qui borne la limite souple. Pour un service déjà démarré, recherchez son PID puis consultez le fichier de limites :

systemctl status nom-du-service
pidof nom-du-binaire
cat /proc/PID/limits | grep -i "open files"

Remplacez PID par le numéro retourné par pidof. La ligne Max open files présente deux valeurs, la limite souple puis la limite stricte. C’est cette information qui permet de confirmer que le réglage appliqué au processus est bien celui attendu.

Compter les descripteurs ouverts

Une limite élevée ne corrige pas une fuite de descripteurs. Comparez la consommation actuelle avec la limite :

ls /proc/PID/fd | wc -l
cat /proc/PID/limits | grep -i "open files"

Pour obtenir une vue plus détaillée, lsof -p PID liste les fichiers et sockets ouverts si l’outil est installé. Repérez une croissance continue, des milliers de journaux identiques ou des connexions qui ne sont jamais libérées. Dans ce cas, cherchez d’abord la cause dans le serveur de jeu, un plugin, un proxy ou un script avant d’augmenter durablement la limite.

Sur un VPS, vérifiez aussi les ressources voisines : utilisation CPU, RAM, espace de stockage, inodes et état du firewall. Une saturation générale peut produire d’autres erreurs en parallèle, mais elle ne change pas la valeur de LimitNOFILE du service.

Relier la limite aux ressources du serveur

La limite de fichiers se règle au niveau du système d’exploitation, mais l’environnement d’hébergement reste important. Sur un VPS, la virtualisation partage un serveur physique entre plusieurs machines virtuelles. Vérifiez la capacité des processeurs, la RAM, l’espace disque SSD, la bande passante et la présence d’une adresse IP adaptée à votre usage. Un serveur dédié fournit des ressources physiques réservées, tandis qu’un serveur VPS privilégie une mise en service souple.

Une offre VPS cloud peut proposer une machine virtuelle redimensionnable, mais le changement de formule ne modifie pas automatiquement la limite du service. Quand vous comparez plusieurs configurations, vérifiez l’emplacement du data center, la redondance annoncée, les sauvegardes et les outils de monitoring au lieu de regarder uniquement le nombre de vCPU.

L’accès root, un panel d’administration ou un outil de déploiement peuvent changer la façon dont le serveur démarre. Notez la distribution, le gestionnaire de service, les règles du firewall et la procédure de backup avant de modifier nofile. Ces informations évitent de corriger la mauvaise instance ou de perdre le réglage lors d’une reconstruction du serveur virtuel.

Augmenter la limite d’un service systemd

Pour un serveur lancé par systemd, créez un remplacement local avec :

sudo systemctl edit nom-du-service

Dans l’éditeur, ajoutez uniquement :

[Service]
LimitNOFILE=65535

Enregistrez, puis rechargez la configuration et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart nom-du-service
sudo systemctl status nom-du-service

Le nombre 65535 est un exemple de plafond technique, pas une recommandation universelle. Choisissez une valeur cohérente avec le logiciel, la charge attendue et la limite globale du système. Après le redémarrage, contrôlez la valeur réellement reçue :

PID=$(systemctl show -p MainPID --value nom-du-service)
sudo cat /proc/$PID/limits | grep -i "open files"

Cas d’un serveur dans Docker

Si le jeu tourne dans un conteneur, une modification faite uniquement dans votre shell hôte ne suffit pas. Vérifiez la limite du processus dans le conteneur et définissez la limite au lancement, par exemple :

docker run --ulimit nofile=65535:65535 image-du-serveur

Avec Compose, le réglage dépend de la version et du moteur utilisé. Après recréation du conteneur, vérifiez la limite depuis l’environnement qui exécute réellement le serveur. N’oubliez pas de conserver ce réglage dans votre fichier de déploiement afin qu’une nouvelle création ne le perde pas.

Vérifier après la modification

Un contrôle complet comporte quatre étapes :

• confirmer que le service est actif avec systemctl is-active nom-du-service ;
• relire /proc/PID/limits pour le bon processus ;
• consulter les dernières erreurs avec journalctl -u nom-du-service -n 100 --no-pager ;
• observer le nombre de descripteurs pendant une période de charge représentative.

Un tableau de supervision peut suivre le CPU, la RAM, le stockage SSD, les connexions réseau et les descripteurs ouverts. Il permet de distinguer une limite de processus d’un manque de ressources du serveur virtuel ou d’un problème de configuration réseau.

Si l’erreur revient, comparez la progression du compteur avec les connexions, les fichiers temporaires et les logs. Une limite plus haute doit donner du temps au diagnostic, elle ne remplace pas une correction du logiciel ou une rotation des journaux.

Éviter les erreurs courantes

• Ne modifiez pas seulement ulimit dans votre session SSH si le serveur démarre comme service.
• Ne confondez pas limite souple et limite stricte.
• Ne redémarrez pas uniquement le jeu sans vérifier le processus réellement utilisé par le gestionnaire.
• Ne copiez pas une valeur extrême sans mesurer la consommation et la capacité de la machine.
• Ne masquez pas une fuite de descripteurs en augmentant la limite à chaque incident.

Documentez le nom exact du service, sa méthode de démarrage, son système Ubuntu ou Debian et le réglage appliqué. Cette documentation est particulièrement utile lors d’une migration vers un autre VPS ou hébergeur.

Avant toute intervention importante, prévoyez une sauvegarde de la configuration et un accès de secours. Pour compléter votre préparation, consultez aussi notre guide sur la sécurisation initiale d’un serveur dédié et celui consacré aux sauvegardes d’un serveur dédié.