Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8680 closed defect (duplicate)

CPU 100% - conn_write_callback(): socket # wants to write.

Reported by: alphawolf Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.11-alpha
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Running as a relay on Debian Wheezy x86_64, installed from tor repository.

This is difficult to describe, and I'm not 100% certain I know how to reproduce it... It seems to reproduce itself. After an indeterminate amount of time, the CPU usage for tor goes to 100% and stays there until I restart the service. This is a fairly low bandwidth relay (128 KB/s), and even when very busy the CPU usage is usually 3%. The most recent time this happened, I stumbled upon the "SIGNAL DEBUG" command, which I passed to tor via arm. The result was *millions of lines* of the following:

Apr 10 17:59:25.000 [debug] conn_write_callback(): socket 124 wants to write.
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): 124: starting, inbuf_datalen 0 (0 pending in tls object). at_most 15872.
Apr 10 17:59:25.000 [debug] tor_tls_read(): read returned r=-1, err=-2
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): After TLS read of 0: 0 read, 0 written
Apr 10 17:59:25.000 [debug] connection_or_process_cells_from_inbuf(): 124: starting, inbuf_datalen 0 (0 pending in tls object).
Apr 10 17:59:25.000 [debug] conn_write_callback(): socket 124 wants to write.
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): 124: starting, inbuf_datalen 0 (0 pending in tls object). at_most 15872.
Apr 10 17:59:25.000 [debug] tor_tls_read(): read returned r=-1, err=-2
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): After TLS read of 0: 0 read, 0 written
Apr 10 17:59:25.000 [debug] connection_or_process_cells_from_inbuf(): 124: starting, inbuf_datalen 0 (0 pending in tls object).

Those lines were repeated identically, adding 75,000 lines per second to the log.

Other information:

  • The relay also runs a bitcoin server as a hidden service.
  • Tor is configured to to listen for socks connections on the local network.

Before running "SIGNAL DEBUG", I: 

  • Turned off the bitcoin server. CPU remained at 100% for the tor process.
  • Disabled the hidden service in torrc, and gave SIGHUP. CPU remained at 100% for the tor process.
  • Disabled any device on the local network that could be accessing tor via socks. CPU remained at 100% for the tor process.

I'm not sure what other information I can provide... Let me know what else you need to help track this down.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by arma

arm is a Tor controller, and it has a local socket open to Tor. It's possible what you are seeing is Tor writing stuff to the Tor controller (arm). The more it logs, the more it writes.

You can kill -USR1 your Tor and it will dump a list of current connections to the log. If that socket number is associated with your controller connections, I'd bet this is a false alarm.

comment:2 Changed 7 years ago by nickm

Alternatively, this could be the same as #5650 and #8679

comment:3 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final
Resolution: duplicate
Status: newclosed

comment:4 Changed 7 years ago by nickm

(closed as duplicate. let's try to coordinate efforts at #5650)

comment:5 Changed 7 years ago by nickm

(There's now a possible fix for this issue on that ticket. Needs testing!)

Note: See TracTickets for help on using tickets.