Topic: Client hangs at "Bitcoin Core is shutting down..." window (Read 5337 times)
With each new release of Bitcoin-QT, the prospect that it will leave the block list damaged has increased. I appreciate all the recommendations for how we can manually piece together the remnants of a forced shutdown (kill) of the BitCoin-Qt process. But perhaps what we really need is some protection so that the next execution of BitCoin-Qt will figure out what is good and what is not and reinstate itself. Too often I've run into Bitcoin-QT going CPU crazy and having to be put down. Can't it leave some checkpoints to save the user from having to fix it on his own?
Alright great, thank you for the additional info, very helpful!
Ok this might be a dumb question, but when copying the "blocks" and "chainstate" folders to a machine that has never had bitcoin installed, should I manually create the ~/.bitcoin folder on the target, then install the bitcoin-qt client, run it, and allow it to create the rest of the files it needs? I recall when you first launch bitcoin-qt it knows it hasn't been run before and asks if it should create a structure for you. I just want to make sure nothing gets overwritten after launch.
I'm not saying that this is the only way, but I always just install bitcoin-qt, run it once, shut it down, and then copy the "blocks" and "chainstate" folders. When it askes to merge folders I say yes, then let it replace any duplicate files. I'm not sure what would happen if you did it your way.**EDIT** is there any reason why I shouldn't just tar the entire ~/.bitcoin folder and plop it onto another computer? I was thinking that way I would have a complete copy of everything (blockchain and wallet) and not have to worry.
Thanks!
The only issue I see there is the duplicate wallet. If you use a wallet in two places with bitcoin-qt it will eventually "split". When you generate a new recieving address or send a transaction bitcion-qt uses a new address. So if you create a recieving address on one instance, and then send coins to it, then only that instance of the wallet will have access to those coins. This is partially remedied by the use of a "keypool", which is a bunch of pregenerated address stored in the wallet (default size is 100). However, the wallets will still "split" after the 100 address in the keypool have been used. Thanks!
Ok this might be a dumb question, but when copying the "blocks" and "chainstate" folders to a machine that has never had bitcoin installed, should I manually create the ~/.bitcoin folder on the target, then install the bitcoin-qt client, run it, and allow it to create the rest of the files it needs? I recall when you first launch bitcoin-qt it knows it hasn't been run before and asks if it should create a structure for you. I just want to make sure nothing gets overwritten after launch.
**EDIT** is there any reason why I shouldn't just tar the entire ~/.bitcoin folder and plop it onto another computer? I was thinking that way I would have a complete copy of everything (blockchain and wallet) and not have to worry.
Thanks!
**EDIT** is there any reason why I shouldn't just tar the entire ~/.bitcoin folder and plop it onto another computer? I was thinking that way I would have a complete copy of everything (blockchain and wallet) and not have to worry.
Thanks!
You can copy the blockchain you already have rather than resyncing every time. Just copy the "blocks" and "chainstate" folders. They're in the ~/.bitcoin directory. 
+1. This should solve the problem and saves a lot of time.
You can copy the blockchain you already have rather than resyncing every time. Just copy the "blocks" and "chainstate" folders. They're in the ~/.bitcoin directory.
Thanks much for the tip! This literally will save days of waiting
You can copy the blockchain you already have rather than resyncing every time. Just copy the "blocks" and "chainstate" folders. They're in the ~/.bitcoin directory.
Switched from 64 to 32 bit Ubuntu 14.04 just in case (it was running a bit slow as a VM on my host) but it did the same thing. Can I just tar up the .bitcoin folder and move it to another machine? I want to keep testing with other Linux distros but syncing the blockchain all day is brutal.
I've had this happen to me every so often.
yes happens to me periodically...
Currently running v0.9.1.0-g026a939-beta from the bitcoin ppa repository on Ubuntu 14.04 LTS. However, this was the exact same behavior with the standard Linux tgz bin file from bitcoin.org (which I tried first, on another installation).
Fresh installation of Ubuntu (running on VMWare Player), and fresh installation of the core client. I let it do its massive day-long, multi GB update to sync the blockchain (twice now!) and after it's all done, and letting it rest for a few hours 'just in case', when I go to exit the client, the "Bitcoin Core is shutting down..." window appears and doesn't go away.
Has anyone else experienced this? Any way I can get this window to go away and the client to shut down cleanly? There is nothing in db.log and here's the last part of debug.log
2014-04-29 21:00:37 Requesting shutdown
2014-04-29 21:00:37 Running Shutdown in thread
2014-04-29 21:00:38 addcon thread interrupt
2014-04-29 21:00:38 net thread interrupt
2014-04-29 21:00:38 msghand thread interrupt
2014-04-29 21:00:38 opencon thread interrupt
2014-04-29 21:00:38 dumpaddr thread stop
Thanks
**EDIT** gave up waiting and force closed it.. an additional entry showed up in debug.log
2014-04-30 01:57:15 Stopping thread
Fresh installation of Ubuntu (running on VMWare Player), and fresh installation of the core client. I let it do its massive day-long, multi GB update to sync the blockchain (twice now!) and after it's all done, and letting it rest for a few hours 'just in case', when I go to exit the client, the "Bitcoin Core is shutting down..." window appears and doesn't go away.
Has anyone else experienced this? Any way I can get this window to go away and the client to shut down cleanly? There is nothing in db.log and here's the last part of debug.log
2014-04-29 21:00:37 Requesting shutdown
2014-04-29 21:00:37 Running Shutdown in thread
2014-04-29 21:00:38 addcon thread interrupt
2014-04-29 21:00:38 net thread interrupt
2014-04-29 21:00:38 msghand thread interrupt
2014-04-29 21:00:38 opencon thread interrupt
2014-04-29 21:00:38 dumpaddr thread stop
Thanks
**EDIT** gave up waiting and force closed it.. an additional entry showed up in debug.log
2014-04-30 01:57:15 Stopping thread
Jump to: