Update triggering-searches.md

[luckylittle]

The original approach did not work when copying and pasting directly from the manual page - I had to modify how rTorrent triggers the cross-seed webhook.

rTorrent communicates via XML-RPC, and when a script is executed through event.download.finished, it captures the script’s output. If that output is not valid XML-RPC (as is the case with typical HTTP responses), it can cause the XML-RPC parser to fail, resulting in rTorrent becoming unresponsive and displaying a "Bad response" error.

Additionally, it is not necessary to pass $d.name= and $d.data_path=, the download hash alone is sufficient.

Recommended solution:

• Use /usr/bin/curl -s in your script to enable silent mode and suppress output.
• Execute the HTTP call asynchronously (e.g., by appending &) to prevent rTorrent from waiting for a response.

This solution has been tested and confirmed to work reliably.

[ShanaryS]

Could you keep the original and add this as an alternative? I believe the current works for some users. Feel free to remove $d.name= and $d.data_path= in the original, it's from pre v6.

d

[mmgoodnow]

rTorrent communicates via XML-RPC, and when a script is executed through event.download.finished, it captures the script’s output. If that output is not valid XML-RPC (as is the case with typical HTTP responses), it can cause the XML-RPC parser to fail, resulting in rTorrent becoming unresponsive and displaying a "Bad response" error.

This part seems wrong. Why would it expect a script to print out valid XMLRPC? rTorrent exposes an XMLRPC server and I wonder if your bug is actually there.

[zakkarry]

I've had no issues with what is currently used as the recommended commands in .rtorrent.rc - I'm wondering too why your PATH variables might not be being utilized.

Additionally, removing information that is "not necessary" seems like a useless exercise, even if the data is non-essential currently, but I guess assuming the user has the client added we can get the information elsewhere if we are intending on displaying it in some manner in v7/UI. If the information is available to the client at the completion call time, sending it can't hurt and future-proofs us against any changes that might necessitate the information, even just logging the name, down the road. I'm not too stuck on this though so I'll yield to @mmgoodnow and @ShanaryS on whether we only include infoHash going forward,

Just to elaborate a bit on my reasoning, I could see if a user was cautious about paths (maybe they contain their home directory as the path, and the username is "sensitive"), but if that is the case, it is a niche case. That user can modify the command themselves; defaulting to less complete data in the command doesn't seem to provide any benefit and as far as my immediate thinking goes, it can't and won't cause any issues.

---

Given all of that, the only outstanding major issue seems to be that your rTorrent isn't utilizing your PATH environmental variables at all? curl shouldn't require absolute paths, and I haven't experienced this myself in my container (are you using docker? If so what image specifically?)

Perhaps you can try setting a PATH for /usr/bin/ - which curl should show what the path defaults to if it exists in the PATH var's included directory. Would need more details about how you run your client to really understand why absolute pathing is necessary for curl, though.

[ShanaryS]

I agree on keeping $d.data_path=, they cost nothing and make futures changes easier if needed. $d.name= should definitely go though.

[zakkarry]

I agree on keeping $d.data_path=, they cost nothing and make futures changes easier if needed. $d.name= should definitely go though.

Given we can get the name from the .torrent file or client anyway, I think that's fine as well.

[luckylittle]

My $PATH is fine, I like to specify absolute path for security reasons (PATH Hijacking/Executable Path Injection attack prevention). It makes no difference in this scenario and works exactly the same with curl or /usr/bin/curl.

Your documentation specifically says: infoHash or path is required but not both (infoHash is recommended) [1] so it make sense to keep following that advice.

I'm not entirely sure if the latest xmlrpc change (rakshasa/rtorrent#1463) broke this functionality, but as it stands it did not work for me on rtorrent 0.15.4 without the changes specified here.

Source:
[1] https://www.cross-seed.org/docs/reference/api#post-apiwebhook

[mmgoodnow]

I wonder if it's some sort of deadlock because of the synchronous curl call.

[zakkarry]

My $PATH is fine, I like to specify absolute path for security reasons (PATH Hijacking/Executable Path Injection attack prevention). It makes no difference in this scenario and works exactly the same with curl or /usr/bin/curl.

Your documentation specifically says: infoHash or path is required but not both (infoHash is recommended) [1] so it make sense to keep following that advice.

I'm not entirely sure if the latest xmlrpc change (rakshasa/rtorrent#1463) broke this functionality, but as it stands it did not work for me on rtorrent 0.15.4 without the changes specified here.

Source: [1] https://www.cross-seed.org/docs/reference/api#post-apiwebhook

I see how you're reading this, but it's intended to mean "one of them is required, and both are not required" rather than "only provide one and not two" - I suppose we could clarify this better, but it's really not that big of a deal in my opinion. Something like "at least one option needs to be provided" seems more apt now that there are only two.

There is no reason for you, or anyone, to follow this misunderstood statement arbitrarily just because we wrote it ambiguously.

We can correct the language there to better reflect the usage, but removing the path isn't really something that is necessary and it seems like we are in agreement about the removal of old (and now invalid) option name, and keeping the remainder.

[luckylittle]

It might have been caused by one of these actually (fixed in 0.15.5):
rakshasa/rtorrent#1507
rakshasa/rtorrent#1512
rakshasa/rtorrent#1514

I will build this version and try with the old command. Stand by.

[zakkarry]

