High CPU, autostarting httpd processes, and index.php

[stephenrs]

Hi,

I've been using Transmission (currently v2.03) for quite a while, and I've noticed that sometimes it causes both of my CPU's (MBP 2.66Ghz core 2 duo, 4GB RAM) to peg at 100% and stay there. I usually just clear out some torrents and restart to make the problem go away, but today this didn't work, so I decided to dig a little deeper. What I found is that Transmission (or something impersonating Transmission) has spawned a bunch of apache processes, and is sending GET requests to my local web server - continuously. In fact, it sends several dozen of these GET requests per second(!). Here are a couple entries from my web server logs:

Code: Select all

127.0.0.1 - - [03/Aug/2010:17:55:24 -0500] "GET /installation/index.php HTTP/1.1" 302 - "http://www.tracker.tracker.example.com/installation/index.php" "Transmission/2.03"
127.0.0.1 - - [03/Aug/2010:17:55:24 -0500] "GET /installation/index.php HTTP/1.1" 302 - "http://www.tracker.example.com.tracker.example.com/installation/index.php" "Transmission/2.03"

If I kill -9 the httpd processes, they just regenerate themselves. Normally when I see hits for anything in a "/installation" directory in server logs, I suspect someone (or something) is trying to breach security on the server, but I'm guessing this is not the case with Transmission (??).

Can someone please tell me what's going on here? Whatever it is, it's pretty abusive. I'd really appreciate any help with this, it's making it so that I can't really use Transmission if I want to do anything else on my computer at the same time. Thanks.

[jch]

Code: Select all

$ host tracker.tracker.example.com
tracker.tracker.example.com has address 127.0.0.1

Workaround: edit your torrents to remove any reference to a tracker that rhymes with hay.

--jch

[stephenrs]

Workaround: edit your torrents to remove any reference to a tracker that rhymes with hay.
--jch

hehe, i'm pretty sure i know what you mean, and i'll give that a try, thanks for the reply...but can you explain a bit more about what's going on under the hood/in the background? i only superficially understand the mechanics of torrents, and i'd like to have a better handle on what's happening on my machine - it's my main development box. i don't need a full primer on all things torrent-tech related, but any info (like what is it trying to install?) would be much appreciated. thanks again.

[jch]

can you explain a bit more about what's going on under the hood/in the background?

Sure.

A well known tracker rhyming with hay (and unfortunately censored by this <censored> forum) has been redirected at the DNS level to 127.0.0.1, i.e. localhost. Any connection to said tracker will end up connecting to your own host.

Try it: in a terminal window, type "host <the name of the tracker>".

--jch

[stephenrs]

A well known tracker rhyming with hay (and unfortunately censored by this <censored> forum) has been redirected at the DNS level to 127.0.0.1, i.e. localhost. Any connection to said tracker will end up connecting to your own host.

http://www.webpronews.com/topnews/2010/ ... eedfetcher

WTF?? Right you are. Who's genius idea was this...I'm having a hard time understanding the rationale. I'm guessing a lot of people (without cpu monitors) are wondering why their machine slows down so much when they download <certain> torrents...

Removing the offending tracker from affected torrents, does in fact fix this, so thanks again.

EDIT: maybe I'll visit my hosts file and give them a taste of their own medicine...hehe...or at least to make it so that I don't have to edit every <hay> torrent I want to download...

[stephenrs]

Could someone please inform us what the hay is the issue with blueberry? I thought they were basically out of the tracking business anyway. So if Transmission doesn't like blueberries (or trackers that rhyme with hay) why isn't it coded to just not load them as trackers (and give a log entry) instead of using localhost to block them?

You're right, they are out of the tracking business, but it's not Transmission's fault that these requests resolve to localhost - there's a blurb about it here: http://forum.suprbay.org/showthread.php?tid=51913 ...a mighty ungraceful way to get out of the business of tracking, I'd say.

