0.4.23: an instance of Bitshares already running WIN7

[svk]

This error is shown when LevelDB throws an error saying the database is locked by another process. The LOCK files in the _db folders do not appear to get deleted by LevelDB under any circumstances (which is weird) and deleting them has no apparent effect.

In practice, the GUI will *only* show this error if the CLI client is running with the data dir the GUI intends to use; when another instance of the GUI is running, it's smart enough to just bring up the old instance of the GUI rather than trying to start a second one and running into this issue.

Are you sure you don't have a CLI client running somewhere?

While I've never seen this error after my original post which was on v0.4.23, I just wanna say that I was getting the error on the initial launch of the client after a clean install, so there was something else going on than a previous instance running or an improper exit.

[modprobe]

This error is shown when LevelDB throws an error saying the database is locked by another process. The LOCK files in the _db folders do not appear to get deleted by LevelDB under any circumstances (which is weird) and deleting them has no apparent effect.

In practice, the GUI will *only* show this error if the CLI client is running with the data dir the GUI intends to use; when another instance of the GUI is running, it's smart enough to just bring up the old instance of the GUI rather than trying to start a second one and running into this issue.

Are you sure you don't have a CLI client running somewhere?

[cn-members]

I had to delete everything in datadir to solve it

[vikram]

Yea this happened to me too.  This is windows 8.  Unfortunately there are lots of LOCK files.  So I am deleting all of them.  I run it again and I get the same error.  Task Manager has no Bitshares client running.  I know there was a bad shutdown that started this problem, then it crashed and I believe tried resetting the DB when it crashed again.  Now it won't try to reset the DB. :(

$ find . -name LOCK -print
./chain/index/account_db/LOCK
./chain/index/account_index_db/LOCK
./chain/index/address_to_account_db/LOCK
./chain/index/address_to_trx_db/LOCK
./chain/index/ask_db/LOCK
./chain/index/asset_db/LOCK
./chain/index/asset_proposal_db/LOCK
./chain/index/auth_db/LOCK
./chain/index/balance_db/LOCK
./chain/index/bid_db/LOCK
./chain/index/block_id_to_block_record_db/LOCK
./chain/index/burn_db/LOCK
./chain/index/collateral_db/LOCK
./chain/index/delegate_vote_index_db/LOCK
./chain/index/edge_index/LOCK
./chain/index/feed_db/LOCK
./chain/index/fork_db/LOCK
./chain/index/fork_number_db/LOCK
./chain/index/future_blocks_db/LOCK
./chain/index/id_to_transaction_record_db/LOCK
./chain/index/market_history_db/LOCK
./chain/index/market_status_db/LOCK
./chain/index/market_transactions_db/LOCK
./chain/index/object_db/LOCK
./chain/index/pending_transaction_db/LOCK
./chain/index/property_db/LOCK
./chain/index/relative_ask_db/LOCK
./chain/index/relative_bid_db/LOCK
./chain/index/reverse_edge_index/LOCK
./chain/index/short_db/LOCK
./chain/index/slate_db/LOCK
./chain/index/slot_record_db/LOCK
./chain/index/symbol_index_db/LOCK
./chain/index/undo_state_db/LOCK
./chain/raw_chain/block_id_to_block_data_db/LOCK
./chain/raw_chain/block_num_to_id_db/LOCK
./exceptions/LOCK
./mail_client/archive/LOCK
./mail_client/inbox/LOCK
./mail_client/processing/LOCK
./mail_client/properties/LOCK
./peers.leveldb/LOCK

I don't think you should delete these. These are the LevelDB lock files and I always have them on everything too.

As David Brown speculates, the problem is the Qt GUI client is detecting the existence of that lock file, which makes it think there is another copy of the program running. This lock file should be deleted when the program exits normally, but it can stay around if the client terminates improperly. The best way to eliminate this error is to delete the lock file, then launch the client again.

I believe this is referring to some other magic file that we have implemented. I'm not familiar with it either but have made a note about this issue here: https://github.com/BitShares/qt_wallet/issues/82

[gamey]

So I deleted the lock files and tried this. 

I'll let you decide if there is value in this but it seems maybe the exception handling could be straightened out a bit to not lead people down the wrong path?

I deleted the peers.leveldb directory and it appears to be going further now.  Actually I guess it is grabbing the whole blockchain at this point.

