Sorry for the churn on this, but the current message (introduced in #9073)
isn't acceptable:
$ src/bitcoin-cli getinfo
rpc: couldn't connect to server
(make sure server is running and you are connecting to the correct RPC port: -1 unknown)
Putting the error code after the words "RPC port" made me wonder whether
there was a port configuration issue.
This changes it to:
$ src/bitcoin-cli getinfo
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)
As orphan state is now "network state", like in
d6ea737be1,
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.
This was misnamed, resulting in a warning message and missing
functionality. I'm not sure what the change in behavior will be here,
this needs testing.
Also remove connection to non-existing slot "test".
This was used for testing if the signal arrived. It is no
longer necessary.
Fixes:
2016-12-01 10:04:06 GUI: QObject::connect: No such signal PeerTableModel::layoutAboutToChange() in qt/rpcconsole.cpp:518
2016-12-01 10:04:06 GUI: QObject::connect: (receiver name: 'RPCConsole')
2016-12-01 10:04:06 GUI: QObject::connect: No such slot RPCConsole::test() in qt/rpcconsole.cpp:781
2016-12-01 10:04:06 GUI: QObject::connect: (receiver name: 'RPCConsole')
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.
When generating a new service key, explicitly request a RSA1024 one.
The bitcoin P2P protocol has no support for the longer hidden service names
that will come with ed25519 keys, until it does, we depend on the old
hidden service type so make this explicit.
See #9214.
Jonas Schnelli