Possible switch to rtorrent-ps

[binhex]

Hi guys, my torrent client of choice is rtorrent, i do indeed eat my own dog food and use this docker image for my download needs. From time to time i see unrecoverable crashes with the rtorrent process (zombie state) which is not great, requiring a restart of the container.

so i started looking at rtorrent-ps as an alternative due to slightly more active dev and a focus on stability, so far its working well for me in local testing, no crashes, it seems a bit faster, and resource usage also seems lighter.

i can confirm the current rtorrent.rc is compatible with rtorrent-ps, and rutorrent will stay the same, so the only real change is a downgrade to rtorrent v0.9.6, but other than that i see no side effects, so anybody got an real issues with switching this image over to rtorrent-ps?.

EDIT - This is now live in the latest image, any problems please raise a separate issue.

#54

[dbsps]

Would welcome the switch! Any chance you could toss in pyroscope/pyrocore as well? The pyrotorque functionality specifically would be a nice addition (provides the queuing system that rtorrent lacks)

see: https://pyrocore.readthedocs.io/en/latest/advanced.html#rtorrent-queue-manager

[disrupted]

Indeed this would be a very welcome change and also agree with @dbsps about pyrocore. Was even considering a fork of your project but of course it would be way better to have it officially.

[GiowGiow]

That would be awesome man!

[fryfrog]

I think you just did it and something about my setup didn't like it. :)

[fryfrog]

Maybe just ui.torrent_list.layout.set in my rtorrent.rc file.

Edit: This solved mine, yay. Also, I suggested this way way back in issue #53 based on some reading on the internet! ;)

[binhex]

@fryfrog yes i did pull the trigger on sunday so you are correct, latest image does included rtorrent-ps. glad you got your issue sorted, i can only assume that that particular config entry is a 0.9.7 rtorrent option only.

yes i know you suggested it (linked to it in op of this issue), it was in the back of my mind to revisit, and now its a reality :-)

i havent missed the comments regards inclusion of pyrocore, i just wanted to do this one step at a time, i will add in another issue for it so i dont forget.

[enoch85]

Works fine here, been testing for a week now.

[disrupted]

same here, working great. I was just thinking the other day since now it's switched to rTorrent-PS it might actually make sense to go all in and switch to the newer fork rTorrent-PS-CH which includes a number of enhancements and fixes, one of the most notable being the ability to work with partially completed jobs (those cases where you'd only want 1 file from a giant torrent) which is otherwise not possible in rtorrent. Pretty sure I am not the only one who's been looking for this. It includes some other interesting features which are all explained if you follow the link.

[dbsps]

from what I understand -CH is not optimized to work inside a docker container. From the github repo: Differences between rTorrent-PS: - CPU optimized build - relative rpath linking - git version support - vanilla build of rtorrent is completely separated - no docker support (due to CPU optimized build) via https://github.com/chros73/rtorrent-ps-ch

[fryfrog]

I wonder why "due to CPU optimized build" precludes Docker? Isn't it just passing through what ever CPU you've got?

[disrupted]

@fryfrog I know, right? There should be a way to get it working in Docker no matter what.

I wonder what would happen if one simply was to disable the optimize flag in their build.sh script. Unfortunately I have no experience with this whatsoever but perhaps it's worth a shot.

[binhex]

no docker support (due to CPU optimized build)

i am guessing here but i think what that means is that when you compile rtorrent-ps-ch during docker build (which is normally when its done) then the problem you have is that rtorrent-ps-ch will be built with optimised code for the cpu that the build host (in my case docker hub) has. If a user then pulls down the built docker image then there is a good chance that their host's cpu will be different to the build host's and thus rtorrent-ps-ch will run non optimised.

the only way around this would be to compile rtorrent-ps-ch at docker run time, this would ensure that the code is optimised for the end user's cpu, but of course would mean a lengthy wait whilst its compiles before it will actually run the compiled app. this would only happen once and on restart of the container it would skip compilation and go straight to startup, but of course if a new docker image was built you would need to destroy the existing container and thus force recompilation again when the container gets created.

so is it possible to run rtorrent-ps-ch via docker?, i would say there is a god chance it could!, will it mean long waits on first run of the container?, absolutely.

[GottZ]

that would literally remove even more benefits of docker.
unless users use "dind" to build the clean image themselves, i'd strongly disagree from shipping this as container image. it's usually unreasonable to execute big changes on the container image after deployment.
in my case i store images on separate physical storage than volumes.

reasonable: make it a environment flag that, if set, downloads the source to a specified volume, builds it, replaces the already running instance (mounted through another volume) and then is done.

through this, upgrading the container could be improved too without much downtime.

probably best to ship a build container that creates a docker image and pushes it to the local store.

this way people can upgrade rtorrent without much downtime.

this would also remove the requirement for chown on startup and people can strip flood or rutorrent out of the container completely.

another issue: compiling eats ram. this container runs fine on a vm with 1 gb of ram or even less.
compiling could result in noticable issues for some people.

yes.. you are free to do what ever you want since it's pretty much your personal project. i'd say, create a build image that spits out images and then throw it aswell as a non cpu optimized version onto the docker hub

[dbsps]

Yeah I think thats likely the reason they explicitly state its not really meant for docker. Probably the more sane path forward would be to just see what features besides the CPU optimizations are of real value over -ps and then do a pull request over at -ps with those changes rather than trying to adopt -ch and hack around its problematic features with regards to containers.

…

On Thu, Mar 14, 2019 at 3:46 PM Jan-Stefan Janetzky < ***@***.***> wrote: that would literally remove even more benefits of docker. unless users use "dind" to build the clean image themselves, i'd strongly disagree from shipping this as container image. it's usually unreasonable to execute big changes on the container image after deployment. in my case i store images on separate physical storage than volumes. reasonable: make it a environment flag that, if set, downloads the source to a specified volume, builds it, replaces the already running instance (mounted through another volume) and then is done. through this, upgrading the container could be improved too without much downtime. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvn-zRqYQS2vC7r9gZ2W5UA_YFgCpbXks5vWqcggaJpZM4bUSMp> .

-- Regards, Kris Roadruck