Too many open files

Support Debian
, ,
Tags: #<Tag:0x00007f9c84cbf930> #<Tag:0x00007f9c84cbf7c8> #<Tag:0x00007f9c84cbf660>
#1

Salut !

J’ai un soucis avec la limite d’ouverture de fichiers sur une debian 12. J’ai tenté plusieurs modifs, dont une dans /etc/systemd/system.conf qui semble prise en compte, mais le process (transmission-daemon) remet la limite soft à 1024 après quelques dizaines de secondes de fonctionnement. J’ai également modifié /etc/security/limits.conf, /etc/sysctl.conf (avec fs.file-max) et /etc/systemd/user.conf (mais ça doit être pour les comptes user et pas les comptes system si je comprend bien).Si une personne à une idée ça m’aiderais beaucoup. Merci !

#2

Bonjour,

  1. Que voulais tu faire au départ? et pourquoi?
  2. Quelles sont en détail les modifications que tu as faites (quels fichiers, quelles options et quelles valeurs pour ces options)
  3. as-tu des logs sur ce qui se passe ?

Normalement il n’y a pas de raison d’utiliser systemd pour modifier cette valeur.
Soit c’est avec sysctl pour le global, soit c’est avec ulimit pour le détail.

Il est important de garder en tête que le changement du nombre de fichiers ouverts par un seul processus aura des impacts de performances, voire sur la stabilité du système. D’où l’importance de bien définir le besoin réel d’une telle modification.

#3

Salut !
C’est un raspberry qui fait juste tourner un transmission qui accède a ses fichiers sur un nas. J’ai besoin d’augmenter la limite car depuis que j’ai dépassé les 800 fichiers en seed, j’ai des erreurs dans transmission. Exemple de message d’erreur en log : Couldn’t create socket: Too many open files (fdlimit.c:683). Parfois ça dit juste « too many open files »

J’ai fait différents tests, et quand je change la limite avec prlimit ou ulimit -n ça résoud bien le problème, donc je cherche comment fixer ces valeurs.
Au début j’ai modifié sysctl.conf avec
fs.file-max = 16384
mais aucun effet

Dans limits.conf, j’ai ajouté ça
* hard nofile 8192
* soft nofile 4096
j’avais essayé en mettant transmission-daemon à la place du wildcard, mais ça change rien

Après j’ai essayé avec user.conf et system.conf ou j’ai ajouté
DefaultLimitNOFILE=4096:524288
ça je le vois pris en compte quand transmission-daemon démarre, mais après une dizaine de secondes, le 4096 retourne à 1024 (mais pas le 524288).

Donc je la refixe à la main avec
prlimit --nofile=4096:8192 -p pgrep -f transmission-daemon
(normalement y’a des crochets autour du pgrep… mais l’éditeur les enlève)
et ça tien jusqu’au redémarrage.

#4

Il vaut mieux créer un fichier dans /etc/sysctl.conf.d.
Ensuite, c’est étrange que aies eu besoin de faire ça.
te rapelles-tu de la valeur originelle de cette variable? (tu pouvais l’avoir avec sysctl -a | grep -i file-max).
Sous mon PC j’ai une valeur de 9223372036854775807.
Que tu sois bloqué à 800 fichiers me parait un peu lunaire.
Quelqu’un aurait-il le moyen de vérifier ça sur un raspberry pas trop bidouillé?

#5

Oui, de base la valeur de fs.file-max est bien celle que tu indique, donc je vais virer cette modif dans sysctl.conf car elle diminue la valeur pour rien. Mais c’est la limite appliqué à l’utilisateur qui doit primer, et de base, prlimit me dit quelles sont à 1024 en soft, 1048576 en hard. Donc c’est cette limite soft qui pose problème

#6

donc ca n’aurait pas du bloquer à 800 fichiers.
Les 1024 c’est par process. Et si le process grimpe au dessus ca va être la hard limit qui va faire l’arrêt.

#7

Pourtant j’ai plus d’erreur quand je passe de 1024 à 2048. C’est ~800, + ses fichiers de conf, + les fichiers en cours de partage, donc le process doit bien atteindre les 1024 fichiers ouverts pas transmission-daemon seul. Aussi, j’ai vu l’erreur apparaître de plus en plus fréquemment a mesure que j’ajoutais des fichiers (ça a du commencer vers les 700). Bref, je suis a peu près sur de savoir quel paramètre changer pour régler le problème, mon problème c’est de faire en sorte que ce réglage soit définitif en l’inscrivant dans la config de l’OS, et pas devoir le changer à la main à chaque redémarrage.

#8

le soft paramètre est modifiable par l’ user, le hard uniquement par root si on utilise la commande ulimit.

Sinon il faut créer un fichier /etc/security/limits.d/10-ulimits.conf, avec

# limite soft du nombre maximum de fichiers ouverts pour l'utilisateur toto
toto       soft    nofile          4096

