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é?
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
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.
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.
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.
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
Ç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é?
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
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.
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
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.
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é !
donc dans le lanceur de l’application dans ce cas.
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.
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.
ton transmission il est lancé comme un service?
car je viens de lire ça
/etc/systemd/system.conf (Pour les services systemd)
Ajoutez ces lignes :
DefaultLimitNOFILE=65535:524288
DefaultLimitNPROC=128000:256000
DefaultLimitSTACK=16384:32768
dans
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
Top ! Une bonne raison de pas trainer pour mettre a jour ! Merci à vous deux pour le temps que vous m’avez accordé, j’estime que mon problème est résolu !
1 J'aime
Si tu trouves une version de Raspberry Pi OS basée sur Trixie, je suis preneur.
Mais pour l’instant c’est toujours la version sur Debian 12 qui est proposée sur le site officiel, et rien d’autre.
c’est pas encore sortie mais la beta doit-être assez mature pour tester 