Error: Unable to save resume file. Too many open files.

[fingon]

I've been getting this error message ever since 2.0.0 - I have now tried 2.0.0 - 2.0.4. The bug didn't occur on 1.9.3. It usually happens after N hours (where N in interval of ~2-10) of serious seeding/downloading.

[fingon]

All torrents I have open go to that state at once too.. Guess something's leaking file handles. This is on Mac, in case it matters.

[Longinus00]

Have you tried using lsof or something similar to determine what's actually eating the files?

[fingon]

It's full of IPv6 UDP listeners.. ~3300 of them:

• Transmiss 36443 mstenber 3312u IPv6 0x0a2f9dc0 0t0 UDP *:*
• Transmiss 36443 mstenber 3313u IPv6 0x0a2cdd38 0t0 UDP *:*
• Transmiss 36443 mstenber 3314u IPv6 0x0a2fa054 0t0 UDP *:*

.. and so forth.

[Bombaclat]

Having the same problem on CentOS 5.5 with Transmission 2.04. I have 50 torrents running, with 48 seeding. A restart of the daemon fixes the issue.

[Harry]

Same problem for me. Kernel 2.6.35-ARCH.

lsof shows (snip): ​http://pastebin.com/dUEjyPEd A ton of "can't identify protocol".

I tried adding "* - nofile 2048" in my limits.conf, with no success.

If I try to open the settings menu I get a ton of popups about "Too many open files". I have 66 torrents, all private-flagged. Running Transmission 2.04 (11151) with a GUI.

My settings.json is: ​http://pastebin.com/wLHixR70

The box running Transmission is dual-stacked with a working IPv6 tunnel given to me via radvd.

I hope this helps fix whatever bug is causing this. Thanks.

[fingon]

I think there's two different 'features' though, you with ton of seeded torrents probably just run out of connections due to number of connections in each seeded torrent (if you haven't chosen seed only X at once and/or otherwise limited it). My case happens even with low (5) torrents being seeded, with fixed max# of connections, after a while -> IPv6-only 'feature' seems to be in order.

[starmoon]

I have the same problem. I have 60s torrents seeding.

[starmoon]

Seems that i have solved this problem by using "ulimit -n 2048" before starting transmission-daemon.

[AVI]

Having the same problem on Ubuntu 10.04 server with Transmission (daemon) 2.11.

400s seeding torrents. Kernel 2.6.32-25-generic-pae

# ulimit
unlimited

"open-file-limit": 64,

[AzaToth]

This happens to me as well now :( I've got atm 70 seeding torrents, and after a day or so, the process starts to run at 100% and impossible to connect to it. lsof shows similar output as previous posts shows.

Whats strange is that before I've had 200 seeding torrents without any problem, it's mostly latly it's started to hang... I haven't been able to identify which torrent might be the issue.

[apeiron]

I just ran into this with two (2) torrents on OS X, Transmission version 2.12. My max open files sysctl is three times what the current open files amount is. Restarting Transmission seems to have fixed the problem for now.

[charles]

Does the problem go away if you turn off DHT?

[AzaToth]

Replying to charles:

Does the problem go away if you turn off DHT?

The tracker is private, and the majority of the torrents have private flag on, though I can't vogue for that everyone has that, thus I'll test by disable it, might take some days though. Is it same for peer exchange, or should I only explicit disable DHT?

[charles]

Yes, I'm asking what happens if you explicitly disable DHT.

The process of deciding which torrents to share on the DHT network is different from deciding whether or not your session sets itself up in the DHT network at all...

[Harry]

Replying to charles:

Does the problem go away if you turn off DHT?

I have had DHT off for about two days and the problem has not happened yet. Either I am lucky, or DHT is the culprit.

[AzaToth]

Replying to Harry:

Replying to charles:

Does the problem go away if you turn off DHT?

I have had DHT off for about two days and the problem has not happened yet. Either I am lucky, or DHT is the culprit.

I've also tested, and havent seen any issues yet, doesn't seems to be too many open fds now

$ sudo lsof -p $(pidof transmission-daemon) | wc -l
116

[charles]

AzaToth?, for you is that also after turning off DHT?

[AzaToth]

Replying to charles:

AzaToth?, for you is that also after turning off DHT?

yep

[charles]

Judging from the UDP sockets, and the behavior going away when DHT is disabled, this sounds like it might be a DHT bug.

CC'ing the wise and powerful DHT author jch :)

[Sheriff Hobbes]

I experience this problem even with DHT turned off! Using Transmission 2.13. System is RHEL 5.5. With Transmission 1.11 this did not happen!

[charles]

Sheriff Hobbes: Have you tried using lsof or something similar to determine what's actually eating the files?

[Sheriff Hobbes]

Transmission is eating the files. I've done "lsof -p <transmission process id>" and I get a very long list. I changed max. open files from the default 1k to 32k and now I've been running for 2 1/2 days w/o a problem. I have only 12 torrents in my list!

[egolost]

I'm on CentOS 5.5 experiencing this problem for quite many releases now. Thought the solution was to increase the max open files in the OS but that only delayed the problem. Tonight I took the time to investigate a bit further with lsof -u tmission (which is my user running transmission-daemon).

lsof returns a lot of line similar to:

transmiss 19183 tmission 454u sock 0,5 2252802264 can't identify protocol

this was previous mentioned and a solution was to turn of DHT. So I did and it's still filling up with those kind of lines. After 36 min uptime lsof -u tmission returns 227 lines and of them 159 is similar to the one above. I'm currenty seeding 18 torrents and Downloading 11.

Could it be something related to ipv6 maybe? got a friend without ipv6 but he is on ubuntu and he don't have this problem. I have multiple ipv6 addresses on my host. I tried to bind it to a single of them but that did not change anything either.

[jch]

Does the following help?

--jch

[egolost]

jch: applied and tested your patch on 2.13. Tried both with DHT enabled and disabled. The "can't identify protocol" open files are still increasing every minute. After 17 min i got 201 of them and totally 292 lines of open files(this with DHT enabled).

[egolost]

netstat -apn attachment after applying the 0001-Avoid-a-descriptor-leak-when-binding-the-IPv6-DHT-so.patch

[jch]

Transmission has opened just 32 sockets, two of which are for UDP. Working just as designed, sorry for that.

--jch

[livings124]

I'm a bit confused. Are you saying that the posted patch fixes this issue?

[jch]

I'm only saying that in the particular attachment above, there's nothing wrong I can see -- everything is working as designed.

Egolost, I'm closing this bug for now -- please reopen it if you manage to reproduce this issue with r11644 or later.

--jch

[jordan]

reopening for attribution

[jordan]

fixed by r11644

[masc]

I'm seeing regression with version 2.50 and higher (didn't check previous releases) running transmission-daemon on gentoo.