toto est l’utilisateur qui est concerné. Il vaut mieux éviter de le modifier pour l’ensemble du système.

Et c’est pris en compte au prochain redémarrage normalement.

attention, dans ce fichier, le wildward ne peux pas s’appliquer à root, il faut faire une ligne spécifique.

#9

J’ai déjà une ligne semblable dans limits.conf et ça marche pas (ou du moins c’est remis à 1024 après démarrage du processus).
‹ * soft nofile 4096 ›

Et j’ai aussi essayé avec le nom de l’user « debian-transmission » a la place du wildcard

#10

Ça doit vouloir dire que tu as deux fichiers de configuration qui semble se contredire.
Tu as un user système debian-transmission poru ce processus?

Comment est-il lancé?

#11

Salut !

L’erreur « Too many open files » concerne le nombre de descripteurs de fichiers et donc aussi les sockets.
Typiquement, une socket est ouverte par client qui se connecte au programme ou par machine à laquelle notre programme se connecte.

Par exemple, avec un programme qui tente de créer des sockets en boucle :

$ ulimit -S -n 10
$ ./sockets
socker number 0 successfully created
socker number 1 successfully created
socker number 2 successfully created
socker number 3 successfully created
socker number 4 successfully created
socker number 5 successfully created
socker number 6 successfully created
socket creation: Too many open files
press ENTER to exit
$

Le nombre de fichiers partagés n’est donc peut-être pas la cause principale de l’erreur.

–
AnonymousCoward

1 J'aime
#12

Y’a pas d’autres fichiers dans limits.d

Oui y’a un user debian-transmission, ps me montre bien que c’est lui qui est lié au processus. Transmission est lancé par un script depuis openvpn.

#13

merci pour l’info. Ça doit s’ajouter au nombre de fichiers oui. Mais la cause de l’erreur c’est cette foutu valeur soft qui veut pas garder le réglage que je lui donne. Mon problème est de trouver pourquoi elle reprend une valeur de 1024 après quelques dizaines de secondes, alors qu’au début elle est bien fixé à la valeur indiqué dans /etc/sytemd/system.conf

#14

plutot que de modifier le fichier /etc/systemd/system.conf qui est valable sur l’ensemble du système, ce qui n’est aps une bonne idée, modifie soit le fichier de conf limits comme je te l’aie indiqué, ou bien modifie le lancement de ton process.
Dans le lanceur ajoute la mise à la valeur voulue de ulimit -Sn.

#15

Je viens de trouver ça. Il semble que cette limite soit codé en dur dans transmission, et pas moyen de la changer depuis sa conf. Donc pas le choix que de faire une bidouille depuis un script qui va vérifier la valeur et la changer si besoin… grrr…

Merci pour votre aide ! D’en discuter avec d’autres m’a bien aidé !

#16

donc dans le lanceur de l’application dans ce cas.

#17

c’est quoi que tu appel le lanceur de l’application ? j’ai déjà essayé depuis le script openvpn qui démarre transmission, mais il me dit qu’il a pas les droits pour le faire (alors que c’est root qui le lance). J’ai essayé dans un autre script qui vérifie périodiquement que transmission est bien lancé, et redémarre le tout si besoin, j’espère que ça marchera.

#18

attention quand tu fais la commande ulimit -Sn 2048, c’est le user de l’environnement courant qui est pris en compte et qui modifie pour lui-même.

Si c’est root, et s’il n’y a pas de ligne root dans les fichiers de conf, alors tu ne peux pas modifier à la volée. Il faut que la ligne de l’utilisateur concerné soit dans /etc/security/limits.d je pense.

#19

ton transmission il est lancé comme un service?
car je viens de lire ça

:two: /etc/systemd/system.conf (Pour les services systemd)

Ajoutez ces lignes :

DefaultLimitNOFILE=65535:524288
DefaultLimitNPROC=128000:256000
DefaultLimitSTACK=16384:32768

dans

#20

Grâce au lien posté ci-dessus , on peut tomber sur celui-ci : GitHub - Lift 1024 open files limit (switch to curl polling API)

Cela explique pourquoi le logiciel Transmission lui-même reconfigurait la limite du nombre de descripteurs de fichiers à 1024. C’est le comportement observé ci-dessus.

La solution serait de mettre à jour Raspberry Pi OS (basé sur Debian) pour bénéficier de Transmission dans une version 4.0.0-beta.1 ou ultérieure.
C’est à dire d’avoir un Raspberry Pi OS basé sur Debian Trixie.

On peut voir les versions de Transmission pour les version de Debian ici : packages.debian.org - transmission

On peut voir que le changelog pour Transmission 4.0.0-beta.1 mentionne la suppression de la limite à 1024 descripteurs de fichiers :
release 4.0.0-beta.1

–
AnonymousCoward

1 J'aime