Cleanup of -debug=net log messages#20724
Conversation
|
Concept ACK |
|
Having run this patch on a node that does tor and accepts incoming connections for a couple of days, with debug logging disabled, my logs have:
which mostly seem pretty reasonable indicators of what's going on. But they do also still have: validation debug info:
socks/tor debug info (netbase.cpp):
block file management info:
For comparison: #19832 (comment) |
|
Very strong Concept ACK: this is a great signal-to-noise improvement!
Perfect! |
|
Yeah, I've resigned myself to always running nodes with net logging on now and grepping for things. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, 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. |
|
Concept ACK. I have a draft branch that makes The branch is here: https://github.com/jnewbery/bitcoin/commits/2020-12-log-disconnect. It doesn't necessarily need to go in at the same time as this, but it might make sense to try to fix this definitively. |
|
Concept ACK |
07c606c to
2219a8d
Compare
|
Removed dep on #20646 since it's no longer changing late sendaddrv2 from a disconnect, and marked as ready for review. |
|
@jnewbery Didn't like the change to always evaluating the args to the LogPrint format that comes with a |
Good point about always evaluating the LogPrint args. In practice, I don't think it matters very much here. These logs are infrequent, only happen once per connection, and none of them have expensive-to-evaluate log args, so the performance impact would be negligible. Still, if you wanted to do it with zero cost, we could implement some |
2219a8d to
e28d740
Compare
|
utACK e28d7405c11d407b4665a378ad17bc3e9b81c4f0 |
e28d740 to
b007071
Compare
|
utACK b0070717b4fe33f21d6d0d15bc30a26473f06a90 Checked range-diff. Only conflict was change from |
|
ACK b0070717b4fe33f21d6d0d15bc30a26473f06a90 Very nice to see so many "attacker log spam" vectors (or worst-case: attacker disk fill vectors) be removed in one go. Looking forward to seeing this merged! |
|
🕵️ @sipa has been requested to review this pull request as specified in the REVIEWERS file. |
maflcko
left a comment
There was a problem hiding this comment.
review ACK b0070717b4fe33f21d6d0d15bc30a26473f06a90 🔘
Show signature and timestamp
Signature:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
review ACK b0070717b4fe33f21d6d0d15bc30a26473f06a90 🔘
-----BEGIN PGP SIGNATURE-----
iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUgJAQwAt8D/Rh7yHcjI6ZS+S010qa2U/jXHrKnTvbItbCDH6SMlqyd0djxIfw2t
fDT0bOKNGEZOgfy9v5pnDy9ZbtZmO9t/kLwiRYDTvkX0UigWczjkuXnEWIp3QFjL
XedcGIRRe5jvVNVS0TIJNGwcNxez5cbnfKVcFMX0aRPoC5h+7IxCOBZQ6PvRlFmC
bIj6Z3yhPFBjWXNsfLOPEYGZ74680ahH1GSkJ2ww4aIx/6CNCJhSSH4gIjsbVPBc
jDiXwzgPolnv9LPmpLGfoVzAriV4Z9fcA8bewohzLwAJDJHzCE8/LhziPM+fqYpv
1KHSIL/wJN93UnGtzWQJyWl2p1+meerqUIgqh4sbgBCsL3pQg8AD9sC6HgVOcAxL
8RDh3f3lDSIHkmk+RC5zm6FzfUurEratFs530w6OwTtgdFoyeeuiZ3RlTHBbdoXG
FBaqGjLy3NagvHXqiLFnJJs/pFvQH8hJHh3qosvn2cjF4HB0FLhD/ihcfPw+u9hk
f3hY8LO9
=VKWw
-----END PGP SIGNATURE-----
Timestamp of file with hash d559c553e0361215784d099000b159ebc6ba1b880fcf3dd5cc55c844632bb1fd -
b007071 to
4424d13
Compare
|
Addressed marco's comments |
|
cr ACK 4424d136c45b6b078afd58d5e8fc609ec7e047eb |
|
re-ACK 4424d136c45b6b078afd58d5e8fc609ec7e047eb only change is fLogIPs fixup in first commit 🤺 Show signature and timestampSignature: Timestamp of file with hash |
|
Concept ACK. I really wanted this! |
|
My PR being merged made this one conflict with master. I've rebased it here: https://github.com/jnewbery/bitcoin/tree/pr20724.1. Feel free to take that if it helps. utACK dd0aeac if you take it. |
4424d13 to
48c8a9b
Compare
I manually rebased it onto master in order to include #21000, but I think I got the same changes as your rebase anyway. |
|
ACK 48c8a9b Confirmed I got the same rebase. |
|
re-ACK 48c8a9b only change is rebase 🚓 Show signature and timestampSignature: Timestamp of file with hash |
|
re-ACK 48c8a9b |
48c8a9b net_processing: log txrelay flag from version message (Anthony Towns) 98fab37 net: use peer=N instead of from=N in debug log (Anthony Towns) 1230210 net_processing: additional debug logging for ignored messages (Anthony Towns) f7edea3 net: make debug logging conditional on -debug=net (Anthony Towns) a410ae8 net, net_processing: log disconnect reasons with -debug=net (Anthony Towns) Pull request description: A few changes to -debug=net logging: * always log when disconnecting a peer * only log various connection errors when -debug=net is enabled, since errors from random untrusted peers is completely expected * log when ignoring a message due to violating protocol (primarily to make it easier to debug other implementations) * use "peer=123" rather than "from 123" to make grepping logs a bit easier * log the value of the bip-37 `fRelay` field in version messages both when sending and receiving a version message ACKs for top commit: jnewbery: ACK 48c8a9b MarcoFalke: re-ACK 48c8a9b only change is rebase 🚓 practicalswift: re-ACK 48c8a9b Tree-SHA512: 6ac530d883dffc4fd7fe20b1dc5ebb5394374c9b499aa7a253eb4a3a660d8901edd72e5ad21ce4a2bf71df25e8f142087755f9756f3497f564ef453a7e9246c1
…at" log message to debug category 25f899c log: Move "Pre-allocating up to position 0x[...] in [...].dat" log message to debug category (practicalswift) acd7980 log: Move "Leaving block file [...]: [...]" log message to debug category (practicalswift) Pull request description: Move `Pre-allocating up to position 0x[…] in […].dat` log message to debug category. After the cleanup of `-debug=net` log messages PR (#20724) was merged recently the console log now has very high signal to noise ratio. That's great! :) This PR increases the signal to noise ratio slightly more by moving the most common remaining implementation detail log message (`Pre-allocating up to position 0x[…] in […].dat`) to the debug category where it belongs :) Expected standard output from `bitcoind` (when in steady state) before this patch: ``` $ src/bitcoind … 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z Pre-allocating up to position 0x0000000 in blk00000.dat 0000-00-00T00:00:00Z Pre-allocating up to position 0x000000 in rev00000.dat 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) ``` Expected standard output from `bitcoind` (when in steady state) after this patch: ``` $ src/bitcoind … 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) ``` I find the latter alternative much easier to visually scan for anomalies (and more aesthetically pleasing TBH!). Non-GUI users deserve nice interfaces too :) ACKs for top commit: laanwj: ACK 25f899c Tree-SHA512: 5970798c41b041527ebdcbd843c5e136c257c28c3b21fc74102da8970406ca5c0c7e406305c5e6e67de5c1708dc1858af07a77a2e05f44159b7103423e8ab32f
…n […].dat" log message to debug category 25f899c log: Move "Pre-allocating up to position 0x[...] in [...].dat" log message to debug category (practicalswift) acd7980 log: Move "Leaving block file [...]: [...]" log message to debug category (practicalswift) Pull request description: Move `Pre-allocating up to position 0x[…] in […].dat` log message to debug category. After the cleanup of `-debug=net` log messages PR (bitcoin#20724) was merged recently the console log now has very high signal to noise ratio. That's great! :) This PR increases the signal to noise ratio slightly more by moving the most common remaining implementation detail log message (`Pre-allocating up to position 0x[…] in […].dat`) to the debug category where it belongs :) Expected standard output from `bitcoind` (when in steady state) before this patch: ``` $ src/bitcoind … 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z Pre-allocating up to position 0x0000000 in blk00000.dat 0000-00-00T00:00:00Z Pre-allocating up to position 0x000000 in rev00000.dat 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) ``` Expected standard output from `bitcoind` (when in steady state) after this patch: ``` $ src/bitcoind … 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) 0000-00-00T00:00:00Z UpdateTip: new best=0000000000000000000000000000000000000000000000000000000000000000 height=000000 version=0x00000000 log0_work=00.000000 tx=000000000 date='0000-00-00T00:00:00Z' progress=0.000000 cache=000.0MiB(0000000txo) ``` I find the latter alternative much easier to visually scan for anomalies (and more aesthetically pleasing TBH!). Non-GUI users deserve nice interfaces too :) ACKs for top commit: laanwj: ACK 25f899c Tree-SHA512: 5970798c41b041527ebdcbd843c5e136c257c28c3b21fc74102da8970406ca5c0c7e406305c5e6e67de5c1708dc1858af07a77a2e05f44159b7103423e8ab32f
Summary: ``` A few changes to -debug=net logging: - always log when disconnecting a peer - only log various connection errors when -debug=net is enabled, since errors from random untrusted peers is completely expected - log when ignoring a message due to violating protocol (primarily to make it easier to debug other implementations) - use "peer=123" rather than "from 123" to make grepping logs a bit easier - log the value of the bip-37 fRelay field in version messages both when sending and receiving a version message ``` Some differences from the source material are due to segwit and out of order backports. Backport of [[bitcoin/bitcoin#20724 | core#20724]]. Ref T1696. Test Plan: ninja all check-extended Reviewers: #bitcoin_abc, PiRK Reviewed By: #bitcoin_abc, PiRK Maniphest Tasks: T1696 Differential Revision: https://reviews.bitcoinabc.org/D10923
A few changes to -debug=net logging:
fRelayfield in version messages both when sending and receiving a version message