Having DHT disabled, unidentifiable sockets seem to remain at an acceptable level.

/ # lsof -p 5201 | grep .*identify.*protocol.* | wc -l
333

Having DHT enabled, transmission will reach the maximum open file limit pretty quickly.

Open file limit is now capped to FD_SETSIZE (https://trac.transmissionbt.com/ticket/4164), which makes it difficult to avoid the problem in addition.

[masc]

update. disabling DHT won't help. just takes longer until the limit is reached and transmission stalls.

/ # lsof -p 5201 | wc -l
1045 -> FD_SETSIZE limit exceeded
/ # lsof -p 5201 | grep .*identify.* | wc -l
755

grsec: more alerts, logging disabled for 10 seconds
grsec: From 200.35.62.46: denied resource overstep by requesting 1024 for RLIMIT_NOFILE against limit 1024 for /usr/bin/transmission-daemon[transmission-da:5203] uid/euid:110/110 gid/egid:105/105, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: From 200.35.62.46: denied resource overstep by requesting 1024 for RLIMIT_NOFILE against limit 1024 for /usr/bin/transmission-daemon[transmission-da:5203] uid/euid:110/110 gid/egid:105/105, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: From 200.35.62.46: denied resource overstep by requesting 1024 for RLIMIT_NOFILE against limit 1024 for /usr/bin/transmission-daemon[transmission-da:5203] uid/euid:110/110 gid/egid:105/105, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: From 200.35.62.46: denied resource overstep by requesting 1024 for RLIMIT_NOFILE against limit 1024 for /usr/bin/transmission-daemon[transmission-da:5203] uid/euid:110/110 gid/egid:105/105, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: From 200.35.62.46: denied resource overstep by requesting 1024 for RLIMIT_NOFILE against limit 1024 for /usr/bin/transmission-daemon[transmission-da:5203] uid/euid:110/110 gid/egid:105/105, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: more alerts, logging disabled for 10 seconds

[x190]

What is your setting for "peer-limit-global:" in settings.json?

[masc]

240 (default)

[rb07]

Replying to masc:

update. disabling DHT won't help. just takes longer until the limit is reached and transmission stalls.

Assuming you have something like this:

$ emerge -pv net-misc/curl

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] net-misc/curl-7.25.0  USE="idn ipv6 ssl -ares -gnutls -kerberos -ldap -nss -ssh -static-libs -test -threads" 0 kB 

Can you rebuild curl, this time with c-ares enabled? i.e. 'USE="ares" emerge -av net-misc/curl'

[rb07]

Actually is threads enabled, and c-ares disabled (building libcurl) what causes a problem like the one you describe.

[masc]

Replying to rb07:

Actually is threads enabled, and c-ares disabled (building libcurl) what causes a problem like the one you describe.

Disabling threads and enabling ares for curl resolves the issue.. great, thanks!

[rb07]

Replying to masc:

Disabling threads and enabling ares for curl resolves the issue.. great, thanks!

Its only the one combination that doesn't work: threads enabled, c-ares disabled; the other 3 combinations do work fine, I'm using threads enabled, and c-ares enabled, which is the one that should give the best performance.

[samuli]

Sorry, but how is the bug fixed if the problem is still manifesting with certain allowed build combinations of curl?

[masc]

interesting, I can't combine those two. I had to remove threads support to get ares.

!!! The ebuild selected to satisfy "curl" has unmet requirements.
- net-misc/curl-7.24.0::gentoo USE="ares ipv6 kerberos ldap (multilib) ssl threads -gnutls -idn -nss -ssh -static-libs -test"

  The following REQUIRED_USE flag constraints are unsatisfied:
    threads? ( !ares )

  The above constraints are a subset of the following complete expression:
    threads? ( !ares ) nss? ( !gnutls )