[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #4580 [Tor Client]: Some Tor clients go nuts requesting the consensus if there is no recent enough consensus



#4580: Some Tor clients go nuts requesting the consensus if there is no recent
enough consensus
------------------------+---------------------------------------------------
 Reporter:  arma        |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  major       |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client  |        Version:  Tor: unspecified  
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------
 Yesterday we failed to make a consensus for whatever reason.

 Soon after, we (the directory authorities) started getting bombed by
 begindir requests. I'm not sure what they were requesting, but early
 analysis shows they were requesting a consensus. Most of the requests sent
 their begindir cell but never got their actual HTTP request through.

 When I noticed, moria1 was at 2+ gigs of ram. I did a kill -USR1 and it
 spent an hour dumping 195000 conns, and I killed it at that point. No idea
 how many conns it had total. They were almost all linked conns, e.g.:

 {{{
 Nov 25 02:34:45.000 [info] Conn 195295 (socket -1) type 5 (Exit), state 3
 (open), created 145 secs ago
 Nov 25 02:34:45.000 [info] Conn 195295 is to [x]:1.
 Nov 25 02:34:45.000 [info] Conn 195295: 0 bytes waiting on inbuf (len 0,
 last read 145 secs ago)
 Nov 25 02:34:45.000 [info] Conn 195295: 0 bytes waiting on outbuf (len 0,
 last written 145 secs ago)
 Nov 25 02:34:45.000 [info] Conn 195295 has Exit-ward circuit: circID 0
 (other side 46154), state 3 (open), born 1322201975:
 Nov 25 02:34:45.000 [info] Conn 195296 (socket -1) type 9 (Directory),
 state 5 (waiting for command), created 145 secs ago
 Nov 25 02:34:45.000 [info] Conn 195296 is to [x]:0.
 Nov 25 02:34:45.000 [info] Conn 195296: 0 bytes waiting on inbuf (len 0,
 last read 145 secs ago)
 Nov 25 02:34:45.000 [info] Conn 195296: 0 bytes waiting on outbuf (len 0,
 last written 145 secs ago)
 }}}

 For this particular [x], there were 16665 conns open because of it.

 But only 27 of them were OR conns, e.g.:

 {{{
 Nov 25 01:26:05.000 [info] Conn 121 (socket 371) type 4 (OR), state 8
 (open), created 704 secs ago
 Nov 25 01:26:05.000 [info] Conn 121 is to [x]:62067.
 Nov 25 01:26:05.000 [info] Conn 121: 496 bytes waiting on inbuf (len
 32736, last read 10 secs ago)
 Nov 25 01:26:05.000 [info] Conn 121: 0 bytes waiting on outbuf (len 0,
 last written 10 secs ago)
 Nov 25 01:26:05.000 [info] Conn 121: 0/18437 bytes used on OpenSSL read
 buffer; 0/18698 bytes used on write buffer.
 Nov 25 01:26:05.000 [info] Conn 121 has App-ward circuit: circID 36152
 (other side 0), state 3 (open), born 1322201666:
 }}}
 {{{
 Nov 25 01:26:35.000 [info] Conn 1530 (socket 163) type 4 (OR), state 8
 (open), created 208 secs ago
 Nov 25 01:26:35.000 [info] Conn 1530 is to [x]:62767.
 Nov 25 01:26:35.000 [info] Conn 1530: 0 bytes waiting on inbuf (len 0,
 last read 10 secs ago)
 Nov 25 01:26:35.000 [info] Conn 1530: 0 bytes waiting on outbuf (len 0,
 last written 95 secs ago)
 Nov 25 01:26:35.000 [info] Conn 1530: 0/18437 bytes used on OpenSSL read
 buffer; 0/18698 bytes used on write buffer.
 Nov 25 01:26:35.000 [info] Conn 1530 has App-ward circuit: circID 53174
 (other side 0), state 3 (open), born 1322202160:
 }}}
 {{{
 Nov 25 01:27:25.000 [info] Conn 3762 (socket 480) type 4 (OR), state 8
 (open), created 408 secs ago
 Nov 25 01:27:25.000 [info] Conn 3762 is to [x]:62152.
 Nov 25 01:27:25.000 [info] Conn 3762: 432 bytes waiting on inbuf (len
 32736, last read 10 secs ago)
 Nov 25 01:27:25.000 [info] Conn 3762: 32768 bytes waiting on outbuf (len
 36576, last written 10 secs ago)
 Nov 25 01:27:25.000 [info] Conn 3762: 0/18437 bytes used on OpenSSL read
 buffer; 0/18698 bytes used on write buffer.
 Nov 25 01:27:25.000 [info] Conn 3762 has App-ward circuit: circID 57857
 (other side 0), state 3 (open), born 1322201977:
 }}}
 {{{
 Nov 25 01:28:39.000 [info] Conn 7024 (socket 192) type 4 (OR), state 8
 (open), created 107 secs ago
 Nov 25 01:28:39.000 [info] Conn 7024 is to [x]:62866.
 Nov 25 01:28:39.000 [info] Conn 7024: 0 bytes waiting on inbuf (len 0,
 last read 98 secs ago)
 Nov 25 01:28:39.000 [info] Conn 7024: 0 bytes waiting on outbuf (len 0,
 last written 99 secs ago)
 Nov 25 01:28:39.000 [info] Conn 7024: 0/18437 bytes used on OpenSSL read
 buffer; 0/18698 bytes used on write buffer.
 }}}
 {{{
 Nov 25 01:32:14.000 [info] Conn 17016 (socket 417) type 4 (OR), state 8
 (open), created 202 secs ago
 Nov 25 01:32:14.000 [info] Conn 17016 is to [x]:62772.
 Nov 25 01:32:14.000 [info] Conn 17016: 480 bytes waiting on inbuf (len
 32736, last read 10 secs ago)
 Nov 25 01:32:14.000 [info] Conn 17016: 32768 bytes waiting on outbuf (len
 36576, last written 10 secs ago)
 Nov 25 01:32:14.000 [info] Conn 17016: 0/18437 bytes used on OpenSSL read
 buffer; 0/18698 bytes used on write buffer.
 Nov 25 01:32:14.000 [info] Conn 17016 has App-ward circuit: circID 40388
 (other side 0), state 3 (open), born 1322202167:
 }}}

 So my first thought is that moria1 just can't keep up with hearing all
 these new requests, and also pumping bytes out to the requestor, and
 things just queue up, which uses ram, which makes seeks slower, lather
 rinse repeat.

 Is there a Tor client version out there that asks for a consensus without
 checking if it has already asked for a consensus?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4580>
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