Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#5553 closed Bug (duplicate)

regression in 2.82 -- open file descriptors no longer user configurable

Reported by: Astara Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.82
Severity: Normal Keywords: posix FD file_descriptors


Seems like someone thought that applications had to limit their use of fd's by hard coding the limit in the code?

I don't know for sure, but I doubt seriously that POSIX covers user torrent servers/clients.

I'm also pretty sure that the 1024 file descriptors is a minimum an Os will provide to an application or that it can "rely" on. I'd be very surprised to see 1024 being a maximum, as server progs like Samba and Squid-cache both are usually configured for ~10K fd's.

The effect to shut down about 1/3rd of my torrents -- as they'd no longer be saved and couldn't be restored.

I have 320 torrents of which, right now, maybe 70-80 are active.

I have another 230-250 that are Inactive, but waiting for connections.

I kept setting ulimit for 16K open FD's both the soft and hard limit, and couldn't understand why I had FH exhaustion -- until I saw that no matter what I set for open file handles -- it was ignored and reduced to 1024.

That might make sense if it was running on a low-resource server, but that's what the config file / runtime options are supposed to be for -- certainly such limits shouldn't be hard-coded into the code, no?

Change History (5)

comment:1 Changed 8 years ago by livings124

  • Component changed from Transmission to libtransmission
  • Owner set to jordan

comment:2 Changed 8 years ago by x190

Astara, the 1024 limit is related to a limit imposed by libcurl, I believe. If you set your global peer limit to 800 or less does the problem disappear?

comment:3 Changed 8 years ago by mike.dld

Looks like duplicate of #5306.

comment:4 Changed 8 years ago by jordan

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

I agree, this is a duplicate of #5306.

comment:5 Changed 8 years ago by Astara

How do you figure?

That bug says: "Total of peer sockets + FILE_CACHE_SIZE(32) + all other open files for this process must be <= FD_SETSIZE (hopefully 1024)"

It is intentional that fdlimit.c:541 goes to 1024 as that is regarded as the safe upper limit for libcurl.

So the math is: 1024 - 32 (FILE_CACHE_SIZE) - ~200 for process files - ~800 (peers global) = 0. =============

my max_peers value was noted in the discussion on this as being 768. That's less than 800. So how can this bug be a duplicate -- as it had file-cache-size=32, max_peers=768 (actual has never been seen to be over ~300, with 150-200 being more typical.

That bug was a case where the peer limit was > 800. So why do you think it is the same (most of the notes on this bug are in the forum, since the bug database tends to drop responses -- will have to see if this goes through -- should probably save it for repost in the forum)...

Note: See TracTickets for help on using tickets.