I do agree though - if it's common knowledge that hay trackers are bogus, why does Transmission honor these client-side-performance-killing trackers in torrents? Although I haven't tried it yet, I'm guessing the hosts file hack that I have in mind will solve this problem for me, but it would seem to make more sense for this to be handled at the app level, especially for users who don't know what a hosts file is. In any case, I still love Transmission...I used to use azureus/vuze, yuck.

[hippy dave]

hm that's dirty as hell - fair enough if tphay want to stop tracking, but why the (heck) would they redirect to localhost? surely it should be obvious that's going to cause problems for someone somewhere down the line.

edited my hosts file accordingly, cheers for the info.

[Inuyasha]

I do agree though - if it's common knowledge that hay trackers are bogus, why does Transmission honor these client-side-performance-killing trackers in torrents? Although I haven't tried it yet, I'm guessing the hosts file hack that I have in mind will solve this problem for me, but it would seem to make more sense for this to be handled at the app level, especially for users who don't know what a hosts file is. In any case, I still love Transmission...I used to use azureus/vuze, yuck.

Although every torrent on earth comes from linuxisobay, minor workarounds to preserve functionality for this tracker and prevent catastrophic client breakage are overshadowed by a much greater concern - never ever fixing an upstream issue.

[stephenrs]

Although every torrent on earth comes from linuxisobay, minor workarounds to preserve functionality for this tracker and prevent catastrophic client breakage are overshadowed by a much greater concern - never ever fixing an upstream issue.

While I agree with you in principle, rigid adherence to myopic principles rarely gets you very far in the real world. As a practical matter, pretending this problem doesn't exist (just because it's upstream) is no solution at all...neither is passing the workaround off fully to the users downstream. Since Transmission requires a restart to stop hammering my cpu after editing one of the torrents in question, and waiting for Transmission to shut down is not my favorite 5 minutes of the day (hehe), I assert that a far better solution would be to offer something in Transmission's preferences something like "dont' hammer my localhost with endless useless requests", or better yet (and arguably more future proof and flexible), the ability to specify an ignore list for trackers...perhaps with hay included in the list by default.

This problem may not ever go away on its own, so I suggest that it might be nice if Transmission would do something to help end users address it...and yes, I know that most/all torrent clients take a while to shut down...

[stephenrs]

Sounds like trac ticket material to me. You will need to register first.

T used to refuse the hay in the past. This should be easy to implement.

I had the same thought, thanks for the nudge: https://trac.transmissionbt.com/ticket/3507

[yebyen]

It occurred to me that this might launch useful behavior in rare cases, or in a special case not yet dreamed of...

What if you were running a tracker listening on port 80, or mod_proxy apache forwarder to a tracker? Then, if you used multiple hosts to download a torrent from the hay site, or another one who has configured their torrents this way, and the hosts were all on a VPN (or literally on the same host... I'm having trouble getting lxc configured on my netbook, so I wind up using a lot of chroots instead of the bridge, and now I'm having multiple users on multiple chroots with their own transmission clients.)... if you did that, then there would be someone to manage communication between those VPN'ed hosts.

It's useful once you accept that if some of them get a better connection some of the time, you're not sure where you'll be sitting, and your hosts do have fast access by VPN link. (Even one day a week.)

I don't know a lot about how transmission binds to IP addresses, but I conjecture that it would have to be a special tracker (or at least bound to the VPN), or the localhost name might have to be redirected to the address of the tracker on the VPN subnet.

I just saw two different transmission clients running on the same host in chroots behind the same NAT firewall, both having different parts of the same 5GB download, not communicating with each other, and trying to get a tracker on localhost... and the gears started turning.

[stephenrs]

It occurred to me that this might launch useful behavior in rare cases, or in a special case not yet dreamed of...

Interesting thoughts, and you might be onto something in a strange kind of way , but for the other 99.99% of cases this behavior is simply a CPU cycle-wasting, machine-heating, PITA. IMHO.