I copy pasted the lines directly from the docs when I setup my rtorrent.rc file, so it could be your specific version or container. If you need help with modifications to the Dockerfile to help troubleshoot or debug, you can come to the Discord and I can try and be of assistance too.

Let me know, username at the top of the list that is similar as here.

Discord link top right corner https://www.cross-seed.org

[luckylittle]

You probably use the old version (<0.15.4). I build my own binaries (no container) directly from the original source. Please test 0.15.4 or 0.15.5.

[hitboxr]

I'm not sure if this PR is the right solution, but this definitely does need to be addressed.

Specifically with current versions of rakshasa rtorrent (arguably the "official" flavor, and the only regularly updated one at this point), the webhook script makes the client completely unusable when firing. The entire rtorrent client hangs for upwards of a minute after a hash check is completed before even sending the HTTP request, and whatever interaction happens on firing causes cross-seed to log Indexing failed: Invalid XML-RPC message every time the webhook fires.

Disabling calling the script by commenting out the call in rtorrent.rc completely resolves this behavior on completed downloads, and rtorrent finishes the hash check and remains responsive as expected.

This is easily reproducible by running any recent rakshasa rtorrent release with the webhook script configured, and finishing a download to trigger it.

[zakkarry]

I'm not sure if this PR is the right solution, but this definitely does need to be addressed.

Specifically with current versions of rakshasa rtorrent (arguably the "official" flavor, and the only regularly updated one at this point), the webhook script makes the client completely unusable when firing.
.....

There are several version of rtorrent widely used, I use the rtorrent+flood container from hotio. This container is using 0.15.5--4.9.5 and I have no issues with it.

It would be helpful if you guys could give more information about your environments, as as it sits I've also used this on crazymax's fork and not had any issue and @mmgoodnow also hasn't echo'd that he has had any problems. We are kind of at a loss unless we can replicate and see this, so far the only place this has been brought up is in this issue sporadically with months apart comments, a diversion into discussing the path inclusion, and no real triaging being able to be done.

[hitboxr]

It would be helpful if you guys could give more information about your environments

I'm using crazy-max/rtorrent-rutorrent, nothing particularly out of the ordinary about the setup or environment. My client has ~6k torrents seeding, so maybe that's a factor if it's some kind of performance regression? I'm happy to provide any specifics, let me know what would be helpful.

I just tested out the latest v0.15.5 crazymax image and an older v0.15.3 image (specifically tag 5.2.8-0.15.3) and I see identical behavior on both. Reverting to the last crazymax image before the switch back to rakshasa (tag 5.1.7-7.2) completely resolves the issue, no client hanging and the webhook fires immediately with no errors in the cross-seed logs.

[zakkarry]

I have nearly 20k in my rtorrent, and experience no issues at all related to the completion call...I'm not sure which version @mmgoodnow uses but I also don't think he uses Docker.

He has more experience with RT than I do, but as I said I am using 0.15.5 and see no issues, I'll have to setup a mirror of your setup to test with or maybe @mmgoodnow has some input.

I also know many people who use crazymax's version and haven't heard anyone bring this up outside of this thread's commenting. I'll consult with them as well.

[luckylittle]

You are comparing apples and oranges. I don't know where your image came from and how it was built - this simply does not work when you use the latest binaries:

• prereqs

sudo dnf install -y gcc-c++ gcc libcurl-devel make ncurses-devel openssl-devel tmux wget zlib-devel

• libtorrent

./configure
make
sudo make install

• rtorrent

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-xmlrpc-tinyxml2
make
sudo make install

[mmgoodnow]

It might have been caused by one of these actually (fixed in 0.15.5):

rakshasa/rtorrent#1507

rakshasa/rtorrent#1512

rakshasa/rtorrent#1514

I will build this version and try with the old command. Stand by.

I was hoping these were going to fix it. I am fine with recommending & also.

I updated my version a couple months ago and had to pin back to 0.9.8 due to crashes and trackers not supporting it. I haven't looked into it further but it could very well be the long script executions causing the issues.

[mmgoodnow]

Minimize the changes to just the fix and I'll approve.

[zakkarry]

I wasn't "comparing" anything, I was giving my accounting/experience of the situation and I even said I would set up your environment.

I also told you where my "image came from" in a previous comment

[hitboxr]

even said I would set up your environment.

also told you where my "image came from"

Just as a point of clarification, @luckylittle and I are not the same person. I think you may have crossed a wire somewhere regarding who said what in response to who when.

I was hoping these were going to fix it. I am fine with recommending & also.

I updated my version a couple months ago and had to pin back to 0.9.8 due to crashes and trackers not supporting it. I haven't looked into it further but it could very well be the long script executions causing the issues.

I was hoping that as well. This makes it sound even more like the behavior is the result of a rakshasa rtorrent v0.10+ regression. I'd be curious to hear your experience with v0.15.5

[zakkarry]

I don't know, there have been several people, but my point was that I wasn't comparing anything and I mentioned which image I use and all that above, anyone can read it.

I'm just trying to see if I can replicate it, and as it stands I am not seeing the same issues. We (myself and mmgood) are just trying to help and figure out solutions.

[hitboxr]

As of yesterday, rakshasa rtorrent v0.16.0 has been released and contains a curl/http refactor to make requests asynchronously. I'm waiting on crazymax's docker image to bump versions before I can test it but it sounds promising from reading the patch notes.