Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #925

Closed (moved)
Open
Opened Feb 12, 2009 by riastradh@riastradh

Tor fails badly when accept(2) returns EMFILE or ENFILE

If accept(2) in connection_handle_listener_read returns EMFILE or ENFILE, Tor logs a failure and returns to the event loop. The listening socket remains ready for reading, however, so that Tor again tries to accept a connection. This leads to tens of thousands of logged failures per second. Here is an excerpt from my syslog:

Feb 11 05:57:36 Tor[20415]: accept failed: Too many open files. Dropping incoming connection. Feb 11 05:57:54 last message repeated 301536 times Feb 11 05:57:54 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n. Feb 11 05:57:54 Tor[20415]: accept failed: Too many open files. Dropping incoming connection. Feb 11 05:58:05 last message repeated 184158 times Feb 11 05:58:05 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n. Feb 11 05:58:05 Tor[20415]: accept failed: Too many open files. Dropping incoming connection. Feb 11 05:58:13 last message repeated 127556 times Feb 11 05:58:13 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n. Feb 11 05:58:13 Tor[20415]: accept failed: Too many open files. Dropping incoming connection. Feb 11 05:58:26 last message repeated 223556 times Feb 11 05:58:26 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n.

I don't know what the right thing to do here is, but spiking the CPU and spraying log messages is not a very graceful mode of failure. One way to mitigate the damage might be to close the listening socket, which I believe won't be reopened until a minute later. This is no worse for the Tor network than just wedging, and perhaps better, since prospective connectors would be refused rather than silently forgotten in a flurry of furious logging.

Also, it would be nice to document the number of file descriptors generally required by a Tor relay, or a formula for computing it. For example, is it proportional to the bandwidth and to the number of relays in the Tor network? Or to the bandwidth and to the number of users in the Tor network? This way, prospective operators of Tor relays would not need to repeatedly restart their relays as they test incremental bumps in the file descriptor ulimits, unless there is some way to bump them without restarting the relay (but I doubt whether there is).

(Apologies if this is duplicated: I hit !^A while editing this, in order to move to the beginning of the line, but the obnoxious !@#!^%&%!^& web form [and my obnoxiously colluding web browser] interpreted it to mean something else for which I quickly hit the stop button. I don't know what hitting !^A actually did.)

[Automatically added by flyspray2trac: Operating System: All]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#925