------------ error --------------
10001 db_in_use_exception: Database in Use
Unable to open database C:/Users/b/AppData/Roaming/BitShares/peers.leveldb
        Corruption: error in middle of record
    {"db":"C:/Users/b/AppData/Roaming/BitShares/peers.leveldb","msg":"Corruption
: error in middle of record"}
    p2p  level_pod_map.hpp:62 bts::db::level_pod_map<unsigned int,struct bts::ne
t::potential_peer_record>::open

    {"dir":"C:/Users/b/AppData/Roaming/BitShares/peers.leveldb","create":true,"c
ache_size":0}
    p2p  level_pod_map.hpp:67 bts::db::level_pod_map<unsigned int,struct bts::ne
t::potential_peer_record>::open

[dannotestein]

@gamey, I'm not sure which files the GUI is detecting that's making it think another instance is running, but there is a decent chance it can be fixed with the command-line client as below:

From a command prompt, run:
c:\Bitsharesx\bin\bitshares\bitshares_client.exe --rebuild-index

After that finishes, type "quit", then relaunch the GUI version after the cmdline client quits.

[gamey]

Yea this happened to me too.  This is windows 8.  Unfortunately there are lots of LOCK files.  So I am deleting all of them.  I run it again and I get the same error.  Task Manager has no Bitshares client running.  I know there was a bad shutdown that started this problem, then it crashed and I believe tried resetting the DB when it crashed again.  Now it won't try to reset the DB. :(

$ find . -name LOCK -print
./chain/index/account_db/LOCK
./chain/index/account_index_db/LOCK
./chain/index/address_to_account_db/LOCK
./chain/index/address_to_trx_db/LOCK
./chain/index/ask_db/LOCK
./chain/index/asset_db/LOCK
./chain/index/asset_proposal_db/LOCK
./chain/index/auth_db/LOCK
./chain/index/balance_db/LOCK
./chain/index/bid_db/LOCK
./chain/index/block_id_to_block_record_db/LOCK
./chain/index/burn_db/LOCK
./chain/index/collateral_db/LOCK
./chain/index/delegate_vote_index_db/LOCK
./chain/index/edge_index/LOCK
./chain/index/feed_db/LOCK
./chain/index/fork_db/LOCK
./chain/index/fork_number_db/LOCK
./chain/index/future_blocks_db/LOCK
./chain/index/id_to_transaction_record_db/LOCK
./chain/index/market_history_db/LOCK
./chain/index/market_status_db/LOCK
./chain/index/market_transactions_db/LOCK
./chain/index/object_db/LOCK
./chain/index/pending_transaction_db/LOCK
./chain/index/property_db/LOCK
./chain/index/relative_ask_db/LOCK
./chain/index/relative_bid_db/LOCK
./chain/index/reverse_edge_index/LOCK
./chain/index/short_db/LOCK
./chain/index/slate_db/LOCK
./chain/index/slot_record_db/LOCK
./chain/index/symbol_index_db/LOCK
./chain/index/undo_state_db/LOCK
./chain/raw_chain/block_id_to_block_data_db/LOCK
./chain/raw_chain/block_num_to_id_db/LOCK
./exceptions/LOCK
./mail_client/archive/LOCK
./mail_client/inbox/LOCK
./mail_client/processing/LOCK
./mail_client/properties/LOCK
./peers.leveldb/LOCK

[dannotestein]

As David Brown speculates, the problem is the Qt GUI client is detecting the existence of that lock file, which makes it think there is another copy of the program running. This lock file should be deleted when the program exits normally, but it can stay around if the client terminates improperly. The best way to eliminate this error is to delete the lock file, then launch the client again.

[davidpbrown]

This is a wild guess especially since I'm not on Windows but I see there is a LOCK file in the wallets/default .. or whatever name your wallet is. Oddly the instance that I had was from August.. size is 0 bits.. so I deleted it and restarted and it reappears.. what doesn't happen that I wonder should is that it gets removed on qt shutdown. So, perhaps that is causing more confusion in Windows.. since that kind of lock file existing can stop and confuse other programs tracking of its state.

[fuzzy]

I just installed the wallet on my Windows 7 64 partition and I get a strange error immediately after the splash screen:



I say strange because obviously there isn't another instance running.. Anyone seen this before? Anyone have a fix?

I tried uninstalling then re-installing, same thing. Oh and uninstalling just removed my wallet and all blockchain data with no warning, kind of annoying..

Actually having this same problem as we speak.  On the client 4.27.1

[mira]

So I failed to update to 4.23.1 - i had ended up with 4.22 again.  What step am I missing to update?

(but I did get rid of that error of another instance running)

[mira]

Same error message after updating.  Will have to approach it fresh tomorrow  :-[

[svk]

I'm on linux mint 17.  Installed client and GUI.

So I just reinstall as before!  That seemed to simple to be true.   :)

Thank you!

Yea just delete the folder of the client that wasn't working, then reinstall as before but using the latest version :) Don't touch the .BitsharesX folder though cause that's where your wallet is.

[mira]

I'm on linux mint 17.  Installed client and GUI.

So I just reinstall as before!  That seemed to simple to be true.   :)

Thank you!

[svk]

The instructions here work fine for me in Ubuntu, is that what you're using?

https://github.com/dacsunlimited/bitsharesx/blob/master/BUILD_UBUNTU.md

Are you trying to compile the client only or the GUI as well under linux?

[mira]

No, I haven't tried 4.23.1 yet.  This was the first time I'd compiled from source, and am not confident how to update.  Could you advise?  Or should I move this to the stupid questions thread....?

[svk]

Was resolved for me with v0.4.23.1, did you try that?

I never saw this on Linux though.

[mira]

I'm getting this same error message on a Linux installation that was previously working.

Prior to receiving this message it needed to rebuild the database, but hung for so many hours I terminated.  After that trying to restart I get the message "An instance of BitShares X is already running!  Please close it and try again" as soon as it tries to rebuild the database.

Using command ps -ef shows no other instance running. 

Any suggestions of how to resolve?

[svk]

I had something similar but not exactly the same.

I tried to install v0.4.23 on a windows machine where no version of the client has ever been installed.  I didn't get the End User Agreement as is normally the case when installing new, but instead the program behaved as if I already had a wallet set up - asking me for my password.  I removed everything and tried v0.4.22 and everything worked as it should; first the End User Agreement, etc.

A fresh install of 0.4.22 gives me the exact same error as 0.4.23 :(

[blahblah7up]

I had something similar but not exactly the same.

I tried to install v0.4.23 on a windows machine where no version of the client has ever been installed.  I didn't get the End User Agreement as is normally the case when installing new, but instead the program behaved as if I already had a wallet set up - asking me for my password.  I removed everything and tried v0.4.22 and everything worked as it should; first the End User Agreement, etc.

[svk]

I just installed the wallet on my Windows 7 64 partition and I get a strange error immediately after the splash screen:



I say strange because obviously there isn't another instance running.. Anyone seen this before? Anyone have a fix?

I tried uninstalling then re-installing, same thing. Oh and uninstalling just removed my wallet and all blockchain data with no warning, kind of annoying..