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.
Added a new command to the P2P protocol definitions to allow querying for support flags.
Implemented handling of new support flags command in net_node. Changed for_each callback template to include support flags. Updated print_connections command to show peer support flags.
Added p2p constant for signaling fluffy block support.
Added get_pool_transaction function to cryptnote_core.
Added new commands to cryptonote protocol for relaying fluffy blocks.
Implemented handling of fluffy block command in cryptonote protocol.
Enabled fluffy block support in node initial configuration.
Implemented get_testnet function in cryptonote_core.
Made it so that fluffy blocks only run on testnet.
25% of the outputs are selected from the last 5 days (if possible),
in order to avoid the common case of sending recently received
outputs again. 25% and 5 days are subject to review later, since
it's just a wallet level change.
10be903 Brackets to prevent premature return (NanoAkron)
fb1785a Brackets to ensure doesn't function prematurely return (NanoAkron)
8ed0d72 Moved logging to target functions rather than caller (NanoAkron)
442bfd1 Added messages at log level 2 to reflect deactivation procedure (NanoAkron)
This is intended to catch traffic coming from a web browser,
so we avoid issues with a web page sending a transfer RPC to
the wallet. Requiring a particular user agent can act as a
simple password scheme, while we wait for 0MQ and proper
authentication to be merged.
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.
Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).
This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
This adds [snap](https://snapcraft.io) packaging to the project. See the
link for more information on snaps. Snap packages install on all Linux
distributions. On Ubuntu, snap confinement with apparmor and seccomp
provide an additional layer of security.
This snap sets up monerod as a systemd service, which should start
immediately on install. To access the wallet CLI, simply run `monero`
(/snap/bin/monero). I think it's a really quick & easy way to get
started with monero.
I've made some opinionated decisions in the packaging just to kick this
off, but I'm happy to iterate on this stuff.
By default the flag is enabled whenever libunwind is found on the
system, with the exception of static build on OSX (for which we can't
install the throw hook #932 due to lack of support for --wrap in OSX
ld64 linker).
When an exception happens while reading the config file, we need
to print the error, as the logging system isn't initialized yet,
so the generic catch will not print anything.
It sets the max number of threads to use for a parallel job.
This is different that the number of total threads, since monero
binaries typically start a lot of them.
d662ab5 rpc: print human readable time since received when printing pool (moneromooo-monero)
5c9dd23 rpc: add a do_not_relay boolean to tx submission (moneromooo-monero)
This is a list of existing output amounts along with the number
of outputs of that amount in the blockchain.
The daemon command takes:
- no parameters: all outputs with at least 3 instances
- one parameter: all outputs with at least that many instances
- two parameters: all outputs within that many instances
The default starts at 3 to avoid massive spamming of all dust
outputs in the blockchain, and is the current minimum mixin
requirement.
An optional vector of amounts may be passed, to request
histogram only for those outputs.
The functions in src/cryptonote_core/checkpoints_create.{h,cpp} should
be member functions of the checkpoints class, if nothing else for the
sake of keeping their documentation together.
This commit covers moving those functions to be member functions of the
checkpoints class as well as documenting those functions.
Example of current return for `print_block 912345`:
timestamp: 1452793716
previous hash:
b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78
nonce: 1646
is orphan: 0
height: 912345
depth: 85434
hash:
e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6difficul
ty: 815625611
reward: 7388968946286
{
"major_version": 1,
"minor_version": 2,
…
Without `std::endl`, the difficulty gets smashed on the end of the hash.
bcac101 daemon: fix a few issues reported by valgrind (moneromooo-monero)
a7e8174 tx_pool: fix serialization of new relayed data (moneromooo-monero)
601ad76 hardfork: fix mixup in indexing variable in get_voting_info (moneromooo-monero)
444e22f blockchain: remove unused timer (moneromooo-monero)
7edfdd8 blockchain: fix m_sync_counter uninitialized variable use (moneromooo-monero)
d97582c epee: use generate_random_bytes for new random uuids (moneromooo-monero)
17c7c9c epee: remove dodgy random code that nobody uses (moneromooo-monero)
In particular, ensure we check the status of RPC response structures,
as some functions will return success, but with a BUSY status, when
the daemon is not yet synced, and the response will not filled.
In particular, <boost/program_options.hpp> blows up daemon.cpp.obj,
making it too big to compile in debug mode on Win32. Even on a
release build it drops daemon.cpp.o on Linux from 31MB to 20MB.
This has no effect on the final linked binary size.
This fixes coretests, which does not register daemon specific arguments,
but uses core, which uses those arguments. Also gets rid of an unwanted
dependency on daemon code from core.
