Couldn't create socket: Too many open files (fdlimit.c:683)

[pitris]

Hello,
I'm running transmission-daemon (2.72) on openwrt. In the past two days I started getting these messages in the log:

Code: Select all

Couldn't create socket: Too many open files (fdlimit.c:683)

I've never had any problems with that, even if I was seeding much more torrents than I do now. The set of my torrents hasn't changed in the last few days.
Now I'm running approx 10 torrents with maximum peers up to 100.
ulimit -n is 1024
If I check lsof, I see loooots of "can't identify protocol" messages

Code: Select all

$ lsof | grep transm
transmiss 4617 4619 pitris  979u     sock        0,5       0t0 199889769 can't identify protocol
transmiss 4617 4619 pitris  980u     sock        0,5       0t0 199900590 can't identify protocol
transmiss 4617 4619 pitris  983u     sock        0,5       0t0 199915857 can't identify protocol
transmiss 4617 4619 pitris  985u     sock        0,5       0t0 199889796 can't identify protocol
transmiss 4617 4619 pitris  987u     sock        0,5       0t0 199900618 can't identify protocol
transmiss 4617 4619 pitris  989u     sock        0,5       0t0 199900608 can't identify protocol
transmiss 4617 4619 pitris  993u     sock        0,5       0t0 199900684 can't identify protocol
transmiss 4617 4619 pitris  996u     sock        0,5       0t0 199900660 can't identify protocol
transmiss 4617 4619 pitris  998u     sock        0,5       0t0 199900661 can't identify protocol
transmiss 4617 4619 pitris  999u     sock        0,5       0t0 199900662 can't identify protocol
transmiss 4617 4619 pitris 1001u     sock        0,5       0t0 199900698 can't identify protocol
transmiss 4617 4619 pitris  968u     sock        0,5       0t0 199890115 can't identify protocol
...
$ lsof | grep transm | grep identify | wc -l
2448

And all the torrents one by one get stopped because transmission cannot save any files...

Any ideas what could happen?
Thanks!

[pitris]

And one more thing: there's also lots of

Code: Select all

Couldn't set source address 2001:0:5ef5:79fb:283c:ceb:a9b6:b86d on 991: Cannot assign requested address (net.c:269)

in the log.

[pitris]

Nothing special, still the same...
It's not the limit, there's no global limit for peers, only some torrents have their own limit for peers.

[rb07]

I'm running transmission-daemon (2.72) on openwrt. In the past two days I started getting these messages in the log

Two questions:

1. Is it your own build or installed from a package?
2. What changed just before those 2 days? Interesting changes: installed a new version (of anything related), changed the settings.

One cause of the "too many open files" problem is building transmission with a libcurl configured to use --enable-nonblocking and without c-ares. In fact, the latest curl version (7.28.0) got rid of the nonblocking option.

Correction:
The libcurl problem is with curl built with settings: --with-threads, and not --with-ares (nonblocking has nothing to do).

[pitris]

I haven't changed the settings for ages, that's the weird thing... No installation nor upgrade of whatever.
peer-limit-global was always 128 in my conf and never had any trouble. After this started to happen I tried to increase it to 256 but it didn't help...
This transmission-daemon is actually running on a router. It is the trunk, installed from packages. So I assume also the libevent should be ok.
curl is 7.23, but i have no idea how the transmission is built...

[rb07]

Good, then it doesn't look like the libcurl problem, it is something else.

Do you have a working netstat?

The lsof output seems to be showing peer connections, it would be helpful to see in what state are those connections (CLOSE_WAIT, ESTABLISHED, SYN_SENT), and netstat can be used to show that:

Code: Select all

$ netstat -anp | grep trans

The connections should vary a lot, growing and shrinking. If some start accumulating, then its a problem.

You should take a look at this old ticket: Unable to save resume file. Too many open files. Perhaps x190 meant to say disable DHT (not uTP).

Also check the actual limit:

Code: Select all

$ cat /proc/$(pidof transmission-daemon)/status | grep FDSize

[pitris]

