Thread Exception When building database
I noticed if the download from the foundry is ahead of what bitcoind has processed so far, the server will start up and then halt with no sort of error messages. I had to run the server by hand to get an actual error message out of it.
$ python -m pdb /usr/local/bin/run_electrum_server
> /usr/local/bin/run_electrum_server(3)<module>()
-> __requires__ = 'electrum-server==1.0'
(Pdb) c
INFO:electrum:Starting Electrum server on electrum.infoha.us
INFO:electrum:Database version 3
INFO:electrum:Blockchain height 364172
INFO:electrum:UTXO tree root hash: 024be20b1a208ee8dd04cfb982b176fdec6428bbe4cc6025260aa8116fe2cc64
INFO:electrum:Coins in database: 1435151785615950
INFO:electrum:TCP server started on 199.101.100.59:50001
Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "build/bdist.linux-x86_64/egg/electrumserver/blockchain_processor.py", line 74, in do_catch_up
self.header = self.block2header(self.bitcoind('getblock', [self.storage.last_hash]))
File "build/bdist.linux-x86_64/egg/electrumserver/blockchain_processor.py", line 126, in bitcoind
raise BaseException(r['error'])
BaseException: {u'message': u"Can't read block from disk", u'code': -32603}```
It looks to me that this error originated in bitcoind. What is in your .bitcoin/debug.log when this happens? You may have to reindex bitcoind.
Yup, looks like the bitcoind was still indexing the blockchain, it had the headers but not the blocks.
So basically just missing some exception handling and retry behavior when trying to do catchup if bitcoind returns errors.
"Can't read from disk" sounds worse than not having caught up? I actually had this issue once with a corrupted blockchain and had to resync bitcoind
I'm fairly certain this is due to the 'fast' new method of Bitcoin Core doing catchup, it downloads the headers first, then the full block data later. In this case, the headers were downloaded so it's in the BlockIndex. It only checks if it has the blockdata if Pruning is enabled, but since pruning isn't enabled, until bitcoind catches up, it'll still fail to read the block
Not really sure if an upstream change needs make to return a separate error code, or if bitcoind.py should just handle this as 'bitcoind still warming up'