2015-12-31 01:39:56 -05:00
|
|
|
// Copyright (c) 2014-2016, The Monero Project
|
2015-02-10 18:13:32 -05:00
|
|
|
//
|
|
|
|
// All rights reserved.
|
|
|
|
//
|
|
|
|
// Redistribution and use in source and binary forms, with or without modification, are
|
|
|
|
// permitted provided that the following conditions are met:
|
|
|
|
//
|
|
|
|
// 1. Redistributions of source code must retain the above copyright notice, this list of
|
|
|
|
// conditions and the following disclaimer.
|
|
|
|
//
|
|
|
|
// 2. Redistributions in binary form must reproduce the above copyright notice, this list
|
|
|
|
// of conditions and the following disclaimer in the documentation and/or other
|
|
|
|
// materials provided with the distribution.
|
|
|
|
//
|
|
|
|
// 3. Neither the name of the copyright holder nor the names of its contributors may be
|
|
|
|
// used to endorse or promote products derived from this software without specific
|
|
|
|
// prior written permission.
|
|
|
|
//
|
|
|
|
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
|
|
|
|
// EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
|
|
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
|
|
|
|
// THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
// STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
|
|
|
|
// THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
|
|
|
#include <atomic>
|
|
|
|
#include <cstdio>
|
|
|
|
#include <algorithm>
|
|
|
|
#include <fstream>
|
|
|
|
|
|
|
|
#include <boost/filesystem.hpp>
|
2015-05-08 16:46:26 -04:00
|
|
|
#include "bootstrap_file.h"
|
|
|
|
#include "bootstrap_serialization.h"
|
2015-02-10 18:13:32 -05:00
|
|
|
#include "cryptonote_core/cryptonote_format_utils.h"
|
2015-05-08 16:46:26 -04:00
|
|
|
#include "serialization/binary_utils.h" // dump_binary(), parse_binary()
|
2015-02-10 18:13:32 -05:00
|
|
|
#include "serialization/json_utils.h" // dump_json()
|
|
|
|
#include "include_base_utils.h"
|
2016-02-14 15:20:14 -05:00
|
|
|
#include "blockchain_db/db_types.h"
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-02-11 19:02:20 -05:00
|
|
|
#include <lmdb.h> // for db flag arguments
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
#include "fake_core.h"
|
|
|
|
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
#undef MONERO_DEFAULT_LOG_CATEGORY
|
|
|
|
#define MONERO_DEFAULT_LOG_CATEGORY "bcutil"
|
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
namespace
|
|
|
|
{
|
2015-02-10 18:13:32 -05:00
|
|
|
// CONFIG
|
2015-05-08 16:46:26 -04:00
|
|
|
bool opt_batch = true;
|
|
|
|
bool opt_verify = true; // use add_new_block, which does verification before calling add_block
|
|
|
|
bool opt_resume = true;
|
|
|
|
bool opt_testnet = true;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
// number of blocks per batch transaction
|
|
|
|
// adjustable through command-line argument according to available RAM
|
2016-02-17 15:10:26 -05:00
|
|
|
#if ARCH_WIDTH != 32
|
2015-05-08 16:46:26 -04:00
|
|
|
uint64_t db_batch_size = 20000;
|
|
|
|
#else
|
|
|
|
// set a lower default batch size, pending possible LMDB issue with large transaction size
|
2016-02-17 15:10:26 -05:00
|
|
|
uint64_t db_batch_size = 100;
|
2015-05-08 16:46:26 -04:00
|
|
|
#endif
|
|
|
|
|
|
|
|
// when verifying, use a smaller default batch size so progress is more
|
|
|
|
// frequently saved
|
|
|
|
uint64_t db_batch_size_verify = 5000;
|
|
|
|
|
|
|
|
std::string refresh_string = "\r \r";
|
|
|
|
}
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-03-22 13:57:24 -04:00
|
|
|
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
namespace po = boost::program_options;
|
|
|
|
|
|
|
|
using namespace cryptonote;
|
|
|
|
using namespace epee;
|
|
|
|
|
2015-02-11 19:02:20 -05:00
|
|
|
|
2016-02-14 16:39:14 -05:00
|
|
|
std::string join_set_strings(const std::unordered_set<std::string>& db_types_all, const char* delim)
|
|
|
|
{
|
|
|
|
std::string result;
|
|
|
|
std::ostringstream s;
|
|
|
|
std::copy(db_types_all.begin(), db_types_all.end(), std::ostream_iterator<std::string>(s, delim));
|
|
|
|
result = s.str();
|
|
|
|
if (result.length() > 0)
|
|
|
|
result.erase(result.end()-strlen(delim), result.end());
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2016-02-14 16:04:38 -05:00
|
|
|
// db_type: lmdb, berkeley
|
|
|
|
// db_mode: safe, fast, fastest
|
|
|
|
int get_db_flags_from_mode(const std::string& db_type, const std::string& db_mode)
|
|
|
|
{
|
|
|
|
uint64_t BDB_FAST_MODE = 0;
|
|
|
|
uint64_t BDB_FASTEST_MODE = 0;
|
|
|
|
uint64_t BDB_SAFE_MODE = 0;
|
|
|
|
|
|
|
|
#if defined(BERKELEY_DB)
|
|
|
|
BDB_FAST_MODE = DB_TXN_WRITE_NOSYNC;
|
|
|
|
BDB_FASTEST_MODE = DB_TXN_NOSYNC;
|
|
|
|
BDB_SAFE_MODE = DB_TXN_SYNC;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
int db_flags = 0;
|
|
|
|
bool islmdb = db_type == "lmdb";
|
|
|
|
if (db_mode == "safe")
|
|
|
|
db_flags = islmdb ? MDB_NORDAHEAD : BDB_SAFE_MODE;
|
|
|
|
else if (db_mode == "fast")
|
|
|
|
db_flags = islmdb ? MDB_NOMETASYNC | MDB_NOSYNC | MDB_NORDAHEAD : BDB_FAST_MODE;
|
|
|
|
else if (db_mode == "fastest")
|
|
|
|
db_flags = islmdb ? MDB_WRITEMAP | MDB_MAPASYNC | MDB_NORDAHEAD | MDB_NOMETASYNC | MDB_NOSYNC : BDB_FASTEST_MODE;
|
|
|
|
return db_flags;
|
|
|
|
}
|
|
|
|
|
2016-02-14 14:32:54 -05:00
|
|
|
int parse_db_arguments(const std::string& db_arg_str, std::string& db_type, int& db_flags)
|
2015-02-11 19:02:20 -05:00
|
|
|
{
|
|
|
|
std::vector<std::string> db_args;
|
|
|
|
boost::split(db_args, db_arg_str, boost::is_any_of("#"));
|
2016-02-14 14:32:54 -05:00
|
|
|
db_type = db_args.front();
|
|
|
|
boost::algorithm::trim(db_type);
|
2015-02-11 19:02:20 -05:00
|
|
|
|
|
|
|
if (db_args.size() == 1)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else if (db_args.size() > 2)
|
|
|
|
{
|
|
|
|
std::cerr << "unrecognized database argument format: " << db_arg_str << ENDL;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-02-14 16:04:38 -05:00
|
|
|
#if !defined(BERKELEY_DB)
|
|
|
|
if (db_type == "berkeley")
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("BerkeleyDB support disabled.");
|
2016-02-14 16:04:38 -05:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-02-11 19:02:20 -05:00
|
|
|
std::string db_arg_str2 = db_args[1];
|
|
|
|
boost::split(db_args, db_arg_str2, boost::is_any_of(","));
|
2016-02-14 16:04:38 -05:00
|
|
|
|
|
|
|
// optionally use a composite mode instead of individual flags
|
|
|
|
const std::unordered_set<std::string> db_modes {"safe", "fast", "fastest"};
|
|
|
|
std::string db_mode;
|
|
|
|
if (db_args.size() == 1)
|
|
|
|
{
|
|
|
|
if (db_modes.count(db_args[0]) > 0)
|
|
|
|
{
|
|
|
|
db_mode = db_args[0];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (! db_mode.empty())
|
|
|
|
{
|
|
|
|
db_flags = get_db_flags_from_mode(db_type, db_mode);
|
|
|
|
}
|
|
|
|
else
|
2015-02-11 19:02:20 -05:00
|
|
|
{
|
2016-02-14 16:04:38 -05:00
|
|
|
for (auto& it : db_args)
|
2016-02-14 15:20:14 -05:00
|
|
|
{
|
2016-02-14 16:04:38 -05:00
|
|
|
boost::algorithm::trim(it);
|
|
|
|
if (it.empty())
|
|
|
|
continue;
|
|
|
|
if (db_type == "lmdb")
|
2016-02-14 15:20:14 -05:00
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("LMDB flag: " << it);
|
2016-02-14 16:04:38 -05:00
|
|
|
if (it == "nosync")
|
|
|
|
db_flags |= MDB_NOSYNC;
|
|
|
|
else if (it == "nometasync")
|
|
|
|
db_flags |= MDB_NOMETASYNC;
|
|
|
|
else if (it == "writemap")
|
|
|
|
db_flags |= MDB_WRITEMAP;
|
|
|
|
else if (it == "mapasync")
|
|
|
|
db_flags |= MDB_MAPASYNC;
|
|
|
|
else if (it == "nordahead")
|
|
|
|
db_flags |= MDB_NORDAHEAD;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
std::cerr << "unrecognized database flag: " << it << ENDL;
|
|
|
|
return 1;
|
|
|
|
}
|
2016-02-14 15:20:14 -05:00
|
|
|
}
|
|
|
|
#if defined(BERKELEY_DB)
|
2016-02-14 16:04:38 -05:00
|
|
|
else if (db_type == "berkeley")
|
2016-02-14 15:20:14 -05:00
|
|
|
{
|
2016-02-14 16:04:38 -05:00
|
|
|
if (it == "txn_write_nosync")
|
|
|
|
db_flags = DB_TXN_WRITE_NOSYNC;
|
|
|
|
else if (it == "txn_nosync")
|
|
|
|
db_flags = DB_TXN_NOSYNC;
|
|
|
|
else if (it == "txn_sync")
|
|
|
|
db_flags = DB_TXN_SYNC;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
std::cerr << "unrecognized database flag: " << it << ENDL;
|
|
|
|
return 1;
|
|
|
|
}
|
2016-02-14 15:20:14 -05:00
|
|
|
}
|
|
|
|
#endif
|
2015-02-11 19:02:20 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-05-08 14:35:48 -04:00
|
|
|
template <typename FakeCore>
|
|
|
|
int pop_blocks(FakeCore& simple_core, int num_blocks)
|
|
|
|
{
|
|
|
|
bool use_batch = false;
|
|
|
|
if (opt_batch)
|
|
|
|
{
|
|
|
|
if (simple_core.support_batch)
|
|
|
|
use_batch = true;
|
|
|
|
else
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MWARNING("WARNING: batch transactions enabled but unsupported or unnecessary for this database type - ignoring");
|
2015-05-08 14:35:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (use_batch)
|
|
|
|
simple_core.batch_start();
|
|
|
|
|
|
|
|
int quit = 0;
|
|
|
|
block popped_block;
|
|
|
|
std::vector<transaction> popped_txs;
|
|
|
|
for (int i=0; i < num_blocks; ++i)
|
|
|
|
{
|
|
|
|
// simple_core.m_storage.pop_block_from_blockchain() is private, so call directly through db
|
|
|
|
simple_core.m_storage.get_db().pop_block(popped_block, popped_txs);
|
|
|
|
quit = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if (use_batch)
|
|
|
|
{
|
|
|
|
if (quit > 1)
|
|
|
|
{
|
|
|
|
// There was an error, so don't commit pending data.
|
|
|
|
// Destructor will abort write txn.
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
simple_core.batch_stop();
|
|
|
|
}
|
|
|
|
simple_core.m_storage.get_db().show_stats();
|
|
|
|
}
|
|
|
|
|
|
|
|
return num_blocks;
|
|
|
|
}
|
|
|
|
|
2015-02-10 18:13:32 -05:00
|
|
|
template <typename FakeCore>
|
2015-08-14 17:49:46 -04:00
|
|
|
int import_from_file(FakeCore& simple_core, const std::string& import_file_path, uint64_t block_stop=0)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2016-02-14 14:32:54 -05:00
|
|
|
if (std::is_same<fake_core_db, FakeCore>::value)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
|
|
|
// Reset stats, in case we're using newly created db, accumulating stats
|
|
|
|
// from addition of genesis block.
|
|
|
|
// This aligns internal db counts with importer counts.
|
2015-03-22 13:57:18 -04:00
|
|
|
simple_core.m_storage.get_db().reset_stats();
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
2015-08-14 17:49:46 -04:00
|
|
|
boost::filesystem::path fs_import_file_path(import_file_path);
|
2015-02-10 18:13:32 -05:00
|
|
|
boost::system::error_code ec;
|
2015-08-14 17:49:46 -04:00
|
|
|
if (!boost::filesystem::exists(fs_import_file_path, ec))
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("bootstrap file not found: " << fs_import_file_path);
|
2015-02-10 18:13:32 -05:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
BootstrapFile bootstrap;
|
|
|
|
// BootstrapFile bootstrap(import_file_path);
|
|
|
|
uint64_t total_source_blocks = bootstrap.count_blocks(import_file_path);
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("bootstrap file last block number: " << total_source_blocks-1 << " (zero-based height) total blocks: " << total_source_blocks);
|
2015-05-08 16:46:26 -04:00
|
|
|
|
|
|
|
std::cout << ENDL;
|
|
|
|
std::cout << "Preparing to read blocks..." << ENDL;
|
|
|
|
std::cout << ENDL;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
std::ifstream import_file;
|
|
|
|
import_file.open(import_file_path, std::ios_base::binary | std::ifstream::in);
|
|
|
|
|
|
|
|
uint64_t h = 0;
|
2015-05-08 16:46:26 -04:00
|
|
|
uint64_t num_imported = 0;
|
2015-02-10 18:13:32 -05:00
|
|
|
if (import_file.fail())
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("import_file.open() fail");
|
2015-02-10 18:13:32 -05:00
|
|
|
return false;
|
|
|
|
}
|
2015-05-08 16:46:26 -04:00
|
|
|
|
|
|
|
// 4 byte magic + (currently) 1024 byte header structures
|
|
|
|
bootstrap.seek_to_first_chunk(import_file);
|
|
|
|
|
|
|
|
std::string str1;
|
|
|
|
char buffer1[1024];
|
2015-02-10 18:13:32 -05:00
|
|
|
char buffer_block[BUFFER_SIZE];
|
|
|
|
block b;
|
|
|
|
transaction tx;
|
|
|
|
int quit = 0;
|
|
|
|
uint64_t bytes_read = 0;
|
|
|
|
|
|
|
|
uint64_t start_height = 1;
|
|
|
|
if (opt_resume)
|
|
|
|
start_height = simple_core.m_storage.get_current_blockchain_height();
|
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
// Note that a new blockchain will start with block number 0 (total blocks: 1)
|
2015-02-10 18:13:32 -05:00
|
|
|
// due to genesis block being added at initialization.
|
|
|
|
|
2015-05-15 20:14:36 -04:00
|
|
|
if (! block_stop)
|
2015-05-08 16:54:46 -04:00
|
|
|
{
|
2015-05-15 20:14:36 -04:00
|
|
|
block_stop = total_source_blocks - 1;
|
2015-05-08 16:54:46 -04:00
|
|
|
}
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
// These are what we'll try to use, and they don't have to be a determination
|
2015-05-08 16:46:26 -04:00
|
|
|
// from source and destination blockchains, but those are the defaults.
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("start block: " << start_height << " stop block: " <<
|
2015-05-15 20:14:36 -04:00
|
|
|
block_stop);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
bool use_batch = false;
|
|
|
|
if (opt_batch)
|
|
|
|
{
|
|
|
|
if (simple_core.support_batch)
|
|
|
|
use_batch = true;
|
|
|
|
else
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MWARNING("WARNING: batch transactions enabled but unsupported or unnecessary for this database type - ignoring");
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
if (use_batch)
|
2015-07-11 15:32:49 -04:00
|
|
|
simple_core.batch_start(db_batch_size);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Reading blockchain from bootstrap file...");
|
2015-02-10 18:13:32 -05:00
|
|
|
std::cout << ENDL;
|
|
|
|
|
|
|
|
// Within the loop, we skip to start_height before we start adding.
|
|
|
|
// TODO: Not a bottleneck, but we can use what's done in count_blocks() and
|
|
|
|
// only do the chunk size reads, skipping the chunk content reads until we're
|
|
|
|
// at start_height.
|
|
|
|
while (! quit)
|
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
uint32_t chunk_size;
|
|
|
|
import_file.read(buffer1, sizeof(chunk_size));
|
|
|
|
// TODO: bootstrap.read_chunk();
|
2015-02-10 18:13:32 -05:00
|
|
|
if (! import_file) {
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("End of file reached");
|
2015-02-10 18:13:32 -05:00
|
|
|
quit = 1;
|
|
|
|
break;
|
|
|
|
}
|
2015-05-08 16:46:26 -04:00
|
|
|
bytes_read += sizeof(chunk_size);
|
|
|
|
|
|
|
|
str1.assign(buffer1, sizeof(chunk_size));
|
|
|
|
if (! ::serialization::parse_binary(str1, chunk_size))
|
|
|
|
{
|
2016-03-21 06:12:12 -04:00
|
|
|
throw std::runtime_error("Error in deserialization of chunk size");
|
2015-05-08 16:46:26 -04:00
|
|
|
}
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MDEBUG("chunk_size: " << chunk_size);
|
2015-05-08 16:46:26 -04:00
|
|
|
|
2015-02-10 18:13:32 -05:00
|
|
|
if (chunk_size > BUFFER_SIZE)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MWARNING("WARNING: chunk_size " << chunk_size << " > BUFFER_SIZE " << BUFFER_SIZE);
|
2016-03-21 06:12:12 -04:00
|
|
|
throw std::runtime_error("Aborting: chunk size exceeds buffer size");
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
if (chunk_size > 100000)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("NOTE: chunk_size " << chunk_size << " > 100000");
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
2015-05-15 20:06:59 -04:00
|
|
|
else if (chunk_size == 0) {
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("ERROR: chunk_size == 0");
|
2015-02-10 18:13:32 -05:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
import_file.read(buffer_block, chunk_size);
|
|
|
|
if (! import_file) {
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("ERROR: unexpected end of file: bytes read before error: "
|
2015-02-10 18:13:32 -05:00
|
|
|
<< import_file.gcount() << " of chunk_size " << chunk_size);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
bytes_read += chunk_size;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Total bytes read: " << bytes_read);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
if (h + NUM_BLOCKS_PER_CHUNK < start_height + 1)
|
|
|
|
{
|
|
|
|
h += NUM_BLOCKS_PER_CHUNK;
|
|
|
|
continue;
|
|
|
|
}
|
2015-05-15 20:14:36 -04:00
|
|
|
if (h > block_stop)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
std::cout << refresh_string << "block " << h-1
|
2015-05-15 20:14:36 -04:00
|
|
|
<< " / " << block_stop
|
2015-05-08 16:46:26 -04:00
|
|
|
<< std::flush;
|
|
|
|
std::cout << ENDL << ENDL;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Specified block number reached - stopping. block: " << h-1 << " total blocks: " << h);
|
2015-02-10 18:13:32 -05:00
|
|
|
quit = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
str1.assign(buffer_block, chunk_size);
|
|
|
|
bootstrap::block_package bp;
|
|
|
|
if (! ::serialization::parse_binary(str1, bp))
|
2016-03-21 06:12:12 -04:00
|
|
|
throw std::runtime_error("Error in deserialization of chunk");
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
int display_interval = 1000;
|
|
|
|
int progress_interval = 10;
|
2015-05-08 16:46:26 -04:00
|
|
|
// NOTE: use of NUM_BLOCKS_PER_CHUNK is a placeholder in case multi-block chunks are later supported.
|
|
|
|
for (int chunk_ind = 0; chunk_ind < NUM_BLOCKS_PER_CHUNK; ++chunk_ind)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
++h;
|
|
|
|
if ((h-1) % display_interval == 0)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MDEBUG("loading block number " << h-1);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MDEBUG("loading block number " << h-1);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
2015-05-08 16:46:26 -04:00
|
|
|
b = bp.block;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MDEBUG("block prev_id: " << b.prev_id << ENDL);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
if ((h-1) % progress_interval == 0)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string << "block " << h-1
|
2015-05-15 20:14:36 -04:00
|
|
|
<< " / " << block_stop
|
2015-02-10 18:13:32 -05:00
|
|
|
<< std::flush;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<transaction> txs;
|
2015-05-08 16:46:26 -04:00
|
|
|
std::vector<transaction> archived_txs;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
archived_txs = bp.txs;
|
|
|
|
|
|
|
|
// std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MDEBUG("txs: " << archived_txs.size());
|
2015-05-08 16:46:26 -04:00
|
|
|
|
|
|
|
// if archived_txs is invalid
|
|
|
|
// {
|
|
|
|
// std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MFATAL("exception while de-archiving txs, height=" << h);
|
2015-05-08 16:46:26 -04:00
|
|
|
// quit = 1;
|
|
|
|
// break;
|
|
|
|
// }
|
|
|
|
|
|
|
|
// tx number 1: coinbase tx
|
|
|
|
// tx number 2 onwards: archived_txs
|
|
|
|
unsigned int tx_num = 1;
|
|
|
|
for (const transaction& tx : archived_txs)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
++tx_num;
|
|
|
|
// if tx is invalid
|
|
|
|
// {
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MFATAL("exception while indexing tx from txs, height=" << h <<", tx_num=" << tx_num);
|
2015-05-08 16:46:26 -04:00
|
|
|
// quit = 1;
|
|
|
|
// break;
|
2015-02-10 18:13:32 -05:00
|
|
|
// }
|
2015-05-08 16:46:26 -04:00
|
|
|
|
|
|
|
// std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MDEBUG("tx hash: " << get_transaction_hash(tx));
|
2015-05-08 16:46:26 -04:00
|
|
|
|
2015-02-10 18:13:32 -05:00
|
|
|
// crypto::hash hsh = null_hash;
|
|
|
|
// size_t blob_size = 0;
|
|
|
|
// NOTE: all tx hashes except for coinbase tx are available in the block data
|
|
|
|
// get_transaction_hash(tx, hsh, blob_size);
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MDEBUG("tx " << tx_num << " " << hsh << " : " << ENDL);
|
|
|
|
// MDEBUG(obj_to_json_str(tx) << ENDL);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
// add blocks with verification.
|
|
|
|
// for Blockchain and blockchain_storage add_new_block().
|
|
|
|
if (opt_verify)
|
|
|
|
{
|
|
|
|
// crypto::hash hsh = null_hash;
|
|
|
|
// size_t blob_size = 0;
|
|
|
|
// get_transaction_hash(tx, hsh, blob_size);
|
2016-01-29 10:09:17 -05:00
|
|
|
|
|
|
|
|
2016-02-08 11:12:11 -05:00
|
|
|
uint8_t version = simple_core.m_storage.get_current_hard_fork_version();
|
2015-02-10 18:13:32 -05:00
|
|
|
tx_verification_context tvc = AUTO_VAL_INIT(tvc);
|
|
|
|
bool r = true;
|
2017-01-15 16:52:56 -05:00
|
|
|
r = simple_core.m_pool.add_tx(tx, tvc, true, true, false, version);
|
2015-02-10 18:13:32 -05:00
|
|
|
if (!r)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("failed to add transaction to transaction pool, height=" << h <<", tx_num=" << tx_num);
|
2015-02-10 18:13:32 -05:00
|
|
|
quit = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// for add_block() method, without (much) processing.
|
|
|
|
// don't add coinbase transaction to txs.
|
|
|
|
//
|
|
|
|
// because add_block() calls
|
|
|
|
// add_transaction(blk_hash, blk.miner_tx) first, and
|
|
|
|
// then a for loop for the transactions in txs.
|
2015-05-08 16:46:26 -04:00
|
|
|
txs.push_back(tx);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (opt_verify)
|
|
|
|
{
|
|
|
|
block_verification_context bvc = boost::value_initialized<block_verification_context>();
|
|
|
|
simple_core.m_storage.add_new_block(b, bvc);
|
|
|
|
|
|
|
|
if (bvc.m_verifivation_failed)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("Failed to add block to blockchain, verification failed, height = " << h);
|
|
|
|
MFATAL("skipping rest of file");
|
2015-02-10 18:13:32 -05:00
|
|
|
// ok to commit previously batched data because it failed only in
|
|
|
|
// verification of potential new block with nothing added to batch
|
|
|
|
// yet
|
|
|
|
quit = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (! bvc.m_added_to_main_chain)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("Failed to add block to blockchain, height = " << h);
|
|
|
|
MFATAL("skipping rest of file");
|
2015-02-10 18:13:32 -05:00
|
|
|
// make sure we don't commit partial block data
|
|
|
|
quit = 2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
size_t block_size;
|
|
|
|
difficulty_type cumulative_difficulty;
|
|
|
|
uint64_t coins_generated;
|
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
block_size = bp.block_size;
|
|
|
|
cumulative_difficulty = bp.cumulative_difficulty;
|
|
|
|
coins_generated = bp.coins_generated;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-05-08 16:46:26 -04:00
|
|
|
// std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
// MDEBUG("block_size: " << block_size);
|
|
|
|
// MDEBUG("cumulative_difficulty: " << cumulative_difficulty);
|
|
|
|
// MDEBUG("coins_generated: " << coins_generated);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
simple_core.add_block(b, block_size, cumulative_difficulty, coins_generated, txs);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e)
|
|
|
|
{
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("Error adding block to blockchain: " << e.what());
|
2015-02-10 18:13:32 -05:00
|
|
|
quit = 2; // make sure we don't commit partial block data
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2015-05-08 16:46:26 -04:00
|
|
|
++num_imported;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
if (use_batch)
|
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
if ((h-1) % db_batch_size == 0)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string;
|
2015-05-08 16:46:26 -04:00
|
|
|
// zero-based height
|
|
|
|
std::cout << ENDL << "[- batch commit at height " << h-1 << " -]" << ENDL;
|
2015-02-10 18:13:32 -05:00
|
|
|
simple_core.batch_stop();
|
2015-07-11 15:32:49 -04:00
|
|
|
simple_core.batch_start(db_batch_size);
|
2015-02-10 18:13:32 -05:00
|
|
|
std::cout << ENDL;
|
2015-03-22 13:57:18 -04:00
|
|
|
simple_core.m_storage.get_db().show_stats();
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
catch (const std::exception& e)
|
|
|
|
{
|
2015-03-22 13:57:24 -04:00
|
|
|
std::cout << refresh_string;
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MFATAL("exception while reading from file, height=" << h << ": " << e.what());
|
2015-02-10 18:13:32 -05:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
} // while
|
|
|
|
|
|
|
|
import_file.close();
|
|
|
|
|
|
|
|
if (use_batch)
|
|
|
|
{
|
|
|
|
if (quit > 1)
|
|
|
|
{
|
|
|
|
// There was an error, so don't commit pending data.
|
|
|
|
// Destructor will abort write txn.
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
simple_core.batch_stop();
|
|
|
|
}
|
2015-03-22 13:57:18 -04:00
|
|
|
simple_core.m_storage.get_db().show_stats();
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Number of blocks imported: " << num_imported);
|
2015-02-10 18:13:32 -05:00
|
|
|
if (h > 0)
|
2015-05-08 16:46:26 -04:00
|
|
|
// TODO: if there was an error, the last added block is probably at zero-based height h-2
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Finished at block: " << h-1 << " total blocks: " << h);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
std::cout << ENDL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char* argv[])
|
|
|
|
{
|
2016-02-14 14:32:54 -05:00
|
|
|
std::string default_db_type = "lmdb";
|
2016-02-14 15:20:14 -05:00
|
|
|
std::string default_db_engine_compiled = "blockchain_db";
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2016-02-14 15:20:14 -05:00
|
|
|
std::unordered_set<std::string> db_types_all = cryptonote::blockchain_db_types;
|
|
|
|
db_types_all.insert("memory");
|
|
|
|
|
2016-02-14 16:39:14 -05:00
|
|
|
std::string available_dbs = join_set_strings(db_types_all, ", ");
|
|
|
|
available_dbs = "available: " + available_dbs;
|
|
|
|
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
uint32_t log_level = 0;
|
2015-05-08 14:35:48 -04:00
|
|
|
uint64_t num_blocks = 0;
|
2015-05-15 20:14:36 -04:00
|
|
|
uint64_t block_stop = 0;
|
2015-08-14 17:49:46 -04:00
|
|
|
std::string m_config_folder;
|
2015-02-11 19:02:20 -05:00
|
|
|
std::string db_arg_str;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-11-21 05:13:10 -05:00
|
|
|
tools::sanitize_locale();
|
|
|
|
|
2015-02-10 18:13:32 -05:00
|
|
|
boost::filesystem::path default_data_path {tools::get_default_data_dir()};
|
|
|
|
boost::filesystem::path default_testnet_data_path {default_data_path / "testnet"};
|
2015-08-14 17:49:46 -04:00
|
|
|
std::string import_file_path;
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
po::options_description desc_cmd_only("Command line options");
|
|
|
|
po::options_description desc_cmd_sett("Command line options and settings options");
|
2015-08-14 17:55:03 -04:00
|
|
|
const command_line::arg_descriptor<std::string> arg_input_file = {"input-file", "Specify input file", "", true};
|
2015-05-15 20:14:36 -04:00
|
|
|
const command_line::arg_descriptor<uint32_t> arg_log_level = {"log-level", "", log_level};
|
|
|
|
const command_line::arg_descriptor<uint64_t> arg_block_stop = {"block-stop", "Stop at block number", block_stop};
|
|
|
|
const command_line::arg_descriptor<uint64_t> arg_batch_size = {"batch-size", "", db_batch_size};
|
|
|
|
const command_line::arg_descriptor<uint64_t> arg_pop_blocks = {"pop-blocks", "Remove blocks from end of blockchain", num_blocks};
|
2016-02-04 20:15:37 -05:00
|
|
|
const command_line::arg_descriptor<bool> arg_drop_hf = {"drop-hard-fork", "Drop hard fork subdbs", false};
|
2015-02-10 18:13:32 -05:00
|
|
|
const command_line::arg_descriptor<bool> arg_testnet_on = {
|
|
|
|
"testnet"
|
|
|
|
, "Run on testnet."
|
|
|
|
, false
|
|
|
|
};
|
|
|
|
const command_line::arg_descriptor<bool> arg_count_blocks = {
|
|
|
|
"count-blocks"
|
2015-05-08 16:46:26 -04:00
|
|
|
, "Count blocks in bootstrap file and exit"
|
2015-02-10 18:13:32 -05:00
|
|
|
, false
|
|
|
|
};
|
|
|
|
const command_line::arg_descriptor<std::string> arg_database = {
|
2016-02-14 16:39:14 -05:00
|
|
|
"database", available_dbs.c_str(), default_db_type
|
2015-02-10 18:13:32 -05:00
|
|
|
};
|
|
|
|
const command_line::arg_descriptor<bool> arg_verify = {"verify",
|
|
|
|
"Verify blocks and transactions during import", true};
|
|
|
|
const command_line::arg_descriptor<bool> arg_batch = {"batch",
|
|
|
|
"Batch transactions for faster import", true};
|
|
|
|
const command_line::arg_descriptor<bool> arg_resume = {"resume",
|
|
|
|
"Resume from current height if output database already exists", true};
|
|
|
|
|
|
|
|
command_line::add_arg(desc_cmd_sett, command_line::arg_data_dir, default_data_path.string());
|
|
|
|
command_line::add_arg(desc_cmd_sett, command_line::arg_testnet_data_dir, default_testnet_data_path.string());
|
2015-08-14 17:55:03 -04:00
|
|
|
command_line::add_arg(desc_cmd_sett, arg_input_file);
|
2015-02-10 18:13:32 -05:00
|
|
|
command_line::add_arg(desc_cmd_sett, arg_testnet_on);
|
2015-05-15 20:14:36 -04:00
|
|
|
command_line::add_arg(desc_cmd_sett, arg_log_level);
|
2015-02-10 18:13:32 -05:00
|
|
|
command_line::add_arg(desc_cmd_sett, arg_database);
|
2015-05-15 20:14:36 -04:00
|
|
|
command_line::add_arg(desc_cmd_sett, arg_batch_size);
|
|
|
|
command_line::add_arg(desc_cmd_sett, arg_block_stop);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
command_line::add_arg(desc_cmd_only, arg_count_blocks);
|
2015-05-15 20:14:36 -04:00
|
|
|
command_line::add_arg(desc_cmd_only, arg_pop_blocks);
|
2016-02-04 20:15:37 -05:00
|
|
|
command_line::add_arg(desc_cmd_only, arg_drop_hf);
|
2015-02-10 18:13:32 -05:00
|
|
|
command_line::add_arg(desc_cmd_only, command_line::arg_help);
|
|
|
|
|
|
|
|
// call add_options() directly for these arguments since
|
|
|
|
// command_line helpers support only boolean switch, not boolean argument
|
|
|
|
desc_cmd_sett.add_options()
|
|
|
|
(arg_verify.name, make_semantic(arg_verify), arg_verify.description)
|
|
|
|
(arg_batch.name, make_semantic(arg_batch), arg_batch.description)
|
|
|
|
(arg_resume.name, make_semantic(arg_resume), arg_resume.description)
|
|
|
|
;
|
|
|
|
|
|
|
|
po::options_description desc_options("Allowed options");
|
|
|
|
desc_options.add(desc_cmd_only).add(desc_cmd_sett);
|
|
|
|
|
|
|
|
po::variables_map vm;
|
|
|
|
bool r = command_line::handle_error_helper(desc_options, [&]()
|
|
|
|
{
|
|
|
|
po::store(po::parse_command_line(argc, argv, desc_options), vm);
|
|
|
|
po::notify(vm);
|
|
|
|
return true;
|
|
|
|
});
|
|
|
|
if (! r)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
log_level = command_line::get_arg(vm, arg_log_level);
|
|
|
|
opt_verify = command_line::get_arg(vm, arg_verify);
|
|
|
|
opt_batch = command_line::get_arg(vm, arg_batch);
|
|
|
|
opt_resume = command_line::get_arg(vm, arg_resume);
|
2015-05-15 20:14:36 -04:00
|
|
|
block_stop = command_line::get_arg(vm, arg_block_stop);
|
2015-02-10 18:13:32 -05:00
|
|
|
db_batch_size = command_line::get_arg(vm, arg_batch_size);
|
|
|
|
|
|
|
|
if (command_line::get_arg(vm, command_line::arg_help))
|
|
|
|
{
|
2015-12-31 16:12:13 -05:00
|
|
|
std::cout << "Monero '" << MONERO_RELEASE_NAME << "' (v" << MONERO_VERSION_FULL << ")" << ENDL << ENDL;
|
2015-02-10 18:13:32 -05:00
|
|
|
std::cout << desc_options << std::endl;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! opt_batch && ! vm["batch-size"].defaulted())
|
|
|
|
{
|
|
|
|
std::cerr << "Error: batch-size set, but batch option not enabled" << ENDL;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
if (! db_batch_size)
|
|
|
|
{
|
|
|
|
std::cerr << "Error: batch-size must be > 0" << ENDL;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
2015-05-08 16:46:26 -04:00
|
|
|
if (opt_verify && vm["batch-size"].defaulted())
|
|
|
|
{
|
|
|
|
// usually want batch size default lower if verify on, so progress can be
|
|
|
|
// frequently saved.
|
|
|
|
//
|
|
|
|
// currently, with Windows, default batch size is low, so ignore
|
|
|
|
// default db_batch_size_verify unless it's even lower
|
|
|
|
if (db_batch_size > db_batch_size_verify)
|
|
|
|
{
|
|
|
|
db_batch_size = db_batch_size_verify;
|
|
|
|
}
|
|
|
|
}
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
opt_testnet = command_line::get_arg(vm, arg_testnet_on);
|
|
|
|
auto data_dir_arg = opt_testnet ? command_line::arg_testnet_data_dir : command_line::arg_data_dir;
|
2015-08-14 17:49:46 -04:00
|
|
|
m_config_folder = command_line::get_arg(vm, data_dir_arg);
|
2015-02-11 19:02:20 -05:00
|
|
|
db_arg_str = command_line::get_arg(vm, arg_database);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2017-01-16 05:45:59 -05:00
|
|
|
mlog_configure("monero-blockchain-import", true);
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Starting...");
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-08-14 17:55:03 -04:00
|
|
|
boost::filesystem::path fs_import_file_path;
|
|
|
|
|
|
|
|
if (command_line::has_arg(vm, arg_input_file))
|
|
|
|
fs_import_file_path = boost::filesystem::path(command_line::get_arg(vm, arg_input_file));
|
|
|
|
else
|
|
|
|
fs_import_file_path = boost::filesystem::path(m_config_folder) / "export" / BLOCKCHAIN_RAW;
|
|
|
|
|
2015-08-14 17:49:46 -04:00
|
|
|
import_file_path = fs_import_file_path.string();
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
if (command_line::has_arg(vm, arg_count_blocks))
|
|
|
|
{
|
2015-05-08 16:46:26 -04:00
|
|
|
BootstrapFile bootstrap;
|
|
|
|
bootstrap.count_blocks(import_file_path);
|
2015-05-16 22:27:26 -04:00
|
|
|
return 0;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
|
2015-02-11 19:02:20 -05:00
|
|
|
|
2016-02-14 14:32:54 -05:00
|
|
|
std::string db_type;
|
2016-02-14 15:20:14 -05:00
|
|
|
std::string db_engine_compiled;
|
2016-02-14 14:32:54 -05:00
|
|
|
int db_flags = 0;
|
2015-02-11 19:02:20 -05:00
|
|
|
int res = 0;
|
2016-02-14 14:32:54 -05:00
|
|
|
res = parse_db_arguments(db_arg_str, db_type, db_flags);
|
2015-02-11 19:02:20 -05:00
|
|
|
if (res)
|
|
|
|
{
|
|
|
|
std::cerr << "Error parsing database argument(s)" << ENDL;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-11 19:02:20 -05:00
|
|
|
}
|
|
|
|
|
2016-02-14 15:20:14 -05:00
|
|
|
if (db_types_all.count(db_type) == 0)
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2016-02-14 14:32:54 -05:00
|
|
|
std::cerr << "Invalid database type: " << db_type << std::endl;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
|
2016-02-14 15:20:14 -05:00
|
|
|
if ((db_type == "lmdb") || (db_type == "berkeley"))
|
|
|
|
{
|
|
|
|
db_engine_compiled = "blockchain_db";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
db_engine_compiled = "memory";
|
|
|
|
}
|
|
|
|
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("database: " << db_type);
|
|
|
|
MINFO("database flags: " << db_flags);
|
|
|
|
MINFO("verify: " << std::boolalpha << opt_verify << std::noboolalpha);
|
2015-02-10 18:13:32 -05:00
|
|
|
if (opt_batch)
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("batch: " << std::boolalpha << opt_batch << std::noboolalpha
|
2015-02-10 18:13:32 -05:00
|
|
|
<< " batch size: " << db_batch_size);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("batch: " << std::boolalpha << opt_batch << std::noboolalpha);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("resume: " << std::boolalpha << opt_resume << std::noboolalpha);
|
|
|
|
MINFO("testnet: " << std::boolalpha << opt_testnet << std::noboolalpha);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("bootstrap file path: " << import_file_path);
|
|
|
|
MINFO("database path: " << m_config_folder);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
|
|
|
|
// fake_core needed for verification to work when enabled.
|
|
|
|
//
|
|
|
|
// NOTE: don't need fake_core method of doing things when we're going to call
|
|
|
|
// BlockchainDB add_block() directly and have available the 3 block
|
|
|
|
// properties to do so. Both ways work, but fake core isn't necessary in that
|
|
|
|
// circumstance.
|
|
|
|
|
|
|
|
// for multi_db_runtime:
|
2016-02-14 15:20:14 -05:00
|
|
|
if (db_type == "lmdb" || db_type == "berkeley")
|
2015-02-10 18:13:32 -05:00
|
|
|
{
|
2016-02-14 14:35:30 -05:00
|
|
|
fake_core_db simple_core(m_config_folder, opt_testnet, opt_batch, db_type, db_flags);
|
2015-05-15 20:14:36 -04:00
|
|
|
import_from_file(simple_core, import_file_path, block_stop);
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2016-02-14 14:32:54 -05:00
|
|
|
std::cerr << "database type unrecognized" << ENDL;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// for multi_db_compile:
|
2016-02-14 14:35:30 -05:00
|
|
|
fake_core_db simple_core(m_config_folder, opt_testnet, opt_batch, db_type, db_flags);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
2015-05-08 14:35:48 -04:00
|
|
|
if (! vm["pop-blocks"].defaulted())
|
|
|
|
{
|
|
|
|
num_blocks = command_line::get_arg(vm, arg_pop_blocks);
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("height: " << simple_core.m_storage.get_current_blockchain_height());
|
2015-05-08 14:35:48 -04:00
|
|
|
pop_blocks(simple_core, num_blocks);
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("height: " << simple_core.m_storage.get_current_blockchain_height());
|
2015-05-16 22:27:26 -04:00
|
|
|
return 0;
|
2015-05-08 14:35:48 -04:00
|
|
|
}
|
|
|
|
|
2016-02-04 20:15:37 -05:00
|
|
|
if (! vm["drop-hard-fork"].defaulted())
|
|
|
|
{
|
Change logging to easylogging++
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
2017-01-01 11:34:23 -05:00
|
|
|
MINFO("Dropping hard fork tables...");
|
2016-02-04 20:15:37 -05:00
|
|
|
simple_core.m_storage.get_db().drop_hard_fork_info();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-15 20:14:36 -04:00
|
|
|
import_from_file(simple_core, import_file_path, block_stop);
|
2015-02-10 18:13:32 -05:00
|
|
|
|
|
|
|
}
|
|
|
|
catch (const DB_ERROR& e)
|
|
|
|
{
|
|
|
|
std::cout << std::string("Error loading blockchain db: ") + e.what() + " -- shutting down now" << ENDL;
|
2015-05-16 22:27:26 -04:00
|
|
|
return 1;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// destructors called at exit:
|
|
|
|
//
|
|
|
|
// ensure db closed
|
|
|
|
// - transactions properly checked and handled
|
|
|
|
// - disk sync if needed
|
|
|
|
//
|
|
|
|
// fake_core object's destructor is called when it goes out of scope. For an
|
|
|
|
// LMDB fake_core, it calls Blockchain::deinit() on its object, which in turn
|
|
|
|
// calls delete on its BlockchainDB derived class' object, which closes its
|
|
|
|
// files.
|
2015-05-16 22:27:26 -04:00
|
|
|
return 0;
|
2015-02-10 18:13:32 -05:00
|
|
|
}
|