0.20.0 pruned node stuck on ARMhf 32 Linux #19380

My node which otherwise happily runs version 0.19.1 gets stuck (tested twice so far) with 0.20.0 using the same configuration as 0.19.1. After returning back to 0.19.1 everything works well.

I expect the node to run and not get stuck for no reason.

Actual behavior

When it gets stuck the process itself is in a weird state because it does not react to TERM signal at all. There is nothing special in the log. Just that there are no more messages in the log after it gets stuck. I run it via daemontools so if the process would end in any way, it would be restarted but that is not the case.

To reproduce

No idea yet. Maybe there are others who just upgrade and find their node not responding after some time. For timing, see https://bitnodes.io/nodes/2001:470:6f:200:20a:f5ff:fe64:22b0-8333/ in plain text: I restarted 0.20.0 in the morning at 8:15 and already at 16:45 it was stuck. After that I returned back to 0.19.1 because this was already second time it got stuck since I upgraded yesterday.

System information

bitcoin-0.20.0-arm-linux-gnueabihf.tar.gz from bitcoincore.org (signature of checksum file verified, checksum verified) bitcoin-0.19.1-arm-linux-gnueabihf.tar.gz from the same as above

# uname -rvm 
3.4.0-lineageos-gb263a89 [#1](/bitcoin-bitcoin/1/) SMP PREEMPT Wed Oct 24 09:09:32 UTC 2018 armv7l

Ubuntu 19.10 ARM 32 in a chroot where bitcoind runs for years happily.

In case it might be related: For the sake of randomness and low-probability high-gain I am running minerd CPU miner on some ARM boxes. But mining seems to work well even on 0.20.0 while it is not stuck.

My bitcoin.conf file:

prune=25550
addresstype=bech32
blockmaxsize=750000

The script I run everything with (free free to comment also on unrelated things that catch your eye):

unset LANGUAGE LANG LC_ALL
exec nice $HOME/bitcoin-0.19.1/bin/bitcoind -datadir=/bitcoin \
  -rpcbind=127.0.0.1 \
  -rpcbind=192.168.1.118 \
  -rpcallowip=192.168.0.0/16 \
  -whitelist=127.0.0.1/8 \
  -whitelist=192.168.1.0/24 \
  -whitelist=192.168.3.0/24 \
  -whitelist=88.99.167.175 \
  -whitelist=88.99.167.186 \
  -whitelist=2a01:4f8:10a:37ee::2 \
  -onion=127.0.0.1:9050 \
  -nodebuglogfile \
  -dbcache=256 \
  -maxmempool=256 \
  -maxuploadtarget=512 \
  -maxconnections=32 \
  "$@"

Linux odroidxu4 4.14.180-odroidxu4 [#16](/bitcoin-bitcoin/16/) SMP PREEMPT armv7l GNU/Linux

I've not seen this behavior on my ARMv7 node running the 0.20 release, though we are running very unlike kernels.

@wpeckr Thanks for feed-back! Were there any relevant change between 0.19.1 and 0.20.0 that would relate to kernel? Yes, I am on a pretty old one on that device.

In the git diff between 0.19.1 and 0.20.0 I noticed a change from bionic to focal (Ubuntu versions) so I am upgrading my chroot to be on latest focal and will re-run 0.20.0. Will update here on Sunday.

There's no changes I'm aware of that would have an impact, but I haven't followed the commits closely for this release. If I was to guess, our difference is that you're making extensive use of the getblocktemplate RPC call, perhaps run with some of the debugging output enabled to see if that coincides with when you're having issues?

debug=rpc

Everything works well after upgrading the chroot bitcoind runs in to Ubuntu Focal (20.04 LTS). Closing this issue. Thank you for feed-back @wpeckr !