Closed jerryfreak closed 8 months ago
this seems to be somehow related to the manner in which rinst script installs
i wanted to install flood to see if i could reproduce the bug in an attempt to isolate the problem to rutorrent
the easiest way to install flood is the swizzin script, i installed a relatively light (for swizzin) install including nginx rtorrent transmission deluge qbittorrent rutorrent flood autodl vsftpd panel ffmpeg
to my surprise rutorrent installed from this package went beyond 6393 with flying colors. in fact i was able to take it out to nearly 11000 torrents with low resource usage, even while running rutorrent concurrently with the more resource-heavy flood (~25% CPU with both, and ~10% CPU with rutorrent alone), and about 5GB of the available 32GB of memory
the swizzin script uses the default 8.1.2 version of php in 22.04, not the 7.4 that is required to install rtinst on 20.04/22.04, perhaps the limitation is in php
The limitation you're facing could be a timeout in php execution or perhaps in the scgi socket somehow. This isn't really a problem with ruTorrent, but rather the way the rtinst script has configured the webserver and applications. As you have noted, swizzin doesn't show this behavior (and php7.4 is not to blame as swizzin works perfectly comparably under buster and bullseye which are using older versions of php)
You might consider comparing php.ini between swizzin and rtinst and the pool.d/www.conf files as well. There may be some differences here which explain the behavior. Additionally, the timeout may be on the webserver as well (i.e. nginx/apache timeouts).
If you still have access to the broken instance, you can check the network graph waterfall and see if any specific calls are timing out at oddly specific intervals (i.e. 10s, 20s, 30s, 60s). This will usually indicate something is closing the connection (the webserver or php timeouts) instead of letting it continue. I'd be willing to bet the issue is less the number of torrents, but rather that the one final torrent pushed it over the threshold and it started producing a reliable timeout
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Closing this off. The problem was the xml-rpc limitation for sending information. It was not set high enough. This has been resolved on both swizzin and docker-rtorrent-rutorrent by patching the rTorrent software.
Please complete the following tasks.
Tell us about your environment
bug is reproducible in all of the following combinations: web browser: chrome and firefox, repeatable in all browsers tried rutorrent 3.10 stable and 4.0 beta3 when either is installed via rtinst script PHP: 7.4 OS: ubuntu 20.04 and 22.04
Tell us how you installed ruTorrent
originally through rtinst script then updated to 4.0 via rutupgrade.
also tried stickz's custom code from here, to no avail _
Describe the bug
rtorrent/rutorrent is stable and uses little resources up to 6393 torrents in the list (most are non-active, i.e. they are checking in with trackers but not making peer connections)
upon adding the 6394th torrent rutorrent loses connection with rtorrent and rutorrent log displays the following error
"bad response from server: (500 [error,list])"
rutorrent is unable to list torrents until they are manually removed from session to bring the number in the list to 6393 or fewer
Steps to reproduce
Expected behavior
expected rutorrent to maintain functionality
Additional context
repeatable to the exact number of torrents in the list on multiple machines with multiple OSes and rtorrent/rutorrent versions