New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rutorrent UI is not showing up but "loading" #281
Comments
looks like it fixed itself after awhile somehow |
I have a similar issue. Since last update 4 days ago, rutorrent won't load anymore (or at least I believe it is since the last update). It leads to rtorrent become unhealthy and stops seeding. Closing rutorrent helps rtorrent to recover after a couple of minutes. When rutorrent is not started or closed, rtorrent seeds properly. I have tried older tags like 4.2.9-0.9.8-0.13.8 and 4.0-0.9.8-0.13.8 but it didn't help. I am running this on Synology with 32GB of RAM. I tried to stop all other containers, down to 4 as shown in the docker info below, thinking it could have been a resources problem but it didn't help. docker info
Compose
The latest entry in rutorrent.log is from 2 months ago. docker logs as soon as rutorrent is kicked in
Radarr and Sonarr, both querying port 8000 on a regular basis, report successful connection when rutorrent is not opened. However they time out when rutorrent is started:
I am not sure where to go next. Any help would be greatly appreciated! |
I've added I have also added a couple of new env variables but it didn't help:
|
Ive been seeing a similar issue, where rutorrent is unable to connect to rtorrent for quite a while, before it graduates to taking several minutes to load before failing, and eventually ending in a state where rutorrent loads, but all plugins fail to load and almost all torrents have tracker time out errors. |
I am still facing the issue. I let the container run for a week without interacting with rutorrent at all hoping time would help (as it did for OP) but sadly it did not. Any pointers would be really appreciated. |
@tofkentof @wkpatrick Are you using torrents with UDP trackers by any chance? |
@stickz in my .rtorrent.rc, What is your reasoning? I'm curious :) Jut to confirm that my problem has been happening for over a month. It impacts only rutorrent. rtorrent behind works fine and seeds properly everything. |
rTorrent has known issues with UDP trackers. This docker image does not implement UDNS. I'm trying to figure out the best solution for the problem. If your rTorrent software is timing out after 5 minutes and crashing this problem can be easily resolved with a patch to the docker container. How many torrents approximately are you running? |
Also please try docker edge. The author just merged my pull request with stability patches which could resolve this problem. #286 |
@stickz I planned to cut a release with your patches. I was thinking of this kind of semantic for versioning:
WDYT? |
@crazy-max sounds good to me. I will be submitting more patches in the future. |
Something like 15k.
I've pulled the new image from the tag edge but now rtorrent stays in an unhealthy state. From rtorrent logs, I can see for each torrent:
It represents over 140k line of logs since rtorrent was restarted few hours ago. From docker logs, i can see that the radarr and sonarr time out when trying to connect to rtorrent:
I did not have this problem when switching back and forth from different tags (4.0, 4.2.9, ...). I am not sure what rtorrent is doing at the moment. I am tempted to leave like that until tomorrow morning and if it doesn't revert to an healthy state. If not I'll roll back to tag latest and see if that helps. |
Yes, please try tag latest. If that doesn't work, I'll submit a pull request for the tracker scrape patch to the docker container. |
I reverted to latest but it did not help. However symptoms seem to change (my assumption).
I've got 16379 lines like this, all with a different hash, which seems to be the number of torrents I've got in rutorrent currently. I suppose all torrents were parsed and tried to be announced to the trackers but timed out. Although I would expect to see those same lines again with the next reannouncement but rtorrent.log has not been populated for the last 90 minutes. |
Maybe rate-limit? |
Sorry what do you mean by rate limit? If you mean upload limit, I do not specify any. Should I post my .rtorrent.rc file here? |
@crazy-max @tofkentof Nope, the problem probably related to #288. This should resolve the tracker issues. |
@tofkentof Perhaps try edge now? We just pushed #288, which should resolve the tracker problem. |
just to be sure should I use edge or master? #288 has been merged to master already however no new build was released. |
Try edge. It is the latest commit from master. It's not required to tag a release, to use the changes. |
sI've been running on edge for pretty much the last 24 hours. I'm a bit worried because I cannot get back to a state where I was before my initial post: rtorrent was running fine and seeding consistently when rutorrent was not running. I'm clueless. I was considering creating a complete new blank container from latest (or edge) using a new volume for /data (for example:
Although I'm not sure if I need to restore other files for this scenario to work. My files in my rtorrent folder (with some exceptions that are not relevant here I suppose):
What do you think? |
Could
This is expected for the torrent session saving process.
|
I have modified slightly my message above since you wrote your messae :) I always had .rtorrent.rc (as it was before commenting out rtorrent-cross-seed.sh reference)
I'll have to check about the 15 minutes mark. I'm not sure but it seems to take longer. I have 7TB free so it should be fine :) |
It looks like you're missing a bunch of values for your
|
Thanks for that @stickz. I've altered .rtorrent.rc file that now looks like that:
I have also added the new variable I'll monitor how it's going and will report. |
As an update, the situation is worse now :) rtorrent is not seeding anything, I believe consistently. in rtorrent.log, I can see that it times out on the announcement for each and every tracker (i've got something like 30 trackers that are suppose to announce). I have been running on Edge for the last 20 hours maybe. My assumption is that it never got to announce to any tracker for the last 20 hours. Anything (logs, cfg, ...) you would like me to provide? |
Yes, I need to know if you're using any UDP trackers. This docker container doesn't support it properly. Furthermore, consider limiting the amount of trackers that can announce at once.
Lastly, this variable needs to be 16M for the amount of torrents you have. We recently added support for 16M. |
I've done everything you mentioned except disabling ipv6 on the hosts (synology distro). Instead I have disabled ipv6 in the container itself by adding:
Should I disable ipv6 at the host level? The uptime for the container is 3 hours. Nothing is currently seeding unfortunately. In rtorrent.log, I can see that each torrent is being parsed (successfully?):
My .rtorrent.rc now looks like this:
My compose looks like this:
|
sit tight @tofkentof. I have #292 coming. I realized the rTorrent software stack was not being built with the intended flags. Also, c-ares + curl is outdated. This will need to be resolved with anther pull request. This docker container is lacking maintenance. I don't know if bringing it up to date will resolve your 16K torrent problem though. |
@tofkentof please provide your ruTorrent 2 out of 3 PRs are merged. #295 #296 #297. These bleeding edge improvements should be able to handle 50k of TCP trackers. |
@stickz the config.php is not exposed outside of the container. I guess it's to be expected? the line config.php:
|
Config looks good. Please try the latest docker release made 40 minutes ago. These changes completely transform the container with GCC 13.2, PHP 8.2, cURL 8.5.0, c-ares 1.24.0 etc. This is an exponential improvement with the build fixes. If the rTorrent software is still faulty, we can look into further actions. I just need to know if your ruTorrent loads correctly. |
Thanks for that. I've pulled the new image latest and will report back. |
Nothing is being seeded unfortunaly and has never been with the new image. I have the feeling since I altered the .rtorrent.rc file with items you suggested I can't seed anymore. Is there any item added that could explain what I'm experiencing? |
Nope, nothing new added could have caused this to happen. If anything, the docker container is more scalable now for tens of thousands of torrents. If you're able to connect to ruTorrent, it's probably some kind of connectivity issue to the tracker. If all your trackers time out, then no peers will be detected to seed. I would strongly encourage looking into your configuration. I don't believe at this point it's related specially to the rTorrent software. You're not using UDP trackers. This rules out that problem. |
I have been also continuing to run into the issue even while on edge. At least for me, I can watch rtorrent use up 48gb of ram and an 8gb (100%) of swap. This is in a 64 gig total system. This ram usage was happening with the initial issue, was not introduced by any of the recent changes. I have also been able to replicate this on the same system. I comment out the actual rutorrent service in the docker compose and make a new one with the same settings, and a new folder to mount for /data to ensure no torrents are loaded. I am still getting these issues 100% of the time with this. |
The recommended course of action is to set |
I was away for a week but back home now. As mentioned previously, none of edge or latest tags helped. What worried me is that I couldn't get back to the state I was previously: rtorrent seeding and rutorrent failing to connect to rtorrent. Yesterday evening I switched back to an older tag: Verdict: rtorrent is seeding again. rutorrent is still not able to connect to rtorrent though. That's a relief on my side that I'm seeding again but at the same time wondering why none of edge or latest helped rtorrent since the last few merges. Question you will ask yourself no doubt ;) I could try to revert once more to latest to double check that rtorrent is failing to seed if you want me to. |
I just ran into the same issue after updating from |
Was your issue rtorrent not seeding or rutorrent not connecting to rtorrent or both? |
Please update the following line in your
It's highly recommended to be on |
Adding this line did not help unfortunately. I'm still currently on docker logs:
rutorrent.log last entry is from September. |
Also I wanted to double check that udp is not used (I created another post to not interfere with the current ideas in case the udp thing is a wrong path) Trace after replacing any IP I assumed being a peer by PEER and any fqdn that is related to a private tracker by ANNOUNCE_TRACKER:
|
|
If you are talking about the docker network config, it is created by the compose:
|
@stickz there is no progress on my side sadly. Problem is still occuring. Would you have any lead? Not sure what else to check. If the above network config is not enough, what else would you like me to produce? |
Im also having problems, cant get it to work with a newer version than [4.2.9-0.9.8-0.13.8-r0]. Get msg at startup: "No connection to rTorrent. Check if it is really running". I also tried the latest version as a clean install, works clean but as soon I try to copy the session folder from my old install I get error. Maybe is has something to do with some of the updates in version [4.2.9-0.9.8_1-0.13.8_1-r0]?
|
Please try docker edge and report back. There is a critical fix in here for an rTorrent memory alignment crash. This could be happening when hash checking torrents. |
I tried :edge now, it dident work at first got the regular error msg (no connection to rTorrent) in webui. But this time I tried to wait a longer then I did earlier. Just when I was to give up after about 15min the webui finally loaded! So I went ahead and tried the same thing with :latest, same thing there it works but it takes like 15min before the webui is accesseable, that havent been a thing in the earlier releases. Its also not only the first launch that takes time, when restarting the container I have to wait for like 15min before I can access webui. Conclusion: It works with :both egde and :latest, but the startup time for webui is like 15min compared to the earlier releases that was accessable almost instatly after reboot |
I can see the exact same issue here, you're not alone |
Support guidelines
I've found a bug and checked that ...
Description
After updating the rutorrent-crazymax for unraid docker rutorrent shows no more UI (endless "loading" text), but as I can see by the network traffic it still downloading/uploading some torrents
Expected behaviour
entering http://192.168.8.121:8095/ opens the web-ui
Actual behaviour
I'm getting endless "Loading" message instead of web-ui.
Steps to reproduce
I think I didn't updated the rutorrent-crazymax for long like 6-8 months, after update it today to the latest version (Last Update: Oct 25, 2023) ui stopped working
Docker info
Docker Compose config
No response
Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: