RNode version 0.6.4
The RNode software is quickly developing a reputation for being verbose. All that output is helpful for developers debugging and also for validators and node operators monitoring the health of their node. But it isn't valuable if you don't know how to read it.
Here I'll summarize the main interactions your node has, and translate the most common and useful log messages.
At startup your node generates any necessary files that don't already exist, gets familiar with your network configuration, and reports some useful information about itself.
[main] INFO c.r.n.configuration.Configuration$ - Using configuration file: .../rnode.toml
[main] WARN c.r.n.configuration.Configuration$ - Configuration file .../rnode.toml not found
RNode looks for configuration options in a configuration file. It is telling you where it looked for that file and whether or not it was found. In this case it wasn't.
[main] INFO c.r.n.configuration.Configuration$ - Starting with profile default
There are two profiles, default, and docker. You probably only want profile docker if you're actually running docker.
INFO - trying to open ports using UPnP....
INFO - No gateway devices found
INFO - No need to open any port
RNode uses UPnP to reach the internet when behind a router. In this case there was no router. If you have a router you'll see more output here
[node-io-9] INFO c.r.node.configuration.Configuration - flag --host was not provided, guessing your external IP address
[node-io-9] INFO c.r.node.configuration.Configuration - guessed ... from source: AmazonAWS service
You can use the --host flag to set a hostname for your system. When in doubt it's better not to use --host because ip address detection almost always works, as it has here.
Using data_dir: .../.rnode
RNode always needs a data directory (or data_dir) It tells you what directory it is using to avoid any possible confusion.
No certificate found at path .../.rnode/node.certificate.pem
Generating a X.509 certificate for the node
Generating a PEM secret key for the node
RNode needs a TLS certificate. In this case it hasn't found one so it generates a new one.
[node-io-9] INFO coop.rchain.node.NodeRuntime - RChain Node 0.6.4 (7d632567a616e6e63d4fca081191afae0a4d458d)
Tells you what version of RNode you're running. Git hash is included because sometimes the same version number is used multiple times 🤦
[node-io-9] INFO o.h.b.c.nio1.NIO1SocketServerGroup - Service bound to address /0:0:0:0:0:0:0:0:40402
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - _ _ _ _ _
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - | |_| |_| |_ _ __| | | ___
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - | ' \ _| _| '_ \_ _(_-<
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - |_||_\__|\__| .__/ |_|/__/
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - |_|
[node-io-9] INFO org.http4s.server.blaze.BlazeBuilder - http4s v0.19.0-M1 on blaze v0.14.0-M3 started at http://[0:0:0:0:0:0:0:0]:40402/
TODO Not totally sure about these. There is one for port 40402 and another for the diagnostics port 40403
[node-io-9] INFO coop.rchain.node.api.GrpcServer$ - gRPC server started, listening on
[node-io-9] INFO coop.rchain.node.NodeRuntime - Listening for traffic on rnode://...:40400.
RNode is letting you know what ports and addresses it is listening on. It is actually a bug that the first line is incomplete
In a peer to peer network, you begin by calling up one other node that you know about. Once you've connected to that first peer, you ask it where you can find some other peers to connect to. At the same time new peers may also be calling you.
[grpc-default-executor-114] INFO coop.rchain.comm.rp.Connect$ - Initialize protocol handshake to rnode://...
You're reaching out to a peer that you've heard of trying to establish a connection
[main-io-43] DEBUG c.r.comm.transport.TcpTransportLayer - Creating new channel to peer rnode://...
???
[grpc-default-executor-112] DEBUG c.r.comm.transport.TcpTransportLayer - Disconnecting from peer rnode://...
???
[grpc-default-executor-0] INFO coop.rchain.comm.rp.Connect$ - Peers: 24.
Your peer-count has changed to 24. This message does not tell you whether you gained or lost a peer to reach 24.
When a network first launches like the testnet launch in Berlin, the genesis validators must all agree on the state of the genesis block. There is a special protocol for proposing and signing a genesis block.
[grpc-default-executor-98] INFO c.r.c.util.comm.CasperPacketHandler$ - Received ApprovedBlock message while in GenesisValidatorHandler state.
Your node received an Approved Block (completed genesis block) while it was still expecting to receive a candidate that it could compare to expectations. You've probably used the --genesis-validator flag after the genesis ceremony was complete.
[grpc-default-executor-98] WARN coop.rchain.casper.Validate$ - Received invalid ApprovedBlock message not containing enough valid signatures.
You've received an approved block that many other validators have signed off on. But it doesn't match your expectations. You've either made a mistake launching your genesis validator node, or a cartel of validators is succeeding in overtaking the network.
[grpc-default-executor-98] INFO c.r.c.util.comm.CasperPacketHandler$ - Invalid ApprovedBlock received; refusing to add.
You've received an approved block that doesn't match your expectations. It will not be added to the DAG.
[node-io-394] INFO c.r.c.u.comm.BlockApproverProtocol - Received expected candidate from rnode://... Approval sent in response.
The bootstrap node has sent you a candidate for the genesis block that matches your expectations. Your node has crytographically signed this candidate and reported back to the standalone node who is collecting signatures.
[grpc-default-executor-2] WARN c.r.c.u.comm.BlockApproverProtocol - Received unexpected candidate from rnode://... because: Candidate deploys do not match expected deploys.
The bootstrap node has sent you a candidate for the genesis block that does not match your expectations. In this case the mismatch was in deploys, but it could also be in timestamp, or required signatures. Because it didn't match your expectations, you have not signed the block. You've either made a mistake launching your genesis validator, or a malicious standalone node it attempting to launch a network with different parameters.
[node-io-10] INFO c.rchain.casper.util.comm.CommUtil$ - Sending request for ApprovedBlock to rnode://...
[grpc-default-executor-2] INFO c.rchain.casper.util.comm.CommUtil$ - Received response from rnode://... Processing...
[grpc-default-executor-2] INFO c.r.c.util.comm.CasperPacketHandler$ - Valid ApprovedBlock received!
If you join the network as a validator after the genesis ceremony is complete, you need to get the approved block from a peer who knows about it -- probably a genesis validator.
When a validator proposes a new block, they send it to all of their connected peers. In order for the block to make it around the network validators must relay blocks. When you hear of a block that you don't have yet, you ask your peers whether they have it. You'll see messages about peers sending you blocks and asking you whether you have blocks.
[node-io-371] WARN coop.rchain.casper.Validate$ - Ignoring block b0cfe2168d... because block creator 84aa8570bd... has 0 weight.
You've received a block, but the person who created it is not a validator (has 0 weight) so you're not adding the block to your DAG
[node-io-94] INFO c.rchain.casper.MultiParentCasper$ - New fork-choice tip is block eb6e09cf0c....
The fork-choice rule has determined that the block whose hash starts with eb6e is the new tip. Your DAG has been updated accordingly
[node-io-389] INFO c.rchain.casper.comm.CommUtil$ - Requested missing block ... from peers
Your node heard of a block that it hasn't yet seen. It has asked all of its active peers whether any of them have seen the block and is hoping to receive news of it.
[node-io-389] INFO c.rchain.casper.comm.CasperPacketHandler$ - Received block with missing elements
Your node has received a block that ???
Block....... is already being processed by another thread
You received the same block twice in rapid succession. The first receipt is currently being added to your DAG, but is not done yet. If there had been more time between the two receipts of the block, you would have received the Received block again message.
[node-io-389] INFO c.rchain.casper.comm..CasperPacketHandler$ - Received block ... again
You've received a block that you already knew about. Most likely two different peers have gossiped you the same block.
[grpc-default-executor-98] WARN c.r.c.util.comm.CasperPacketHandler$ - MultiParentCasper instance not created.
???
If your grpc interface is exposed you may receive deploys of outside code or evaluations of off-chain rholang code.
[grpc-default-executor-6] INFO c.rchain.casper.MultiParentCasper$ - Received Deploy #...
Code was deployed to your validator node. It is waiting in a queue on your node and will be packaged up into a block in the future. For now, you may need to force a propose if you actually want the code to mvoe around the network.