Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4706 closed Bug (worksforme)

Transmission only resolves hostname once and caches resolved IP forever

Reported by: shadowlmd Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.41
Severity: Normal Keywords: transmission-daemon
Cc:

Description

Tracker is up for more than two days after a two week downtime. Transmission is not seeding any torrents for this tracker. There are no errors in log (/var/log/daemon.log). In web interface I see torrents in green color with status "seeding" but on trackers page I see "could not connect to tracker" errors (see screenshot). I can manually connect to tracker url via browser from the same machine where transmission is running. Problem goes away when I restart transmission-daemon. But I do expect transmission to be able to connect to tracker without being restarted each time a tracker goes offline for a while.

I'm running transmission-daemon under Ubuntu 10.04.

Attachments (1)

transmission.png (5.4 KB) - added by shadowlmd 7 years ago.

Download all attachments as: .zip

Change History (18)

Changed 7 years ago by shadowlmd

comment:1 Changed 7 years ago by x190

shadowlmd: Your .png doesn't support what you wrote. It shows Transmission being unable to connect and that it will retry in 2 hours. Does it eventually connect on its own if you just wait?

comment:2 Changed 7 years ago by shadowlmd

It will never connect. I wrote that tracker came back online more than two days ago and transmission was still unable to reconnect. Also torrents were not marked red like they should when there are problems with trackers. I waited one whole day for it to reconnect and it did not. Then I restarted daemon and it connected to trackers instantly.

comment:3 Changed 7 years ago by jordan

shadowlmd, can you confirm the version of transmission-daemon that you're running? 2.41 seems pretty new for 10.04.

Also, I'm not sure how to test this -- I don't have a tracker at hand to take offline. :)

FWIW I'm not seeing this issue if I try to run Transmission while disconnected from the network, and then reconnecting to the network after Transmission's been idle for an hour.

comment:4 Changed 7 years ago by shadowlmd

Yes, it's 2.41 from Andreas Noteng's (official maintainer) PPA (https://launchpad.net/~andreas-noteng/+archive/transmission). Currently there is 2.42 but the package is incomplete so I can't install it.

An hour downtime is not an issue. It happens when tracker is offline for several days. You can probably add a test torrent with a fake tracker url, like 'tracker.example.com' mapped to a real tracker through hosts file. Then you comment entry in hosts and url becomes unavailable until you uncomment it. I will do the same to make sure it is reproducible on my system.

comment:5 Changed 7 years ago by shadowlmd

While experimenting, I discovered that transmission only resolves hostname once and caches resolved IP forever. So, if tracker's IP changes, transmission will never catch up with the change. In my case, after a downtime, tracker was moved to a new IP, which is why transmission could not connect to it.

comment:6 Changed 7 years ago by livings124

  • Component changed from Transmission to libtransmission
  • Owner set to jordan
  • Summary changed from transmission-daemon cannot connect to tracker after tracker downtime to Transmission only resolves hostname once and caches resolved IP forever

comment:7 Changed 7 years ago by jordan

Hmm.... Transmission uses libcurl's default behavior for DNS caching.

In curl 7.23.1 the cache timeout period is 60 seconds, so I'm not sure what the problem here is. What testing were you doing to determine the DNS cache behavior?

comment:8 Changed 7 years ago by jordan

Relevant similar ticket from rTorrent: http://libtorrent.rakshasa.no/ticket/334

comment:9 Changed 7 years ago by shadowlmd

I started torrent with single tracker, then I changed tracker's IP through /etc/hosts file. After around 5 hours transmission was still successfully updating tracker using old IP.

comment:10 Changed 7 years ago by shadowlmd

I'm running another test now with real DNS change.

comment:11 Changed 7 years ago by livings124

What version of curl is on your system?

comment:12 Changed 7 years ago by shadowlmd

I have libcurl3 7.19.7-1ubuntu1.1.

Also, it passed test with real DNS change. I have another idea where to look, will run another test.

comment:13 Changed 7 years ago by x190

FWIW, I ran into a similar issue recently where only a restart of Transmission would allow the announce to be successful. No log messages. There had been a sleep event some hours earlier. Strangely, another instance of Transmission could connect to the same tracker without issue.

comment:14 Changed 7 years ago by jordan

shadowlmd, any news?

comment:15 Changed 7 years ago by shadowlmd

I tried some tricks, but could not reproduce issue. Either it's random, or there is some special case which I cannot figure.

comment:16 Changed 7 years ago by jordan

  • Resolution set to worksforme
  • Status changed from new to closed

Closing this ticket since we can't reproduce it.

Still, thanks for reporting the issue. If you find more information in the future on how to trigger the behavior you were seeing, please let the dev team know via trac. Thanks!

comment:17 Changed 7 years ago by shadowlmd

That's really a bad idea to close a real issue affecting more than one person just because you have not found a way to reproduce it *yet*. Open issue could attract someone, people could say they are affected too, submit new details.

Note: See TracTickets for help on using tickets.