File stats lock-up rtorrent in resume_load_progress/resume_save_progress

[rcawston]

Using the latest libtorrent/rtorrent releases, rtorrent is freezing for extended periods of time on my machine that is seeding from a CIFS share (sadly, we have no other storage option). GDB backtraces show activity in the resume_load_progress resume_save_progress functions in resume.cc. This happens on all older versions I have tested as well. When lots of torrents with many files are open, this leads to the rtorrent ui being unresponsive indefinitely, tracker request timeouts, etc.

I made an incredibly hacky patch (mainly to confirm the issue) for seeding that removes the fileExists and mtimeValue checks in resume_load_progress, and fileExists check in resume_save_progress and just presumes the file exists. This leads to a responsive and functional rtorrent UI, but is obviously not production worthy.

Do you think it would be possible to thread out the file_stat calls in resume.cc's resume_load_progress and resume_save_progress, or otherwise prevent them from locking up rtorrent?

[Speeddymon]

Can you detail further on when you are seeing this? What activity are you taking in the UI when it happens?

I have a similar issue where the UI will freeze when I first start rTorrent, and at other times, seemingly randomly, but it always eventually recovers. Your OP mentions that it freezes indefinitely. How long have you waited? Mine can sometimes take 10-20 minutes (possibly longer) to recover.

[chros73]

Mine can sometimes take 10-20 minutes (possibly longer) to recover.

Really?
Do you have local disk?
Did you enable udp/dht support in your config?

[Speeddymon]

Yep. Local disks and dht is off. I have the server powered down due to weather issues at the moment but I'll check if UDP is enabled next time I power it on.

[Speeddymon]

I should add that I'm running 16 SATA disks through a single SAS controller and an expander card, so that might contribute to some of the issue, but I wouldn't expect it to be all of the issue.

[chros73]

Woow! :)
Check if trackers.use_udp.set is enabled, if it is then try it with disabled.

[Speeddymon]

Will do.

[chros73]

One more thing popped in my mind: how many torrents do you have approx?
Take a look at this section in the meantime (also the referenced ticket): https://github.com/rakshasa/rtorrent/wiki/Performance-Tuning#session-save

[Speeddymon]

I have several hundred torrents started, but usually less than a dozen are actually active at the same time.

#180 seems likely, except that based on how the session.save event is supposed to work in theory, that means it should stack up multiple threads of session saves running simultaneously, and cause the indefinite freezing like OP is reporting, and probably eventually could freeze the whole OS. In my case, its not doing either one.

[ghost]

Can you post the patch as a gist? I'm curious to see it.

[Speeddymon]

trackers.use_udp.set is not in my config.
I'm going to add it right now tho.

[Speeddymon]

Added that and the session save schedule entry with a 6 hour interval.

[chros73]

trackers.use_udp.set is not in my config.

If it wasn't there that means it was disabled.
I'll be curious what will happen.

[chros73]

Added that and the session save schedule entry with a 6 hour interval.

@Speeddymon did it get better?

[Speeddymon]

I need to check back on this. I got back from vacation and haven't powered on the server since. Will update you on this hopefully in the next couple of days.

[Speeddymon]

Seems better with the session save delayed to 6 hours and UDP enabled. Not sure which is more relevant, but I would surmise the session save is the culprit.