Before daemonization, just probe the data directory lock and print an
early error message if possible.
After daemonization get the data directory lock again and hold on to it until exit
This creates a slight window for a race condition to happen, however this condition is harmless: it
will at most make us exit without printing a message to console.
$ src/bitcoind -testnet -daemon
Bitcoin server starting
$ src/bitcoind -testnet -daemon
Error: Cannot obtain a lock on data directory /home/orion/.bitcoin/testnet3. Bitcoin Core is probably already running.
UnloadBlockIndex is only used during init if we end up reindexing
to clear our block state so that we can start over. However, at
that time no connections have been brought up as CConnman hasn't
been started yet, so all of the network processing state logic is
empty when its called.
Additionally, the initialization of the recentRejects set is moved
to InitPeerLogic.
This adds a new CValidationInterface subclass, defined in main.h,
to receive notifications of UpdatedBlockTip and use that to push
blocks to peers, instead of doing it directly from
ActivateBestChain.
Simplified version of #8278. Assumes that every OS that (a) is supported
by Bitcoin Core (b) supports daemonization has the `daemon()` function
in its C library.
- Removes the fallback path for operating systems that support
daemonization but not `daemon()`. This prevents never-exercised code from
ending up in the repository (see discussion here:
https://github.com/bitcoin/bitcoin/pull/8278#issuecomment-242704745).
- Removes the windows-specific path. Windows doesn't support `daemon()`,
so it don't support daemonization there, automatically.
Original code by Matthew King, adapted by Wladimir van der Laan.
This was broken by 63cafa6329.
Note that while this fixes the settings, it doesn't fix the actual usage of
-maxuploadtarget completely, as there is currently a bug in the
nOptimisticBytesWritten accounting that causes a delayed response if the target
is reached. That bug will be addressed separately.
In the case of (for example) an already-running bitcoind, the shutdown sequence
begins before CConnman has been created, leading to a null-pointer dereference
when g_connman->Stop() is called.
Instead, Just let the CConnman dtor take care of stopping.
CConnman then passes the current best height into CNode at creation time.
This way CConnman/CNode have no dependency on main for height, and the signals
only move in one direction.
This also helps to prevent identity leakage a tiny bit. Before this change, an
attacker could theoretically make 2 connections on different interfaces. They
would connect fully on one, and only establish the initial connection on the
other. Once they receive a new block, they would relay it to your first
connection, and immediately commence the version handshake on the second. Since
the new block height is reflected immediately, they could attempt to learn
whether the two connections were correlated.
This is, of course, incredibly unlikely to work due to the small timings
involved and receipt from other senders. But it doesn't hurt to lock-in
nBestHeight at the time of connection, rather than letting the remote choose
the time.
waitfornewblock waits until a new block is received, or the timeout expires, then
returns the current block height/hash.
waitforblock waits for a specific blockhash, or until the timeout expires, then
returns the current block height/hash. If the target blockhash is the current
tip, it will return immediately.
waitforblockheight waits until the tip has reached a certain height or higher,
then returns the current height and hash.
waitforblockheight is used to avoid polling in the rpc tests.
Gregory Sanders