bs prompt "Server stopped...."
paizzj opened this issue · comments
when use bs command sync the blockchians data, and kill the bs , then rerun the command as blew:
[root@jqs bs]# bs
1:51:31.213816 INFO [server] ================= startup ==================
11:51:31.213896 WARNING [server] ================= startup ==================
11:51:31.214022 ERROR [server] ================= startup ==================
11:51:31.214070 FATAL [server] ================= startup ==================
11:51:31.214117 INFO [server] Using default configuration settings.
11:51:31.214159 INFO [server] Please wait while the server is starting...
11:51:31.216686 ERROR [node] Failure starting blockchain.
11:51:31.216776 ERROR [server] Server failed to start with error, operation failed.
11:51:31.216922 INFO [server] Please wait while the server is stopping...
11:51:31.218906 INFO [node] Server stopped successfully.
bs version are 4.0.0
_[root@jqs bs]# bs --version
Version Information:
libbitcoin-server: 4.0.0
libbitcoin-protocol: 4.0.0
libbitcoin-node: 4.0.0
libbitcoin-blockchain: 4.0.0
libbitcoin: 4.0.0_
kill the bs
You killed it, it's dead :)
Also, master (version4) is staging for a future release; use of version3 is recommended.
but when restart bs commond, it cann't start successfully.
follow the wiki:
https://github.com/libbitcoin/libbitcoin-server/wiki/Frequently-Asked-Questions#q-what-sort-of-failure-will-corrupt-the-store
i have a questions :
when during sysncing blockchain data bs stopped , it is must to reinit( via "bs --initchain" ) and resync the blockchain data from the begining ?
It cannot start because the store is corrupt as the result of the process termination. If you terminate the process while the store has unflushed data, the store will always be corrupt. You must execute a controlled shutdown using <CTRL-C> when you stop the server. Otherwise the store is corrupt and must be synchronized.
Store corruption can result from process termination in most databases. Many applications will not detect such a failure, which can lead to consensus failures, incorrect data and/or segmentation faults. LevelDB, for example, is notorious for such failures:
LevelDB is widely noted for being unreliable and databases it manages are prone to corruption. Academic studies of past versions of LevelDB have found that, under some file systems, the data stored in those versions of LevelDB might become inconsistent after a system crash or power failure. LevelDB corruption is so commonplace that corruption detection has to be built into applications that use it.
https://en.wikipedia.org/wiki/LevelDB#Bugs_and_reliability
For this reason Bitcoin Core (which uses LevelDB) will test a certain number of blocks at startup in an attempt to identify corruption. However this is not a guarantee of store consistency following a hard shutdown. Libbitcoin (which does not use LevelDB) has guaranteed identification of hard shutdown corruption. If you terminate the process with an unflushed write the store is considered corrupt.
So what hapens when the power goes out? Everyone has to take 3 day's to resync?
If you are running with write flushing, yes. The BS is designed for query performance, not casual wallet use. Miners and servers - typically with imaging, power reliability and redundancy.
running on ubuntu right now was at block 300k something and my system froze. On restart I had the same issue.
00:28:15.809855 INFO [server] ================= startup ==================
00:28:15.809900 WARNING [server] ================= startup ==================
00:28:15.810013 ERROR [server] ================= startup ==================
00:28:15.810050 FATAL [server] ================= startup ==================
00:28:15.810092 INFO [server] Using default configuration settings.
00:28:15.810128 INFO [server] Please wait while the server is starting...
00:28:15.810605 ERROR [node] Failure starting blockchain.
00:28:15.810648 ERROR [server] Server failed to start with error, operation failed.
00:28:15.810772 INFO [server] Please wait while the server is stopping...
00:28:15.810951 INFO [node] Server stopped successfully.
I looked into the blockchain directory:
block_index block_table flush_lock history_rows history_table spend_table stealth_rows transaction_table
and deleted the flush_lock file
rm flush_lock
then I started bs again and started and picked up right where it left off
When you halt the process the flush lock indicates an unflushed write. The store is presumed (and very likely) corrupt, which produces undefined behavior if you proceed by deleting the lock.
Alright thanks, I'll start it fresh