Correction de l'erreur « Trop de fichiers ouverts » de Matrix Synapse sur systemd

Matrix Synapse peut démarrer normalement puis cesser d'accepter les connexions, afficher le message « Trop de fichiers ouverts » ou sembler bloqué en raison d'une charge importante. Sur une installation systemd, il convient de vérifier en premier lieu la limite de descripteurs de fichiers héritée par le processus Synapse en cours d'exécution. Modifier les ulimitlimites du shell ou un fichier PAM n'a généralement aucun impact sur la limite d'un service lancé par systemd.

Les étapes ci-dessous s'appliquent à un système Linux hôte où Synapse est exécuté en tant que service systemd. L'unité peut porter un nom matrix-synapse.servicespécifique matrix-synapse@.serviceau paquet. Vérifiez le nom réel de l'unité avant de copier les commandes. Si Synapse est exécuté dans un conteneur Docker, Kubernetes ou autre, consultez la section correspondante ci-dessous.

Que signifie « Trop de fichiers ouverts » ?

Linux impose à chaque processus une limite de descripteurs de fichiers ouverts. Un descripteur peut faire référence à un fichier, un socket, un tube ou toute autre ressource ; les connexions réseau consomment donc également des descripteurs. Lorsqu'un processus atteint sa limite logicielle, toute tentative d'ouverture ou d'acceptation d'un autre descripteur peut échouer EMFILE. Linux dispose également d'une limite distincte pour la table des fichiers système : son épuisement peut entraîner une erreur ENFILE. Augmenter la limite d'un service Synapse ne résoudra pas une pénurie à l'échelle du système.

La FAQ officielle d'administration de Synapse indique qu'une activité de connexion et de fédération élevée peut consommer de nombreux descripteurs de fichiers et que leur saturation peut empêcher le serveur d'accepter de nouvelles connexions TCP. Elle recommande d'augmenter la limite à au moins 4 096 connexions par défaut, par exemple 1 024 ou 256. Cette valeur doit être considérée comme un seuil minimal de dépannage pour la situation décrite, et non comme une recommandation universelle pour tous les serveurs domestiques. Commencez par vérifier la limite effective et l'utilisation réelle.

La documentation de Linux relative aux fonctions `getrlimit` et `prlimit` décrit les limites logicielles et matérielles par processus. Synapse propose également une soft_file_limitoption ; la documentation de configuration de Synapse indique une valeur par défaut de zéro, ce qui signifie que Synapse définira sa limite logicielle sur la limite matérielle qu'il peut utiliser.

1. Vérifiez l'unité et diagnostiquez la panne.

Commencez par identifier le nom du service. Sur de nombreuses installations de paquets, il s'agit de « service » matrix-synapse.service, mais ne présumez pas de ce nom si votre installation utilise une unité ou des workers personnalisés.

systemctl list-units --type=service --all | grep -i synapse
systemctl status matrix-synapse.service --no-pager
journalctl -u matrix-synapse.service --since "30 minutes ago" --no-pager

Recherchez l'erreur exacte, l'heure à laquelle elle a commencé et si elle survient lors d'un pic de trafic, d'une activité de fédération ou d'un redémarrage. Ensuite, examinez la limite actuellement signalée par systemd :

systemctl show matrix-synapse.service -p LimitNOFILE -p MainPID

LimitNOFILECette commande affiche la limite configurée du gestionnaire de services ; elle ne correspond pas au nombre de descripteurs actuellement ouverts. Une commande shell telle que ` ulimit -nls` ne fait que signaler la limite du shell courant et ne constitue pas une preuve de la limite du service.

2. Augmentez la limite du service systemd avec un fichier de configuration.

Utilisez un module systemd pour que les mises à jour de paquets n'aient pas à modifier le fichier d'unité du fournisseur. La valeur suivante est un exemple et ne constitue pas une solution idéale garantie pour tous les serveurs. Choisissez une limite supérieure à la consommation maximale observée et vérifiez la compatibilité des applications et des dépendances avant de définir une valeur anormalement élevée.

sudo systemctl edit matrix-synapse.service

Ajoutez ceci sous le nouveau module complémentaire de l'éditeur :

[Service]
LimitNOFILE=65536

Enregistrez et quittez, puis rechargez systemd et redémarrez Synapse pendant une fenêtre de maintenance appropriée :

sudo systemctl daemon-reload
sudo systemctl restart matrix-synapse.service
systemctl show matrix-synapse.service -p LimitNOFILE

Une seule LimitNOFILEvaleur définit à la fois la limite souple et la limite stricte du service dans systemd. La documentation de systemd autorise également une soft:hardpaire de limites. La limite souple ne peut pas dépasser la limite stricte. Avant de choisir une valeur très élevée, consultez la documentation de systemd.exec , qui signale des problèmes de compatibilité pour les programmes utilisant l'ancienne select(2)interface avec des descripteurs supérieurs à 1 023. Ne présumez pas que toutes les bibliothèques ou tous les plugins de votre environnement prennent en charge n'importe quelle limite.

3. Vérifiez les paramètres et les services de travail de Synapse.

Si votre configuration Synapse définit explicitement soft_file_limitune valeur faible, le paramètre de l'application peut maintenir la limite logicielle en dessous du plafond de systemd. Recherchez cette clé dans les fichiers de configuration actifs et la configuration incluse. Supprimez toute substitution inutile ou définissez-la délibérément ; la valeur par défaut documentée de zéro demande à Synapse d'augmenter sa limite logicielle jusqu'à la limite matérielle disponible.

