bitcoind consumes 100% cpu when offline (can't connect to peers) #6903

CAddrMan::Select_ contains two infinite loops, trying to find peers. The float fChanceFactor becomes very large = 1.2^n after n loops, while info.GetChance() returns a very small number, 10^-324.

What you're describing with very small probabilities I mostly fixed in a784f90c a long time ago. What code are you actually seeing this in?

Related issue: #1664 (it was solved back then, at least, as gmaxwell says)

Zcash users are seeing this behaviour on our testnet (our corresponding issue is zcash/zcash#717). We are based off 0.11.2; it does appear that there have been slight changes to Select_() in the intervening time, but nothing that appears to alter the break condition for the infinite loop.

We have a proposed fix for this now (zcash/zcash#929). It would be great to have your thoughts on it @gmaxwell (and if desired we can make a PR for here :smiley:)

Thanks for mentioning @str4d

I can confirm this issue. I am sad to see that this issue has been opened nearly four years ago and is still open.

Running bitcoind v0.18.0 full node with bitcoin.conf:

onlynet=onion
onion=127.0.0.1:9050
listen=1

I think it would be much smarter and better, if bitcoind would detect network unreachability and then go into some sleepy connection testing loop, until connection is detected as up again. This would prevent unhealthy CPU and therefore electrical power usage.

@wodry What are the steps to reproduce, please?

Which OS are you running. What version of tor? Does it happen when you start the node without a connection or does it only happen when you initially had some connections?

Oh yes, sorry, of course:

Bitcoin-qt: bitcoin-0.18.0-x86_64 from binary tar ball OS: Debian GNU/Linux 9.8 (stretch), all packages up to date. Kernel: 4.9.0-8-amd64 [#1](/bitcoin-bitcoin/1/) SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux Tor: 0.2.9.16-1

The 100% CPU usage also happens maybe 10 minutes after having started bitcoin-qt when DSL cable was initially already cut off (and therefore local running Tor had already lost connection).

Steps to reproduce:

Run local Tor with following config

/etc/tor/torrc

ClientOnly 1

ClientUseIPv6 1

ReachableAddresses *:53,*:80,*:443,*:6667,*:8333,*:9001,*:9030

BandwidthRate  3 MBit
BandwidthBurst 5 MBit

The user that runs Bitcoin-qt has to be in the group debian-tor so bitcoin-qt can start Tor Hidden Service automatically.

Run Bitcoin-qt (no connections inbound from internet to any ports like 8333 allowed) with following config

~/.bitcoin/bitcoin.conf

upnp=0

onlynet=onion
onion=127.0.0.1:9050
listen=1
maxuploadtarget=400

# Specify connection timeout in milliseconds
timeout=20000

# Accept command line and JSON-RPC commands
server=1

Let bitcoin-qt run some days and then disconnect network cable, wait approx. 1 hour or Have only Tor running, then disconnect netwotk cable and then start bitcoin-qt and wait 10 minutes (last debug.log messages: "0 addresses found from DNS seeds", "dnsseed thread exit")

-> CPU usage of bitcoin-qt process is constantly 100%

Connect network cable

-> after some time (1h or so) Tor detects network as up again, bitcoin-qt has connection again (messages: "Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)", "New outbound peer connected: version: 70015"), and the CPU usage reduces to normal low value.

The issues seems to be solved with bitcoind 0.18.1. Maybe #16405 fixed it?

With 0.18.1 CPU usage stays now low when internet connection goes down, and when internet connection is up again, at once bitcoind detects it and connects to new outbound peers. So behavior is now really smooth. From my point of view, this issue can be closed.

@wodry #16405 fix in unrelated to this issue.

The issues seems to be solved with bitcoind 0.18.1.

Closing for now