LogPrintLevel()
where the level is hardcoded, and changes all LogPrintf
and LogPrint
uses in init.cpp.
LogPrintLevel()
where the level is hardcoded, and changes all LogPrintf
and LogPrint
uses in init.cpp.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
Concept ACK | fanquake |
Stale ACK | stickies-v, davidgumberg |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Depending on how many conflicts drahtbot detects, maybe this should be targeting a merge around 27.0’s feature freeze?
Many of the log statements in init.cpp could be done at a better level, eg LogPrintf("Error: Out of memory. Terminating.\n");
should obviously be logging at the “error” level, not the “info” level. In order to keep this PR scripted-diff only, I won’t fix that here; but it can fixed in an independent PR either before or after this PR is merged.
2625@@ -2626,7 +2626,7 @@ bool Chainstate::FlushStateToDisk(
2626 // TODO: Handle return error, or add detailed comment why it is
2627 // safe to not return an error upon failure.
2628 if (!m_blockman.FlushChainstateBlockFile(m_chain.Height())) {
2629- LogPrintLevel(BCLog::VALIDATION, BCLog::Level::Warning, "%s: Failed to flush block file.\n", __func__);
2630+ LogWarning("%s: Failed to flush block file.\n", __func__);
__func__
when changing the log output anyway?
ACK 2632d038754d975e76926b7c068309c7aadc82f5
Since we don’t have significant merge conflicts I would this support this PR having a non-scripted diff commit to first fix incorrect levels (instead of having to fix and then re-fix) but am okay with this approach too.
Suggested fixes in https://github.com/bitcoin/bitcoin/compare/master...stickies-v:bitcoin:2024-01/fix-log-level-29231 - happy to open a separate pull for it too?
happy to open a separate pull for it too?
Yeah, I think it is better to change a line of code only once, instead of twice, unless there is a reason to change it twice.
Suggested fixes in master…stickies-v:bitcoin:2024-01/fix-log-level-29231 - happy to open a separate pull for it too?
Added these commits
Changes all uses of LogPrintLevel() where the level is hardcoded, and changes all LogPrintf and LogPrint uses in init.cpp.
Trying to understand the concept here. What problem does this solve?
1142+ LogInfo("Using at most %i automatic connections (%i file descriptors available)\n", nMaxConnections, nFD);
1143
1144 // Warn about relative -datadir path.
1145 if (args.IsArgSet("-datadir") && !args.GetPathArg("-datadir").is_absolute()) {
1146- LogPrintf("Warning: relative datadir option '%s' specified, which will be interpreted relative to the "
1147+ LogWarning("Warning: relative datadir option '%s' specified, which will be interpreted relative to the "
nit:
0 LogWarning("Relative datadir option '%s' specified, which will be interpreted relative to the "
utACK https://github.com/bitcoin/bitcoin/commit/8d46bd6750b47caaf2556f915800c6a22c997bc3
Tangential to this PR:
Is LogPrintLevel
in void libevent_log_cb(...)
an example of:
“when […] a category needs to be added for an info/warning/error log message”
0 static void libevent_log_cb(int severity, const char *msg)
1 {
2- BCLog::Level level;
3 switch (severity) {
4 case EVENT_LOG_DEBUG:
5- level = BCLog::Level::Debug;
6+ LogDebug(BCLog::LIBEVENT, "%s\n", msg);
7 break;
8 case EVENT_LOG_MSG:
9- level = BCLog::Level::Info;
10+ LogInfo("%s\n", msg);
11 break;
12 case EVENT_LOG_WARN:
13- level = BCLog::Level::Warning;
14+ LogWarning("%s\n", msg);
15 break;
16 default: // EVENT_LOG_ERR and others are mapped to error
17- level = BCLog::Level::Error;
18+ LogError("%s\n", msg);
19 break;
20 }
21- LogPrintLevel(BCLog::LIBEVENT, level, "%s\n", msg);
22 }
As per doc/developer-notes#logging, LogError should be used for
severe problems that require the node to shut down
As per doc/developer-notes#logging, LogWarning should be used for
severe problems that do not warrant shutting down the node
-BEGIN VERIFY SCRIPT-
sed -i 's/LogPrintLevel(\(BCLog::[^,]*\), BCLog::Level::Debug,/LogDebug(\1,/' src/net_processing.cpp src/dbwrapper.cpp src/net.cpp src/node/txreconciliation.cpp src/validation.cpp
-END VERIFY SCRIPT-
Changes log output from:
[net:error] Something bad happened
to either
[error] Something bad happened
or, when -loglevelalways=1 is enabled:
[all:error] Something bad happened
-BEGIN VERIFY SCRIPT-
sed -i 's/LogPrintLevel(\(BCLog::[^,]*\), BCLog::Level::Error, */LogError(/' src/net.cpp src/txdb.cpp src/txmempool.cpp
-END VERIFY SCRIPT-
Changes log output from:
[net:warning] Something problematic happened
to either
[warning] Something problematic happened
or, when -loglevelalways=1 is enabled:
[all:warning] Something problematic happened
-BEGIN VERIFY SCRIPT-
sed -i 's/LogPrintLevel(\(BCLog::[^,]*\), BCLog::Level::Warning, */LogWarning(/' src/net.cpp src/node/blockstorage.cpp src/validation.cpp
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
sed -i 's/LogPrint(\(BCLog::[^,]*\),/LogDebug(\1,/' src/init.cpp
sed -i 's/LogPrintf(/LogInfo(/' src/init.cpp
-END VERIFY SCRIPT-