Dans un déploiement multiprocessus, chaque processus de travail est distinct et peut être lancé par une unité ou une instance de modèle séparée. Augmenter la limite du service principal ne garantit pas automatiquement que chaque processus de travail bénéficie de la limite prévue. Examinez les noms réels des unités de travail systemctl list-units, puis appliquez et vérifiez le composant approprié pour chaque service qui en a besoin.

De même, les paramètres de configuration /etc/security/limits.confd'un shell de connexion ulimitne régissent généralement pas un service système lancé directement par systemd. Dans ce cas, modifiez la limite de ressources de l'unité et vérifiez-la sur le processus effectivement démarré par systemd.

4. Si Synapse s'exécute dans un conteneur

Une substitution systemd au niveau de l'hôte pour un service différent ne modifie pas automatiquement la limite de descripteurs de fichiers d'un conteneur. Configurez l'environnement d'exécution ou la couche d'orchestration du conteneur. Pour Docker Compose, la définition de service prend en charge les conteneursulimits ; voici un exemple :

services:
  synapse:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

Ce nombre est donné à titre indicatif ; ajustez-le en fonction de l'utilisation et des limites de l'hôte. La documentation du service Docker Compose décrit ce ulimitsparamètre. Depuis Docker Engine 29, les notes de version de Docker indiquent une modification de la limite nofile par défaut associée à containerd 2.1.5 : les conteneurs peuvent désormais recevoir 1 024 au lieu des 1 048 576 précédents. Si le problème est apparu après une mise à niveau d'Engine, vérifiez la limite effective des conteneurs et définissez explicitement la limite ulimit nécessaire dans la configuration du déploiement. Consultez les notes de version de Docker Engine 29 et la documentation de la commande docker run .

5. Vérifiez la limite du processus Synapse en cours d'exécution

Après le redémarrage, vérifiez la limite au niveau du processus, et pas seulement la configuration de systemd. Obtenez le PID principal et examinez ses limites signalées par le noyau :

PID=$(systemctl show --property=MainPID --value matrix-synapse.service)
grep "Max open files" "/proc/$PID/limits"
find "/proc/$PID/fd" -mindepth 1 -maxdepth 1 | wc -l

Si le PID principal est nul ou appartient à un wrapper plutôt qu'à Synapse, identifiez le processus Synapse dans le cgroup du service et examinez son PID. Le nombre de descripteurs est un instantané ; refaites la mesure lors d'une charge représentative. Vérifiez que le nombre maximal de fichiers ouverts correspond à vos limites souples et strictes, que ce nombre reste largement inférieur à la limite souple et que le journal ne signale plus l'erreur.

Si le nombre de requêtes continue d'augmenter jusqu'à atteindre le nouveau plafond, la limite ne fait peut-être que repousser l'échéance. La FAQ de Synapse indique que les requêtes bloquées ou lentes peuvent être pertinentes lors de l'analyse d'une saturation des descripteurs de fichiers. Il est conseillé d'examiner les journaux et le traitement des requêtes environnants, de comparer le nombre de descripteurs au fil du temps et de rechercher une éventuelle fuite ou des connexions anormalement persistantes plutôt que d'augmenter la limite sans discernement.

Quand augmenter la limite par service ne suffit pas

Si les journaux signalent une erreur de saturation de la table de fichiers système ENFILE, examinez l'utilisation globale de l'hôte et les autres services ; une LimitNOFILEmodification par service n'augmentera pas la capacité globale du noyau. Évitez de modifier les limites globales du noyau sans avoir confirmé l'erreur et compris l'impact sur l'hôte. Si la limite signalée du service reste faible après l'ajout d'une ressource, exécutez la commande systemctl cat matrix-synapse.servicepour confirmer que la ressource est chargée, vérifiez le nom de l'unité, rechargez systemd et redémarrez l'unité concernée.

Auto-évaluation rapide

• Avez-vous identifié l'unité ou le conteneur Synapse exact qui enregistre l'erreur ?
• Le rapport indique-t-il systemctl showla limite prévue pour cette unité ?
• Affiche-t- il /proc/<Synapse-PID>/limitsles limites logicielles et matérielles prévues après le redémarrage ?
• Le nombre de descripteurs est-il inférieur à la limite souple sous une charge de pointe normale ?
• Les paramètres des unités de travail et des conteneurs sont-ils vérifiés séparément le cas échéant ?
• L'erreur a-t-elle disparu ou l'utilisation continue-t-elle de croître jusqu'à la nouvelle limite ?

Si tous les contrôles au niveau du processus sont concluants et que l'erreur a cessé lors d'un trafic représentatif, la modification de la limite par systemd est efficace. Si les descripteurs continuent de s'accumuler ou si le système signale une pénurie globale, il convient de poursuivre l'investigation de la source plutôt que de considérer une limite plus élevée comme une solution définitive.

Sources

• FAQ sur l'administration de Synapse : épuisement des descripteurs de fichiers
• Référence de configuration Synapse : soft_file_limit
• Manuel de systemd.exec : limites des ressources du service
• Manuel Linux : getrlimit et prlimit
• Notes de version de Docker Engine 29