it's described in more detail here. https://trac.transmissionbt.com/ticket/3504#comment:38 Reproducible: Always Steps to Reproduce: 1. emerge curl with USE="threads -ares" 2. start transmission-daemon Actual Results: file descriptors will leak over time, the open file limit will be a hit sooner or later, so transmission will stall and has to be restarted. Expected Results: file descriptors are not supposed to leak. the issue does not occur when compiling curl with USE="-threads ares". maybe it's a good idea to have these curl use flags as a requirement when emerging transmission.
I had faced with this problem too, but it disappeared somehow not long ago. Only thing that changed apart of ~arch upgrades, was that i added to curl's configure options --without-zlib.
ebuild of curl-7.26.0 has: # ares must be disabled for threads REQUIRED_USE="threads? ( !ares ) and from ChangeLog: 20 Feb 2011; Tomáš Chvátal <scarabeus@gentoo.org> curl-7.21.4.ebuild: Update REQUIRED_USE to allow disabling of both ares and threads useflag. Thanks to Brian for hint. since the bug was filed this May and the bug was fixed already back in February, closing as INVALID ->
this useflag constraint does not fix the issue. as mentioned in my initial description. Steps to Reproduce: 1. emerge curl with USE="threads -ares"
(In reply to comment #3) > this useflag constraint does not fix the issue. > as mentioned in my initial description. > > Steps to Reproduce: > 1. emerge curl with USE="threads -ares" https://trac.transmissionbt.com/ticket/3504#comment:44 "... I'm using threads enabled, and c-ares enabled, which is the one that should give the best performance." Our curl ebuild doesn't even seem to allow this combination. CCing curl maintainers for this. Seems like the commit made by scarabeus mentioned in Comment #2 can't be correct and, is missing a bug # explaining the change anyways. And I'm definately not going to block USE="threads" of curl from transmission ebuild.
Also have you retried with transmission-2.61?
> "... I'm using threads enabled, and c-ares enabled, which is the one that > should give the best performance." he also mentions that +threads -ares is the only combination which causes a problem (while even +threads +ares would work). I didn't check against 2.61 yet, but I will (also using curl 7.26). the point of my suggestion was that 2.52 is marked stable but is very much unstable when used with curl USE="+threads -ares". which alternative is there to stabilize? unstable ebuilds should certainly not contain this constraint, but a warning may still be appropriate as long as the issue is not resolved.
I have been running transmission 2.61 with curl 7.26.0 for a few days now and it seems okay.
(In reply to comment #7) > I have been running transmission 2.61 with curl 7.26.0 for a few days now > and it seems okay. phew. thank you for testing.
