Author Topic: 0.4.23: an instance of Bitshares already running WIN7  (Read 1931 times)

0 Members and 1 Guest are viewing this topic.

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 739
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #15 on: December 23, 2014, 09:31:15 pm »
@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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #16 on: December 23, 2014, 10:33:11 pm »
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
I speak for myself and only myself.

Offline vikram

Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #17 on: December 24, 2014, 06:17:16 am »
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

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #18 on: December 24, 2014, 06:40:25 am »
I had to delete everything in datadir to solve it
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline modprobe

Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #19 on: January 06, 2015, 03:49:12 pm »
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?

Offline svk

Re: 0.4.23: an instance of Bitshares already running WIN7
« Reply #20 on: January 06, 2015, 04:45:28 pm »
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.
Worker: dev.bitsharesblocks