Ups, I was talking about peer-limit-global but I meant open-file-limit. peer-limit-global was set to 65535. When I set it to 240, it seems to work fine (even if my set of torrents couldn't reach 240 in summary, because they all have per-torrent peer limit).
Question #2: I had an incorrent listen address for IPv6 (a one which does not exist on the machine). That resulted in "Couldn't set source address" mentioned earlier. But there's an interesting side-affect: transmission then does not do any announce nor scrape, not on IPv6 (understandable) nor on IPv4 (why?).

[flagg]

I have the same problem even with Transmission 2.73

Linux 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 12.10 server headless

Code: Select all

    "peer-limit-global": 240, 
    "peer-limit-per-torrent": 200

only 1 torrent downloading

no disk errors
no permissions errors
nothing changed in system files

I haven't changed anything during this period. only uptated from 2.72 to 2.73
I switched back to 2.72 but the problem remains

after a while (about 30 min) the process starts to reach 80%+ CPU usage and can't connect to WebUI

top


this is the syslog

Code: Select all

Nov 29 15:35:31  transmission-daemon[2786]: last message repeated 16 times
Nov 29 15:36:31  transmission-daemon[2786]: last message repeated 2 times
Nov 29 15:37:31  transmission-daemon[2786]: last message repeated 6 times
Nov 29 15:38:15 ra transmission-daemon[2786]: Couldn't create socket: Too many open files (fdlimit.c:682)
Nov 29 15:38:41 ra transmission-daemon[2786]: Couldn't create socket: Too many open files (fdlimit.c:682)
Nov 29 15:38:59 ra transmission-daemon[2786]: Couldn't save temporary file "/home/user/.config/transmission-daemon/resume/torrent_name.61893edc6e002401.resume.tmp.1rVABP": Too many open files (bencode.c:1744)
Nov 29 15:38:59 ra transmission-daemon[2786]: torrent_name Unable to save resume file: Too many open files (torrent.c:486)
Nov 29 15:38:59 ra transmission-daemon[2786]: Couldn't save temporary file "/home/user/.config/transmission-daemon/stats.json.tmp.JR7Tls": Too many open files (bencode.c:1744)
Nov 29 15:38:59 ra transmission-daemon[2786]: torrent_name Pausing (torrent.c:1769)

cat /proc/2786/status | grep FD

Code: Select all

FDSize:	1024

[rb07]

I have the same problem even with Transmission 2.73

The version is not important.

Linux 3.5.0-18-generic #29-Ubuntu

The problem is probably the way the Ubuntu maintainer built libcurl.

You already have seen the description of the 2 common causes... in the comments above.

Let's try something different:

• On a terminal see if you have curl-config, it probably comes with the -devel package, not with the regular curl or libcurl package. If you don't have it, then install the corresponding development package.
• Using that command twice look for the following:

  Code: Select all

  $ curl-config --features
  ...
  AsynchDNS
  ...
  

  and

  Code: Select all

  $ curl-config --libs
  ... -lcares ...
  

• If you have both of those, or none, then it should work, but if you have "AsynchDNS" and not "-lcares", then that's the problem. Possible solution: re-install older versions of curl until you find one that is built correctly.

For the record (since I have misquoted the parameters), you can see how curl was built using:

Code: Select all

$ curl-config --configure

and the problematic options are: not using --enable-ares, when using --enable-threaded-resolver.

[flagg]

I rebuild the lib by myself

curl-config --configure

'--disable-threaded-resolver' '--enable-ares'

[rb07]

Wrong parameters... they will work, but c-ares is precisely the async resolver that works fine with threads.

You don't say anything about the most important fact, did your rebuild fix the problem?

[flagg]

Wrong parameters... they will work, but c-ares is precisely the async resolver that works fine with threads.

You don't say anything about the most important fact, did your rebuild fix the problem?

that was my configuration at the time I posted
so no...it didn't worked but now I have rtorrent + rutorrent

[cfpp2p]

it didn't worked but now I have rtorrent + rutorrent

before resorting to that, see if perhaps information here and what follows will help:

https://trac.transmissionbt.com/ticket/5161#comment:3