Opened 14 years ago

Closed 14 years ago

#378 closed Bug (fixed)

use {get,set}rlimit to deal with open file limits

Reported by: aaroncorey Owned by: charles
Priority: Normal Milestone: 1.00
Component: Transmission Version: 1.02+
Severity: Normal Keywords:
Cc:

Description

setrlimit(RLIMIT_NOFILE) should be called in daemon/daemon.c in main, which on OS X will bump open file limits from the ludicrously small (256) to reasonable (2048).

Note that this file limit is troublesome and cascades into many other bugs, since once you hit the file limit other bugs tend to crop up, including display glitches.

Attachments (1)

setrlimit-diff (771 bytes) - added by aaroncorey 14 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 14 years ago by aaroncorey

I've been testing this patch, but even now I still get occasional file limit problems. I'll report back after I do some instrumentation.

Changed 14 years ago by aaroncorey

comment:2 Changed 14 years ago by charles

Looking into fdlimit.c, I see some fairly frightening code that revolves around a variable named TR_MAX_OPEN_FILES. I suspect this is where the problem is coming from.

comment:3 Changed 14 years ago by charles

0.91 fixes a rather severe fd leak. This enhancement is a nice idea, but I wonder if it's still necessary?

comment:4 Changed 14 years ago by charles

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

I haven't been seeing this problem since the 0.91 fix, so I don't think this is necessary. If we ever do hit the 'too many open files' wall again, this would be a good fix for it.

comment:5 Changed 14 years ago by wfaulk

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Type changed from Enhancement / Feature Request to Bug Report
  • Version changed from 0.82 to 0.96+

I am definitely seeing this problem. I can easily reproduce the problem in current nightlies by setting the "Global Maximum Connections" (hereafter, "GMC") too high.

If I set GMC to 150, everything goes swimmingly. (The default soft limit for MacOS 10.5 seems to be 256.) If I push it up to 500, I start to get problems within 30 seconds or so, starting with "Couldn't create socket (Too many open files)" in the log and progressing to "Tracker could not be reached" errors in the main GUI.

However, if I start Transmission from a command line where I've previously run 'ulimit -n 10000', I do not have those problems at all when I move from 150 GMC to 500. 10000 is ridiculously high, but it was just for testing.

The patch is a little simplistic, just setting the soft fd limit to 2048. I doubt that anyone would want to set their GMC anywhere near that, but it would be clever to make it match GMC plus overhead for other open file descriptors, and check to see if setrlimit() fails if the user pushes GMC too high.

comment:6 Changed 14 years ago by charles

  • Milestone changed from Sometime to 1.x
  • Owner changed from aaroncorey to charles
  • Status changed from reopened to new

comment:7 Changed 14 years ago by charles

  • Milestone changed from 1.x to 1.00
  • Resolution set to fixed
  • Status changed from new to closed
  • Summary changed from call setrlimit in main to deal with open file limits to use {get,set}rlimit to deal with open file limits

added in r4438.

Note: See TracTickets for help on using tickets.