-
Notifications
You must be signed in to change notification settings - Fork 36.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitcoind become unresponsive to CLI during UpdateTip phase. #16353
Comments
So this happens when you download the most recent blocks at the tip and an utxo set with a different tip from the internet, bypassing any validation? This is not a supported use case. |
What do you mean by that is not a supported use case? It works fine, and sync to the tip without issues. |
It sounds to me no different than an unclean shutdown (e.g. a power outage). It would be nice if the rpc did not time out and responded with a better error message, but ideally this should happen so rarely that it doesn't matter much. |
Any idea on how I could stop that import from happening in the first place (without editing the software)? |
Shutting down the node before you copy your datadir to a different location should fix that. Shutting down will interrupt the main thread, so that no new blocks are written to disk and the chainstate is flushed to disk, so that on startup it is in-sync with the tip. |
No, the utxo set is correct, and blocks are too (ie: the node has been correctly shutdown before backing it up, and the proof of that is that it's synching perfectly to the tip with the same backup, that's never been an issue).
|
See " Unbounded growth of scheduler queue #14289 " for a discussion of
|
IIUC @SylTi wants to interrupt ABC with invalidateblock? |
I'm not sure of what you mean by ABC but I would like to be able to interrupt the "UpdateTip" with invalidateblock, yes. |
@SylTi see #13477 and #13713, and take note of #13713 (comment) which I think is what you want. Edit: ABC means ActivateBestChain, see src/validation.cpp. |
Thanks for the links to those issues/pull requests. |
I don't know, but I suspect it is one of those hard changes. |
Closing as per #16827 (comment) |
When synching from blocks already available on disk on startup from a old utxo set, bitcoind become unresponsive during the UpdateTip phase:
I expect either it to work or to get an error like it's the case when trying to run a cli command during the "Verifying last 6 blocks at level 3" phase
Instead, I get the following timeout when trying to run this command:
This append every time I tried to run a command against it, either it be gettxoutsetinfo or invalidateblock
To reproduce the issue yourself you can :
❗️ backup your chainstate/blocks folder before or set DATADIR/DATA_PATH variable to a new location ❗️
This script require a bunch of disk space available.
What it does is basically download & import a chainstate synched at height = 577000 and around ~8go of blocks up to height 583832
Pre-compiled version of Bitcoin Core v0.18.0
bitcoind/cli are installed on the Windows 10 side on a hard drive but all commands are run through WSL, this setup works fine for everything else but that.
https://gist.githubusercontent.com/SylTi/7e7801e65f355edba3c460731a740d48/raw/bd81624934c42fb2cc45f0aabca3ca0386a516c7/bitcoind.log if you search for "invalid block" you will see some pretty weird stuff. Like the block height going up, then down, then up again.
This happend when the command I tried to run on the CLI was
invalidateblock 00000000000000000028b702b9da76f700cf3da9682553090f485a7281e57922
but it also timeout so it shouldn't have affected the sync? And if it did work while showing me a timeout, why did the sync restart after the block was invalidated?The text was updated successfully, but these errors were encountered: