issues with bitcoin-cli loadwallet command

10 replies 499 views
Posts: 12 · Reputation: 184
#1Apr 2, 2018, 02:06 AM
I'm dealing with a weird issue and I'm curious if anyone else has faced this. So, when I run a command in console A, the bitcoind (Daemon console) in console B shows: [walletname] Wallet completed loading in 2368ms But here’s the catch: the command I executed in console A doesn't give me the prompt back right away. I end up waiting like 8 to 9 minutes before I finally get my prompt back. I need to run another command after that, and it just drags on. If I hit Ctrl+C, I just mess up the loadwallet process and have to stop the daemon, restart it, and then try loading the wallet again. It’s a small wallet with only 8-10 BTC addresses, so I don't get why it's taking so long. I'm on the latest btc daemon and tools. Anyone got any tips to fix this?
4 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#2Apr 4, 2018, 07:22 AM
How long is it between the "Wallet completed loading" message and a message that says "setKeyPool.size() ="? Although the completion line is logged near the end of the loading process, there is still a bit more that it does afterwards. In particular, if your wallet is not fully synced, it will do a scan of the blocks that have occurred since the wallet was last loaded, and depending on how long that is, it can take a while. Having to use walletpassphrase after loading a wallet is expected if your wallet is encrypted. I'm not sure what you're expecting with that.
0 Reply Quote Share
Posts: 12 · Reputation: 184
#3Apr 4, 2018, 01:09 PM
Thank you for your response. Well, nothing. I know it is expected. I am saying the delay because of loadwallet is a hindrance since I want to run the walletpassphrase command. I ran a benchmark again as per your enquiry. The  setKeyPool.size() message appears exactly around the timestamp when I get my prompt back. So when the system is rebooted, it takes around 8 to 9 minutes. This time I did a bitcoin-cli stop and re-ran the daemon and the attempt to load the wallet took 4.5 minutes. That's when the prompt was returned back and the setKeyPool.size() message was echoed back.
0 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#4Apr 6, 2018, 09:06 PM
Between the "loading completed" and "setKeyPool.size" lines, do you also see log lines like "Rescanning last X blocks (from block Y)...", "Still rescanning." "Scanning current mempool transactions" and "Recsan completed in"? It's probably spending those several minutes doing the rescan. How long the rescan takes depends on how far behind the wallet is from the node's tip. If you are unloading the wallet but letting the node remain operational, then you're going to run into this a lot.
3 Reply Quote Share
Posts: 12 · Reputation: 184
#5Apr 6, 2018, 09:56 PM
Do you mean the delay can only be minimized / eliminated if the node is always current and fully synced? If I stop bitcoin daemon and come back after a week, the wallet loading will take more than expected?
1 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#6Apr 6, 2018, 10:09 PM
No, the wallet just needs to be in sync with the node.
3 Reply Quote Share
Posts: 12 · Reputation: 184
#7Apr 7, 2018, 04:12 AM
I had kept the system off for some time to conduct a test. I just ran and I am 147 blocks behind. I tried to load my wallet and I got the prompt back within a second. The command just ran as it should, no delays. Not sure whether it is because earlier my node was lagging behind a lot. There were no 'rescanning' messages seen, atleast not now. Pardon my ignorance but what does 'the wallet just needs to be in sync with the node' mean? Isn't that the same as having the blocks current, because the wallet actually fetches info from my node. Thanks.
2 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#8Apr 7, 2018, 08:59 AM
The wallet maintains its own state separate from the blockchain and other node related things. This only happens if that particular wallet is loaded. You may have Bitcoin Core running without any wallet being loaded - Bitcoin Core is still functioning as a node as it downloads and validates all blocks and transactions. The same would happen if just that specific wallet wasn't loaded but others were - those other wallets would be updated, but the unloaded ones are not. So when you load the wallet again, Bitcoin Core will not have looked for any transactions that pertain to the wallet. It does that on loading, which is why you see it take a while.
0 Reply Quote Share
HumbleBullFull Member
Posts: 54 · Reputation: 378
#9Apr 7, 2018, 10:27 AM
Can you give us a hardware description, maybe you are running this on a raspberry pi, which would explain why the delay, or maybe it's an old machine with low resources. If you are running in linux you can concatenate the commands; Or even use the sleep command between both commands: It will not make it go faster, but you can leave it running and come back later once all is loaded.
2 Reply Quote Share
Posts: 12 · Reputation: 184
#10Apr 7, 2018, 01:14 PM
Hi, yes it is indeed an old system, but enough to act as a full node. Not mining though lol Aware of ; and sleep. Thanks achow101 and seoincorporation for the clarifications. I tried to give you both sMerits but I don't have any
3 Reply Quote Share
LuckyCoinLegendary
Posts: 832 · Reputation: 4795
#11Apr 7, 2018, 05:55 PM
An old system? How old is the hard disk inside the computer if you don't mind me asking? And is it an HDD or SSD? The older a hard disk gets, the more bad sectors it forms which generally slow down read operations in any program. It could make reads take several seconds to complete for instance. You can't even kill a program in linux with SIGKILL while it's blocked by an I/O read or write. I'm not sure if SSDs have this sort of problem but I don't think there is one in your computer.
3 Reply Quote Share
?Reply
Sign in to reply to this topic

Related topics