bitcoind hang on 'move' command (solved)

[dooferorg]

I have a few bitcoin 'accounts' on my particular instance. I know these accounts are pretty mythical, but I wanted to clean things up a bit. I have this:

{
    "" : -5.51065462,
    "acct1" : 4.48588183,
    "acct2" : 1.02477279
}

when I issue the command

bitcoind move acct1 "" 4.48588183

it just hangs for hours. I have killed off the bitcoind (because it then stops listening to even a 'stop' command) and tried again after restarting. Same thing. Tried a remake of the wallet by repimporting dumped private keys from the previous wallet. The 'balances' there show up again, but I cannot get it to be resolved.

I moved off all coins from that wallet (total ends up as zero) but it has addresses would like to keep and use.

Any hints to resolve this?

[zvs]

I have a few bitcoin 'accounts' on my particular instance. I know these accounts are pretty mythical, but I wanted to clean things up a bit. I have this:

{
    "" : -5.51065462,
    "acct1" : 4.48588183,
    "acct2" : 1.02477279
}

when I issue the command

bitcoind move acct1 "" 4.48588183

it just hangs for hours. I have killed off the bitcoind (because it then stops listening to even a 'stop' command) and tried again after restarting. Same thing. Tried a remake of the wallet by repimporting dumped private keys from the previous wallet. The 'balances' there show up again, but I cannot get it to be resolved.

I moved off all coins from that wallet (total ends up as zero) but it has addresses would like to keep and use.

Any hints to resolve this?

does acct1 have like 10,000 satoshi dice returns?  or just normal usage?

[dooferorg]

The main amount that I use the 'sendtoaddress' on (my big mistake I now know   ) was 1 transaction to clear most of that wallet. A subsequent other transaction was made (1 day later) to clear the remainder. Both transactions have cleared according to looking at the receiving account and 'listtransactions' to check the number of confirmations done.

So I'm confused as to why it's just sitting there. I was hoping it would just get to realizing "Yup, I have no coins, all zero'd" and be done with it.

Also, the bitcoind in question is connected to 8 peers and appears (or at least was until it hung) to be synchronized to the latest block.

[dooferorg]

For the sake of completeness, I thought I'd post how I solved this.

- I extracted the private keys of the addresses I had received coins to and saved them to a text file along with the expected address

- I recompiled the 0.7 release from source. Moved it in place of the old binary (when it was all shut down)

- Moved the whole .bitcoin directory out of my home directory (I'm under Linux, doing this, by the way)

- Started bitcoin with '-daemon -rescan' options and waited for a day or more to let it sync up.

- During that time I imported the private keys into the new 'fresh' wallet. The 'listaccounts' operation showed the accounts with the incorrect balances. All of them still adding up to zero though.

- Once synced, I issued the move commands and within just a few seconds I received the 'true' statement.

So, just clearing and resetting things seemed to do the trick. I never did get any more information about what happened, even with the -debug option enabled. Marking this as 'solved'.

[arsenische]

I have a similar problem.

When I call bitcoind move, bitcoind becomes unresponsive to bitcoind getinfo and other RPC calls (but bitcoind help works).

My wallet file is about 60 mb, it contains 30k+ addresses (not sure if it matters) and few accounts. Logs look like that:

Code:

11/05/12 19:13:34 ThreadRPCServer method=move                                                                                                  
11/05/12 19:13:34 connection timeout                                                                                                           
11/05/12 19:13:34 trying connection 89.132.10.252:8333 lastseen=6.6hrs                                                                         
11/05/12 19:13:34 connect() failed after select(): Connection refused                                                                          
...
11/05/12 19:15:06 send version message: version 60002, blocks=206627, us=78.46.69.81:8333, them=98.229.49.176:8333, peer=98.229.49.176:8333    
11/05/12 19:16:13 Flushed 12274 addresses to peers.dat  160ms                                                                                  
11/05/12 19:17:54 Flushed 12274 addresses to peers.dat  171ms                                                                                  
11/05/12 19:18:49 accepted connection 152.2.31.91:36492                                                                                        
11/05/12 19:18:59 socket closed                                                                                                                
11/05/12 19:18:59 disconnecting node 152.2.31.91:36492                                                                                         
11/05/12 19:19:34 Flushed 12274 addresses to peers.dat  163ms                                                                                  
11/05/12 19:19:38 ThreadRPCServer method=getinfo                                                                                               
11/05/12 19:21:14 Flushed 12274 addresses to peers.dat  155ms                                                                                  
...

Rescan takes 4277485ms, but it doesn't help.

I looked into sources, "move" operation looks trivial: it debits amount from one account and credits to another (didn't dig too deep into it though). What could go wrong there? Should it take more time than just few ms to execute?

[2112]

What could go wrong there? Should it take more time than just few ms to execute?

Probably a dedlock. If you can build the bitcoind yourself you can quickly debug it further with db_stat. Just build the BerkelyDB utilities with exactly the same settings as the BerkeleyDB library.

Then create DB_CONFIG file containing single line "set_lg_dir database".

After that you should be able to monitor the live BerkeleyDB environment using db_stat and db_deadlock.

Well, at least this is how it worked with previous versions of bitcoind. I haven't tested this with the most recent ones.

[osoverflow]

same problem with 0.7.1 version. Rolling back to 0.7.0 to see if there is that problem there.

[osoverflow]

the 0.7.0 version does not have the problem. I'm staying with that version until a more stable version arrives.

[kjj]

Heh.  I had the exact same problem with 0.7.0 and it hasn't happened to me since I moved up to 0.7.1.

[osoverflow]

wow! that weird! why I had the problem with 0.7.1 and not with 0.7.0, and you the inverse! hahahaahahah.

[lightbox]

I'm having the exact same problem here on 0.7.1

>bitcoind move fromaccount toaccount 2

just hangs the RPC, and blocks all other RPC commands

i dont know if the "connection timeout" right after the "method=move" in the logs is from the move, or just from all the other stuff its doing (probably the later)

debug.log shows:
ThreadRPCServer method=move
connection timeout

but my only way to recover from this is
1) "bitcoind stop"
2) wait for the debug log to be pretty much done, just waiting on the ThreadRPCServer
3) kill -9 <pid of bitcoind>
4) bitcoind -daemon

Nothing fishy going on at all, its a pretty empty wallet, just put some stuff in it to test a web-app im working on.... this makes the web-app completely die as well, as it doesnt even throw an exception in PHP, it just sits there waiting forever, until the php script times out.

Any suggestions?!

[arsenische]

Any suggestions?!

There was a suggestion to debug a possible deadlock:

What could go wrong there? Should it take more time than just few ms to execute?

Probably a dedlock. If you can build the bitcoind yourself you can quickly debug it further with db_stat. Just build the BerkelyDB utilities with exactly the same settings as the BerkeleyDB library.

Then create DB_CONFIG file containing single line "set_lg_dir database".

After that you should be able to monitor the live BerkeleyDB environment using db_stat and db_deadlock.

Well, at least this is how it worked with previous versions of bitcoind. I haven't tested this with the most recent ones.

Not sure if I find time to set up the environment and learn BrerkleyDB tools. Maybe someone else could do it

Maybe the topic should be renamed as it is [not solved]

[lightbox]

okay just working with sipa on IRC, and tried a patch which has now solved the problem for my specific case.

The fix is here:

https://github.com/sipa/bitcoin/commits/fixmove

hopefully that'll get into the next released version

Thanks sipa!!