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é !
opened 12:00AM - 08 Jun 17 UTC
closed 08:36PM - 28 Nov 22 UTC
scope:core
Hello,
if i read
```
$ git grep FD_SETSIZE
CMakeLists.txt: set(CMAK… E_${L}_FLAGS "${CMAKE_${L}_FLAGS} -DFD_SETSIZE=1024")
gtk/tr-prefs.c: w = new_spin_button (TR_KEY_peer_limit_per_torrent, core, 1, FD_SETSIZE, 5);
gtk/tr-prefs.c: w = new_spin_button (TR_KEY_peer_limit_global, core, 1, FD_SETSIZE, 5);
libtransmission/fdlimit.c: /* set the open-file limit to the largest safe size wrt FD_SETSIZE */
libtransmission/fdlimit.c: const int new_limit = MIN (limit.rlim_max, FD_SETSIZE);
qt/PrefsDialog.cc: #include <winsock2.h> // FD_SETSIZE
qt/PrefsDialog.cc: #include <sys/select.h> // FD_SETSIZE
qt/PrefsDialog.cc: ui.torrentPeerLimitSpin->setRange (1, FD_SETSIZE);
qt/PrefsDialog.cc: ui.globalPeerLimitSpin->setRange (1, FD_SETSIZE);
third-party/miniupnp/receivedata.c: n = select(FD_SETSIZE, &socketSet, NULL, NULL, &timeval);
```
you force the max number of file descriptors to 1024.
now, let's say i have a systems where i could run transmission with more than _just_ 1024 fds, wouldnt it be fantastic if i could specify it either as a configuration option (or using ulimit in the init script)?
is there any reason to hardcode this value at compile time and not make it dynamically changable by the users (unless you want to prevent to have them shot themselves in the foot, but that could happen anyway)
thanks for considering