ressource problem on linux?

Nico Weinreich info at web-unity.de
Sat Feb 13 12:15:39 UTC 2010


or could this be a problem of privoxy handling all tor clients? I think it's 
no problem to run a privoxy instance for each tor client, but I can't find a 
config option in tor, which specifies the port of privoxy?

----- Original Message ----- 
From: <info at web-unity.de>
To: <or-talk at seul.org>
Sent: Thursday, February 11, 2010 9:03 AM
Subject: ressource problem on linux?


> Hi,
>
> I'm using Tor 0.2.1.22 on Debian Lenny. I played a little bit with
> Tor (so there are 10 instances of tor client running simultaneous). I
> can see very often the following in log:
>
> We tried for 15 seconds to connect to '111.222.333.444' using exit
> 'SoDesuKa'. Retrying on a new circuit.
>
> This very often occurs on SoDesuKa and sometimes on some other nodes
> to. There is also
>
> Have tried resolving or connecting to address '111.222.333.444' at 3
> different places. Giving up.
>
> When enabling debug log, I can see
>
> Feb 11 08:23:51.768 [debug]
> connection_ap_handshake_rewrite_and_attach(): Client asked for
> 111.222.333.444:80
> Feb 11 08:23:51.768 [debug] connection_ap_handshake_attach_circuit():
> Attaching apconn to circ 3699 (stream 0 sec old).
> Feb 11 08:23:51.768 [info] exit circ (length 3):
> $B8E356A56EC7300CA87BE4FD0D8096EA6E9113E1(open) lanroamer(open)
> CityTor(open)
> Feb 11 08:23:51.768 [debug] link_apconn_to_circ(): attaching new conn
> to circ. n_circ_id 3699.
> Feb 11 08:23:51.768 [debug] connection_ap_handshake_send_begin():
> Sending relay cell to begin stream 35585.
> Feb 11 08:23:51.768 [debug] relay_send_command_from_edge():
> delivering 1 cell forward.
> Feb 11 08:23:51.768 [debug] relay_send_command_from_edge(): Sending a
> RELAY_EARLY cell; 4 remaining.
> Feb 11 08:23:51.768 [debug] circuit_package_relay_cell(): crypting a
> layer of the relay cell.
> Feb 11 08:23:51.768 [debug] circuit_package_relay_cell(): crypting a
> layer of the relay cell.
> Feb 11 08:23:51.768 [debug] circuit_package_relay_cell(): crypting a
> layer of the relay cell.
> Feb 11 08:23:51.768 [debug] append_cell_to_circuit_queue(): Made a
> circuit active.
> Feb 11 08:23:51.768 [debug] append_cell_to_circuit_queue(): Primed a
> buffer.
> Feb 11 08:23:51.768 [debug]
> connection_or_flush_from_first_active_circuit(): Made a circuit
> inactive.
> Feb 11 08:23:51.768 [info] connection_ap_handshake_send_begin():
> Address/port sent, ap socket 13, n_circ_id 3699
> Feb 11 08:23:51.768 [info] connection_edge_process_inbuf(): data from
> edge while in 'waiting for connect response' state. Leaving it on
> buffer.
> Feb 11 08:23:51.768 [debug] conn_write_callback(): socket 4 wants to
> write.
> Feb 11 08:23:51.768 [debug] flush_chunk_tls(): flushed 512 bytes, 0
> ready to flush, 0 remain.
> Feb 11 08:23:51.768 [debug] connection_handle_write(): After TLS
> write of 512: 0 read, 586 written
> Feb 11 08:23:52.100 [debug] global_write_bucket now 10485760.
> Feb 11 08:23:53.032 [debug] conn_read_callback(): socket 4 wants to
> read.
> Feb 11 08:23:53.033 [debug] connection_read_to_buf(): 4: starting,
> inbuf_datalen 0 (0 pending in tls object). at_most 16384.
> Feb 11 08:23:53.033 [debug] connection_read_to_buf(): After TLS read
> of 512: 586 read, 0 written
> Feb 11 08:23:53.033 [debug] connection_or_process_cells_from_inbuf():
> 4: starting, inbuf_datalen 512 (0 pending in tls object).
> Feb 11 08:23:53.033 [debug] relay_lookup_conn(): found conn for
> stream 35585.
> Feb 11 08:23:53.033 [debug] circuit_receive_relay_cell(): Sending to
> origin.
> Feb 11 08:23:53.033 [debug] connection_edge_process_relay_cell(): Now
> seen 9 relay cells here.
> Feb 11 08:23:53.033 [info] connection_ap_process_end_not_open():
> Address '111.222.333.444' refused due to 'server out of resources'.
> Considering retrying.
> [...]
> Feb 11 08:24:56.496 [info] connection_ap_process_end_not_open():
> Address '111.222.333.444' refused due to 'misc error'. Considering
> retrying.
> Feb 11 08:24:56.496 [info] client_dns_incr_failures(): Address
> 111.222.333.444 now has 1 resolve failures.
>
> This occurs only when running 10 instances, with 5 tor instances all
> seems fine. So it seems to be a problem with file descriptors or tcp
> ports? Can anyone help?
>
>
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
> 

***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list