Bitcoin Core 'unable to open file' causes reindexing to fail

0

I recently struggled to send bitcoin from my Armory wallet (0.96.5) to another account. Sending bitcoin did not work because the wallet could not synchronize with the blockchain. Since Armory relies on the connection managed by the bitcoin core client, bitcoin-qt or bitcoind, it became evident that the failure was caused by the bitcoin core clients (0.17.1). The command ./bitcoin-qt --reindex was issued after Armory was shutdown, but failed repeatedly with entries in debug.log having excerpts such as the following immediately before shutdown:

2019-01-15T23:17:07Z Pre-allocating up to position 0x1000000 in rev01636.dat
2019-01-15T23:17:07Z UpdateTip: new best=0000000000000000001e1db68a762512729668e9dd4c6c06cae346a65618189e height=557921 version=0x20c00000 log2_work=90.224133 tx=371925681 date='2019-01-10T12:31:34Z' progress=0.996972 cache=700.2MiB(5254262txo)
2019-01-15T23:17:07Z UpdateTip: new best=00000000000000000014b6677c848def28a7edef1225b0aa865f96199cb1abd8 height=557922 version=0x20000000 log2_work=90.224157 tx=371928196 date='2019-01-10T12:42:46Z' progress=0.996976 cache=700.3MiB(5254902txo)
2019-01-15T23:17:07Z Imported mempool transactions from disk: 1 succeeded, 0 failed, 0 expired, 0 already there
2019-01-15T23:17:09Z Leaving block file 1636: CBlockFileInfo(blocks=144, size=133976289, heights=557764...558003, time=2019-01-09...2019-01-11)
2019-01-15T23:17:09Z Unable to open file /home/**/.bitcoin/blocks/blk01637.dat
2019-01-15T23:17:09Z Unable to open file /home/**/.bitcoin/blocks/blk01637.dat
2019-01-15T23:17:09Z ERROR: WriteBlockToDisk: OpenBlockFile failed
2019-01-15T23:17:09Z *** Failed to write block
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:37:10Z socket sending timeout: 1201s
2019-01-15T23:39:47Z ERROR: ProcessNewBlock: AcceptBlock FAILED (AcceptBlock: Failed to find position to write new block to disk (code 0))
2019-01-15T23:39:47Z tor: Thread interrupt
2019-01-15T23:39:47Z Shutdown: In progress...
2019-01-15T23:39:47Z addcon thread exit
2019-01-15T23:39:47Z opencon thread exit
2019-01-15T23:39:47Z torcontrol thread exit
2019-01-15T23:39:47Z net thread exit
2019-01-15T23:39:47Z msghand thread exit
2019-01-15T23:39:47Z scheduler thread interrupt
2019-01-15T23:39:47Z Dumped mempool: 3e-06s to copy, 0.000992s to dump
2019-01-15T23:39:47Z Unable to open file /home/**/.bitcoin/blocks/blk01637.dat
2019-01-15T23:39:55Z Unable to open file /home/**/.bitcoin/blocks/blk01637.dat
2019-01-15T23:39:56Z [default wallet] Releasing wallet
2019-01-15T23:39:56Z Shutdown: done

What can be done when a failure to open a file causes reindexing to fail?

Kipp Watson

Posted 2019-01-16T06:52:34.380

Reputation: 11

Please don't answer the question inside the question field. You can post an answer yourself. – Pieter Wuille – 2019-01-16T15:11:18.027

Thank you Pieter for all you have contributed to bitcoin core. I have edited my question as suggested, and I have given an answer as well. – Kipp Watson – 2019-01-17T16:21:58.120

Answers

1

An exhaustive survey of Google searches relating to the failure to read blknnnn.dat files implicated data corruption on the hard drive or in files such as wallet.dat and/or blknnnn.dat. In my case, however, I was able to rule out these factors. I ruled out hard drive failure by using a clone of my virtual machine that ran on a substitute hard drive. I also ruled out corruption in wallet.dat by reindexing a substituted wallet.dat that had recently worked fine. In this case the file that could not be opened was blk1637.dat. After about four unsuccessful reindexing attempts, I looked at the file permissions for the defective block and noted that file permissions were only allowed for root user. Prior blocks were permissioned for a non-root user. The obvious solution to this lack of uniformity in file permissions was to conform the file permission settings of the errant file, but alas making this change and then reindexing the chain did not work, for the same failure to open the block file happened again. I noted a comment someone made in a Google search that init.cpp in the client software used the umask command to change file permissions for the block files. Using the sudo command saved me in this situation. After all, I have everything contained within a virtual machine environment and this security risk was nominal. In the appropriate folder, I ran sudo ./bitcoin-qt, waited for it to catch up with the syncing, then I started up Armory. Ordinarily, using sudo in order to force a resort to root privileges is not a good idea. But in this case it enabled me to transfer my bitcoin to a hardware wallet, freeing me up to run a new node on a virtual machine where the block data files have a consistent 6 0 0 file permissions setting unaltered by an errant system shutdown.

Kipp Watson

Posted 2019-01-16T06:52:34.380

Reputation: 11

Asked: 2019-01-16T06:52:34.380

Viewed: 131 times

Active: 2019-02-16T17:02:00.413