On bitcoind startup, write config args to debug.log #16115

When a developer is examining debug.log after something goes wrong, it's often useful to know the exact options the failing instance of bitcoind was started with. Sometimes the debug.log file is all that's available for the analysis. This PR logs the bitcoin.conf entries and command-line arguments to debug.log on startup.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17812 (config, test: asmap functional tests and feature refinements by jonatack)
• #17783 (util: Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior by ryanofsky)
• #17581 (refactor: Remove settings merge reverse precedence code by ryanofsky)
• #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
• #17493 (util: Forbid ambiguous multiple assignments in config file by ryanofsky)

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.

Knowing the startup parameters for debug purposes is certainly helpful. Unsure about logging rpcpassword (maybe add a blacklist?).

Knowing the startup parameters for debug purposes is certainly helpful. Unsure about logging rpcpassword (maybe add a blacklist?).

Yepp. Agree this is very useful for troubleshooting, but be careful with logging sensitive information (people do post these things to the internet sometimes).

Thank all of you for the good comments! Force-pushed (since this PR is so small) to address all review comments. I added a blacklist, but please verify that it contains the correct items. I tested this manually, bitcoin.conf contains:

debug=1
debug=xxx
torpassword=hellotor

and then I ran bitcoind --debug=cmdline111 --rpcuser=hellouser and the following appeared in debug.log:

2019-05-30T15:31:29Z config-file arg:  -debug=1
2019-05-30T15:31:29Z config-file arg:  -debug=xxx
2019-05-30T15:31:29Z config-file arg:  -torpassword=****
2019-05-30T15:31:29Z command-line arg: -debug=cmdline111
2019-05-30T15:31:29Z command-line arg: -rpcuser=****
2019-05-30T15:31:29Z command-line arg: -server=1

Related to #15493.

Concept ACK, but found two issues.

2019-06-11T22:57:43Z config-file arg:  -regtest.rpcpassword=123456abcdef
2019-06-11T22:57:43Z config-file arg:  -regtest.rpcuser=bitcoinrpc
2019-06-11T22:57:43Z config-file arg:  -rpcpassword=****
2019-06-11T22:57:43Z config-file arg:  -rpcuser=****
2019-06-11T22:57:43Z config-file arg:  -server=1
2019-06-11T22:57:43Z config-file arg:  -test.bind=127.0.0.1
2019-06-11T22:57:43Z config-file arg:  -test.prune=1000
2019-06-11T22:57:43Z command-line arg: -testnet=

1. Blacklisted args does not seem to work for regtest (I assume the same problem is for testnet).
2. Probably there isn't need for a "=" part for no value arguments (or use "=1"?).

Not 100% sure if this is possible or in scope, but it'd be very useful to have the effective command line configuration at-a-glance, especially when trying to debug for others from looking at their logs.

@dongcarl that's a bigger change. Basically all default values are defined when the arg is used, so what you want would require to duplicate all of that or move the defaults to one place elsewhere. I don't think debug log should have all args but maybe we could add an option to control that.

In #15493 I propose to add a RPC to also see effective arg values.

@kristapsk, I force-pushed a fix for both of your suggestions, thanks! I decided to leave the = off if there are no value arguments, because I didn't want to assume that having no values would always be the same as =1.

I just noticed this PR is incomplete. To provide a little background for those not very familiar with the logging code: The client shrinks debug.log upon startup if it's larger than a moderate size (11 MB), preserving the most recent 10 MB. This happens only at startup, so if bitcoind runs for a long time, and happens to do a lot of logging, the log file can become enormous.

External log rotation tools can be configured to prevent the log file from growing unbounded, see #917. Typically the way these tools work is, they first move (as in, the rename system call) debug.log to a different name. Because the client has an open file handle to this file, it continues to log to it even though it's been moved. Then the log rotation tool sends the client a SIGHUP signal to cause it to close its file descriptor and reopen debug.log. Now it's actually creating a new debug.log file, and future logging goes there. No data are lost during this switch. The log rotation tool can now do whatever it wants with the renamed (old) log file. It may compress it, offload it, or, either immediately or after some time, delete it.

If it deletes it, the configuration information that this PR causes to be logged during startup no longer exists anywhere.

The latest commit, https://github.com/bitcoin/bitcoin/pull/16115/commits/df891038ccce1ea15d2cabcd6717acf60ca9e9ee, re-logs the configuration information whendebug.log is reopened. This guarantees that debug.log always contains the configuration messages. My first idea was to re-log only the configuration file and command line arguments (that are being written by the first part of this PR). But there's a lot of other useful stuff that gets logged at just after startup. Here's what appears in debug.log during my testing, after it's reopened (this does not appear on the console):

2019-06-15T05:38:03Z Logging: start relogging initial messages
2019-06-15T05:37:09Z Bitcoin Core version v0.18.99.0-df891038c (release build)
2019-06-15T05:37:09Z Assuming ancestors of block 0000000000000037a8cd3e06cd5edbfe9dd1dbcc5dacab279376ef7cfc2b4c75 have valid signatures.
2019-06-15T05:37:09Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000007dbe94253893cbd463
2019-06-15T05:37:09Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-06-15T05:37:09Z Using RdSeed as additional entropy source
2019-06-15T05:37:09Z Using RdRand as an additional entropy source
2019-06-15T05:37:09Z Default data directory /home/larry/.bitcoin
2019-06-15T05:37:09Z Using data directory /home/larry/.bitcoin/testnet3
2019-06-15T05:37:09Z Config file: /home/larry/.bitcoin/bitcoin.conf
2019-06-15T05:37:09Z config-file arg:  -testnet=1
2019-06-15T05:37:09Z command-line arg: -server=1
2019-06-15T05:37:09Z Using at most 125 automatic connections (1024 file descriptors available)
2019-06-15T05:37:09Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-06-15T05:37:10Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-06-15T05:37:10Z Using 4 threads for script verification
2019-06-15T05:37:10Z No wallet support compiled in!
2019-06-15T05:37:10Z scheduler thread start
2019-06-15T05:37:10Z HTTP: creating work queue of depth 16
2019-06-15T05:37:10Z No rpcpassword set - using random cookie authentication.
2019-06-15T05:37:10Z Generated RPC authentication cookie /home/larry/.bitcoin/testnet3/.cookie
2019-06-15T05:37:10Z HTTP: starting 4 worker threads
2019-06-15T05:37:10Z init message: Loading banlist...
2019-06-15T05:37:10Z Cache configuration:
2019-06-15T05:37:10Z * Using 2.0 MiB for block index database
2019-06-15T05:37:10Z * Using 8.0 MiB for chain state database
2019-06-15T05:37:10Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2019-06-15T05:38:03Z Logging: end relogging initial messages
2019-06-15T05:38:03Z UpdateTip: new best=0000000000000046799df07296169b65f1a203c13b22ffe6df812454ca1e6e45 height=1382445 version=0x20000000 log2_work=71.151478 tx=27610552 date='2018-08-09T15:30:58Z' progress=0.622489 cache=1.6MiB(12574txo)
2019-06-15T05:38:03Z UpdateTip: new best=000000000000007cdf5e7a5a62f116cad1bb1ba492df4c8aef6b2f9a56075d9f height=1382446 version=0x20000000 log2_work=71.151519 tx=27611112 date='2018-08-09T15:31:47Z' progress=0.622494 cache=1.6MiB(12585txo)
[.....]

It's great to know the exact version number, that this client doesn't include a wallet, and other configuration things. Note the two "extra" lines that begin with Logging: to show the start and end of this re-logging. The timestamps of the re-logged messages are the original timestamps from when the client actually started (in this case only about a minute earlier); out-of-order timestamps are a little odd, but on the other hand it's nice to know when the client actually started. After the Logging: end relogging initial messages line, the logging continues where it left off before the file reopen (I was doing reindex at the time).

External log rotation tools can be configured to prevent the log file from growing unbounded, see #917. Typically the way these tools work is, they first move (as in, the rename system call) debug.log to a different name. Because the client has an open file handle to this file, it continues to log to it even though it's been moved. Then the log rotation tool sends the client a SIGHUP signal to cause it to close its file descriptor and reopen debug.log. Now it's actually creating a new debug.log file, and future logging goes there. No data are lost during this switch. The log rotation tool can now do whatever it wants with the renamed (old) log file. It may compress it, offload it, or, after some time, delete it.

If it deletes it, the configuration information that this PR causes to be logged during startup no longer exists anywhere.

The latest commit, df89103, re-logs the configuration information whendebug.log is reopened. This guarantees that debug.log always contains the configuration messages. My first idea was to re-log only the configuration file and command line arguments (that are being written by the first part of this PR). But there's a lot of other useful stuff that gets logged at just after startup. Here's what appears in debug.log during my testing, after it's reopened (this does not appear on the console):

There's quite a bit of complexity added to the code to handle this case (e.g. the additional logic in BCLog::Logger::LogPrintStr and the fact m_relog_save is modified across different functions).

In practice, how often does this situation arise and where the missing information would have been helpful? Would it be reasonable for users to configure their log rotation tools to preserve the first log file instead?

The commit message for the test is incorrect: it is a functional test, not a unit test.

I think this PR should be split in two. The two commits on startup, write config options to debug.log and re-log configuration when debug.log is reopened both address logging, but are essentially independent.

I'm a concept ACK for the first commit (on startup, write config options to debug.log) and would like to see it merged, but a weak concept NACK on the second (re-log configuration when debug.log is reopened) since I think it adds unnecessary complexity to the bitcoind code for something that should really be handled externally.

I think it would be better for saving startup debug information to be handled outside of bitcoind. That way there's less confusion about what should/shouldn't get relogged, less code complexity, and users who save all their logs files will not be logging things redundantly.

Concept ACK with reserves regarding the approach and implementation so the changes can be robust, maintainable, safe and adequately covered by tests.

Thanks for the review comments; they're very helpful. The latest commit, b6e55d566a92427f1af9775d676ab629eaacbe41, addresses some of the comments (I'll address the others soon). This was a force-push because of rebase with master.

Thanks for all the review feedback! The most recent force-push removes the second part of this PR (the extra logging that happens when the log rotates). I agree with @narula's and others' opinions that this can be handled outside of bitcoind. I will probably submit a separate PR for relogging the config information on log rotation.

A good way for the log rotation tools to work is to either save all the log files (which may not be practical), or, when rotating the log file, check to see if the file being rotated out includes the start of the currently-running bitcoind instance (it could search for the string Bitcoin Core version). If found, keep the file, or at least that section of the file. Then remember to send that part to a developer or support person requesting debug.log. (It's that "remember" part that makes me wonder if relogging on log rotation might still be a good idea.)

An additional thought related to this part of my most recent comment:

Then remember to send that part to a developer or support person requesting debug.log

Here's a better procedure that the log rotation tool can follow: After moving debug.log to a new name, it can create a new debug.log file and write the initial (configuration-related) messages to it. Then send the SIGHUP signal. The next log message will be appended to debug.log -- after the initial messages. (I verified this behavior.)

@jkczyz, thanks, adding a flag is an excellent idea, implemented in b6e55d5. Does that also address your concern about matching a substring? It seems to me it does, since we're not doing any string or pattern matching at all.

Yeah, looks like FlagsOfKnownArg handles this for you.

Should I wait for a rebase to test this, or is it better if I test it as it is? Or should I try to rebase myself?

@ysangkok, I integrated with the conflicting recent change (7f40528cd50fc43ac0bd3e785de24d661adddb7a) using a separate commit (https://github.com/bitcoin/bitcoin/pull/16115/commits/07f11f171c82bcbd9d79272c8f87002e39a7521b), force-pushed rebase. Now would be a good time to test, thanks.

To give you a little better understanding of what this PR does, here's part of the debug.log file after running one of the functional (python) tests with the -nocleanup option. After the most recent rebase, the config file section string gets printed out (within square brackets):

2019-11-18T22:47:48.371866Z [init] Default data directory /home/larry/.bitcoin
2019-11-18T22:47:48.371882Z [init] Using data directory /tmp/bitcoin_func_test_z99aclji/node0/regtest
2019-11-18T22:47:48.371901Z [init] Config file: /tmp/bitcoin_func_test_z99aclji/node0/bitcoin.conf
2019-11-18T22:47:48.371922Z [init] config-file arg: regtest=1
2019-11-18T22:47:48.371937Z [init] config-file arg: [regtest] bind=127.0.0.1
2019-11-18T22:47:48.371950Z [init] config-file arg: [regtest] discover=0
2019-11-18T22:47:48.371963Z [init] config-file arg: [regtest] dnsseed=0
2019-11-18T22:47:48.371976Z [init] config-file arg: [regtest] fallbackfee=0.0002
2019-11-18T22:47:48.371990Z [init] config-file arg: [regtest] keypool=1
2019-11-18T22:47:48.372002Z [init] config-file arg: [regtest] listenonion=0
2019-11-18T22:47:48.372015Z [init] config-file arg: [regtest] port=14243
2019-11-18T22:47:48.372031Z [init] config-file arg: [regtest] printtoconsole=0
2019-11-18T22:47:48.372049Z [init] config-file arg: [regtest] rpcport=19243
2019-11-18T22:47:48.372072Z [init] config-file arg: [regtest] server=1
2019-11-18T22:47:48.372088Z [init] config-file arg: [regtest] shrinkdebugfile=0
2019-11-18T22:47:48.372106Z [init] config-file arg: [regtest] upnp=0
2019-11-18T22:47:48.372119Z [init] command-line arg: datadir=/tmp/bitcoin_func_test_z99aclji/node0
2019-11-18T22:47:48.372135Z [init] command-line arg: debug
2019-11-18T22:47:48.372150Z [init] command-line arg: debugexclude=libevent
2019-11-18T22:47:48.372165Z [init] command-line arg: debugexclude=leveldb
2019-11-18T22:47:48.372179Z [init] command-line arg: logthreadnames
2019-11-18T22:47:48.372194Z [init] command-line arg: logtimemicros
2019-11-18T22:47:48.372209Z [init] command-line arg: uacomment=testnode0
2019-11-18T22:47:48.372223Z [init] command-line arg: wallet=0
2019-11-18T22:47:48.372236Z [init] Using at most 125 automatic connections (1024 file descriptors available)

It actually could be useful to have this information available when trying to debug or analyze a functional test or the code being tested (although you can figure it out if you study the code enough), because some of these values differ across the tests.

Code review ACK eb973ff916f88ed36b59ae6466ec16dd30811215. Looks good!

I don't know how to write an automated test for these changes, suggestions are welcome.

Could remove this line from the PR description since there are tests now.

Thanks, @ryanofsky, fixed variable names (in two places), rebased, force-pushed. Also, I changed the PR description as suggested, and simplified it (since it goes into the commit history), no need to show sample output there, which was out of date anyway.

Code review ACK 85f44c083d75b71bce149eff4ecdc9b543dd7dfa. Just variable renames and updated PR description since last review

Code review ACK 6d195a8da92b60161669e56de6cbb4a5baafdf84. No changes since last review other than rebase due to conflict from adjacent rpcwhitelist line

Definite concept ACK. This needs a rebase, but I've read the current code and it looks good. I'll re-review once this has been rebased on master.

Rebased onto master, force-pushed 3028a27

Tested ACK 3028a27c5fde8e341cccb743b31a02c1bd7d934d

I've left a couple of small style nit. Feel free to ignore.

ACK 717099eef1cc5670180a58d0fec6d027a1e2f95d

Rebased onto master, squashed, force-pushed.

Code review ACK 4a88ddac84235398a0ea8c041baee7192a6b4d09

Rebased onto master ...

I don't think this needed rebasing on master. It's better not to rebase on master unless necessary, since it generates additional work for reviewers

I don't think this needed rebasing on master. It's better not to rebase on master unless necessary, since it generates additional work for reviewers

Absolutely right, sorry about that; I actually thought of that just after I did that. I'll avoid unnecessary rebases from now on. Thanks for the new ACK.

Concept ACK. Will test.

ACK 4a88ddac84235398a0ea8c041baee7192a6b4d09, I have tested the code on Linux Mint 19.3, including:

• no bitcoin.conf
• duplicated option names in bitcoin.conf and in the command line

Every time it works as expected.

Code review ACK 4a88ddac84235398a0ea8c041baee7192a6b4d09. Just rebase and spelling/capitalization tweaks since last review

@ryanofsky : current branch is 4a88dda

@ryanofsky : current branch is 4a88dda

Thanks fixed comment. That was the hash I meant

Will re-review and test tomorrow.

Tested ACK 4a88ddac84235398a0ea8c041baee7192a6b4d09 modulo comments below.

• My main comment was not saved by GitHub in my review so I am re-adding it below.
• I tested this PR and the suggested changes after rebasing to current master at e7f84503571c171a7e6728cd2d77dd4103bd7a6f.

@jonatack, thanks for the suggestions, force-pushed (without rebasing onto master) both changes. I made one other change that I hope you agree is an improvement: I removed the keywords from the list of unexpected messages, for example, changed rpcuser=satoshi to just satoshi. The reason is, if there was a weird bug by which the log contained (let's say) ruser=satoshi or rpcuser = satoshi (note the spaces around =) or many other variants, this test would still pass. What we really care about is not leaking the values of these settings (the string satoshi) to the log file, so those values are what we should make sure aren't present in the log file.

@LarryRuane

... force-pushed (without rebasing onto master)...

Needless rebasing makes reviewing of consequent changes harder ;) Thank you.

ACK 8c09bf9508b12e3593e4f6d23ed4dcfdabda7f2b, the only change in feature_config_args.py test, tested locally on Linux Mint 19.3.

ACK 8c09bf9508b12e3593e4f6d23ed4dcfdabda7f2b Two comments, feel free to ignore or handle them in a follow-up.

Thanks, I force-pushed the suggested changes.

Code review ACK 8317bb35b63062e0d54de3af19d923456e1cb467. Just new comments, include, test cases since last review

Tested ACK 8317bb35b63062e0d54de3af19d923456e1cb467

git diff 8c09bf9..8317bb3 since last push:

diff --git a/src/init.cpp b/src/init.cpp
index 04305c9b23..6a91c8c1ce 100644
--- a/src/init.cpp
+++ b/src/init.cpp
@@ -1218,6 +1218,8 @@ bool AppInitMain(NodeContext& node)
         // Not categorizing as "Warning" because it's the default behavior
         LogPrintf("Config file: %s (not found, skipping)\n", config_file_path.string());
     }
+
+    // Log the config arguments to debug.log
     gArgs.LogArgs();
 
     LogPrintf("Using at most %i automatic connections (%i file descriptors available)\n", nMaxConnections, nFD);
diff --git a/src/test/getarg_tests.cpp b/src/test/getarg_tests.cpp
index 090c544be3..bebc56c57b 100644
--- a/src/test/getarg_tests.cpp
+++ b/src/test/getarg_tests.cpp
@@ -2,6 +2,7 @@
 // Distributed under the MIT software license, see the accompanying
 // file COPYING or http://www.opensource.org/licenses/mit-license.php.
 
+#include <fs.h>
 #include <util/strencodings.h>
 #include <util/system.h>
 #include <test/util/setup_common.h>
diff --git a/test/functional/feature_config_args.py b/test/functional/feature_config_args.py
index de8461ea5a..ec6268f5fb 100755
--- a/test/functional/feature_config_args.py
+++ b/test/functional/feature_config_args.py
@@ -99,16 +99,16 @@ class ConfArgsTest(BitcoinTestFramework):
                 unexpected_msgs=[
                     'alice:f7efda5c189b999524f151318c0c86$d5b51b3beffbc0',
                     '127.1.1.1',
-                    'satoshi',
-                    'tpass',
+                    'secret-rpcuser',
+                    'secret-torpassword',
                 ]):
             self.start_node(0, extra_args=[
                 '-addnode=some.node',
                 '-rpcauth=alice:f7efda5c189b999524f151318c0c86$d5b51b3beffbc0',
                 '-rpcbind=127.1.1.1',
                 '-rpcpassword=',
-                '-rpcuser=satoshi',
-                '-torpassword=tpass',
+                '-rpcuser=secret-rpcuser',
+                '-torpassword=secret-torpassword',
             ])
         self.stop_node(0)

Launching bitcoind with this PR adds the following lines to the debug log that correctly list all of the custom settings, re-sorted in alphabetical order (first the config file settings, followed by the command line args) between Config file: and Using at most 512 automatic connections:

2020-01-13T19:14:02Z Config file arg: addresstype="bech32"
2020-01-13T19:14:02Z Config file arg: blocksonly="0"
2020-01-13T19:14:02Z Config file arg: dbcache="8192"
2020-01-13T19:14:02Z Config file arg: logips="1"
2020-01-13T19:14:02Z Config file arg: maxconnections="512"
2020-01-13T19:14:02Z Config file arg: maxuploadtarget="0"
2020-01-13T19:14:02Z Config file arg: par="0"
2020-01-13T19:14:02Z Config file arg: rpcpassword=****
2020-01-13T19:14:02Z Config file arg: rpcuser=****
2020-01-13T19:14:02Z Config file arg: server="1"
2020-01-13T19:14:02Z Config file arg: txindex="1"
2020-01-13T19:14:02Z Config file arg: walletbroadcast="1"
2020-01-13T19:14:02Z Command-line arg: dbcache="256"
2020-01-13T19:14:02Z Command-line arg: logips="0"
2020-01-13T19:14:02Z Command-line arg: walletbroadcast="0"

ACK 8317bb35b63062e0d54de3af19d923456e1cb467

re-ACK 8317bb35b63062e0d54de3af19d923456e1cb467

Implemented review suggestions:

• rename DONT_LOG to SENSITIVE
• in the unit test, verify log file contents without opening and reading debug.log

Here are the changes in the last force-push (I think this PR should remain a single commit), in case that's helpful to reviewers: https://github.com/LarryRuane/bitcoin/compare/8317bb35b63062e0d54de3af19d923456e1cb467..03fdf86b6d4bc036c707a0b0d84995f438283b11

ACK 03fdf86b6d4bc036c707a0b0d84995f438283b11

ACK b951b0973c reviewed diff, re-code review, built, ran tests, launched bitcoind and reviewed debug log output, verified value of str debug log in the added unit test.

$ src/test/test_bitcoin -t getarg_tests/logargs -l test_suite
.../...

2020-01-30T20:48:38Z Command-line arg: dontlog=****
2020-01-30T20:48:38Z Command-line arg: okaylog="public"
2020-01-30T20:48:38Z Command-line arg: okaylog-bool=""
2020-01-30T20:48:38Z Command-line arg: okaylog-negbool=false

$ bitcoind -dbcache=512 -logips=0 -walletbroadcast=0
2020-01-30T19:01:24Z Bitcoin Core version v0.19.99.0-b951b0973c (debug build)
2020-01-30T19:01:24Z Assuming ancestors of block 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf have valid signatures.
2020-01-30T19:01:24Z Setting nMinimumChainWork=000000000000000000000000000000000000000008ea3cf107ae0dec57f03fe8
2020-01-30T19:01:24Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2020-01-30T19:01:24Z Using RdSeed as additional entropy source
2020-01-30T19:01:24Z Using RdRand as an additional entropy source
2020-01-30T19:01:24Z Default data directory /home/jon/.bitcoin
2020-01-30T19:01:24Z Using data directory /home/jon/.bitcoin
2020-01-30T19:01:24Z Config file: /home/jon/.bitcoin/bitcoin.conf
2020-01-30T19:01:24Z Config file arg: addresstype="bech32"
2020-01-30T19:01:24Z Config file arg: blocksonly="0"
2020-01-30T19:01:24Z Config file arg: dbcache="10240"
2020-01-30T19:01:24Z Config file arg: logips="1"
2020-01-30T19:01:24Z Config file arg: maxconnections="512"
2020-01-30T19:01:24Z Config file arg: maxuploadtarget="0"
2020-01-30T19:01:24Z Config file arg: par="0"
2020-01-30T19:01:24Z Config file arg: rpcpassword=****
2020-01-30T19:01:24Z Config file arg: rpcuser=****
2020-01-30T19:01:24Z Config file arg: server="1"
2020-01-30T19:01:24Z Config file arg: txindex="1"
2020-01-30T19:01:24Z Config file arg: walletbroadcast="1"
2020-01-30T19:01:24Z Command-line arg: dbcache="512"
2020-01-30T19:01:24Z Command-line arg: logips="0"
2020-01-30T19:01:24Z Command-line arg: walletbroadcast="0"
2020-01-30T19:01:24Z Using at most 512 automatic connections (1024 file descriptors available)

ACK b951b0973cfd4e0db4607a00d434a04afb0d6199 🐪

<details><summary>Show signature and timestamp</summary>

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK b951b0973cfd4e0db4607a00d434a04afb0d6199 🐪
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUgHewwAixdou/20sx/EQar5cdubgAQpvKEAXE9fZwjP6zu0ZBrabem2sc8gsVkD
bvQPvnTscdaIvHkOzkZ860STB+nr77x483AKc+Dl4G4Z4LecMv8iXSQmoVOwlxl2
rsdUVFQnLAUB9phu9RccJwXUyEsoaGAy/sUcoaHwv3nuApqgNZZptjmCUO3lK5sw
vQ/XT30gVZ6xSlfP21ZQaMaqps4MHOB9Z1X5hjnxm49/XMg+4Et3TJKbGyTNwcm6
Ue/raLdaPtq6htfkhMIro9cc95Bfy1Nr9X4fGpte7IAu4waT5bJQVF2EeoQPyh0d
LEOHe5cQPRsUOd5RvzYmCFqGsM5qRZw9BrQ6yUG13c7tYOi4xc7tdCabE8BUgFuR
NqAw90SZMFl8wdDsQHub0H0V5EDxo92YzukM1J+h40OgG3ozZc3dS7SbPhqNpnoN
uul5igOr4HICcNDPDHufDW4WAzvh8PpUlqCQnzF/BKnbYQjGZvhtB7asR4v0lH3w
LtVy1Blz
=hrjv
-----END PGP SIGNATURE-----

Timestamp of file with hash 7113306c6076473032eb8637f29927398a935b895b4ee90467fca953dfb9ba72 -

</details>