[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