Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#18640: Use smarter algorithms to handle socket exhaustion
----------------------------------------+------------------------------
 Reporter:  nickm                       |          Owner:  andrea
     Type:  enhancement                 |         Status:  assigned
 Priority:  Medium                      |      Milestone:
Component:  Core Tor/Tor                |        Version:
 Severity:  Normal                      |     Resolution:
 Keywords:  tor-dos, TorCoreTeam201606  |  Actual Points:
Parent ID:  #17293                      |         Points:  3
 Reviewer:                              |        Sponsor:  SponsorU-can
----------------------------------------+------------------------------

Comment (by andrea):

 Notes on handling OOS:

 Sockets probably account for most of the descriptor use in a running Tor
 process, but we should make the maximum socket count a little lower than
 the maximum number of descriptors so they can't block us from opening
 files.
 We'll need a heuristic to decide which connections are least harmful to
 kill analogous to OOM handling, but the first step is building plumbing
 to get a chance to run an OOS handler.

 Per compat.c, sockets are created (and the socket counter adjusted) in
 tor_socketpair() (AF_UNIX only), tor_open_socket() and
 tor_accept_socket(), and
 the _nonblocking/_with_extensions versions of those functions.

 Call sites:

  - tor_open_socket_nonblocking() called in three places, all in
 connection.c

    - connection_listener_new() (2 call sites)
    - connection_connect_sockaddr()

  - tor_accept_socket_nonblocking() called in one place, in
 connection_handle_listener_read()

  - open_socket() calls in src/ext/eventdns.c ?

  - get_n_open_sockets() returns counter

  - socket exhaustion can be detected by open/accept failing with
    errno EMFILE, ENFILE, ENOBUFS, ENOMEM.

  - For testing purposes, we can artificially restrict number of
 descriptors
    to trigger socket exhaustion using ulimit -n.

 We can build an OOS handler analogous to circuits_handle_oom called with
 current number of open sockets and an indicator of whether one just failed
 with one of the socket exhaustion related errnos from open_socket()/accept
 call sites.  It can then compare socket count against a new config setting
 parallel to the MaxMemInQueues setting the OOM handler relies on to decide
 if it needs to act.

  - How should we set the default of the number of sockets?  On Linux
    getrlimit(RLIMIT_NOFILE) works, but what about elsewhere?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18640#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs