The best log rotation method formerly available was to configure
logrotate with the copytruncate option. As described in the logrotate
documentation, "there is a very small time slice between copying the
file and truncating it, so some logging data might be lost".
By sending SIGHUP to the server process, one can now reopen the debug
log file without losing any data.
Acquire an exclusive, advisory lock before sending output to debug.log
and release it when we're done. This should avoid output from multiple
threads being interspersed in the log file.
We can't use CRITICAL_SECTION machinery for this because the debug log
is written during startup and shutdown when that machinery is not
available.
(Thanks to Gavin for pointing out the CRITICAL_SECTION problems based
on his earlier work in this area)
Remembering all time samples makes nTimeOffset slow to respond to
system clock corrections. For instance, I start my node with a system
clock that's 30 minutes slow and run it for a few days. During that
time, I accumulate 10,000 offset samples with a median of 1800
seconds. Now I correct my system clock. Without this change, my node
must collect another 10,000 samples before nTimeOffset is correct
again. With this change, I must only accumulate 100 samples to
correct the offset.
Storing unlimited time samples also allows an attacker with many IP
addresses (ex, a large botnet) to perform a memory exhaustion attack
against Bitcoin nodes. The attacker sends a version message from each
IP to his target, consuming more of the target's memory each time.
Time samples are small, so this attack might be impractical under the
old code, but it's impossible with the new code.
The full list of time samples is rarely useful outside of debugging.
The node's time offset, however is useful for discovering local clock
drift, so it's displayed in all logging modes.
This RPC is exactly identical to getblockcount. This duplication
dates back to commit 22f721dbf2 when
Satoshi created the RPC interface.
There's no need to have both, so we standardize on "count" which
matches the naming convention in getconnectioncount.
Following the tradition established with previously deprecated APIs,
getblocknumber continues to work, but it's not listed in the help
system.
Michael Hendricks