3

I've been trying to maintain a full node for several months. It seemed to be working until I noticed zero balances this morning. etherscan.io site confirmed that balances are not zero, so investigating further, I see on my node that in spite of having accumulated a terabyte of blockchain, and until recently been able to view balances properly:

> eth.getBlock("latest").number
 0

But:

> eth.syncing 
{
   currentBlock: 8225916,
   highestBlock: 8226042,
   knownStates: 85829054,
   pulledStates: 85828145,
   startingBlock: 8224824 
}

The process running this has always been:

31300 pts/12   Sl+  222:33 /cnodes/engines/bin/geth --syncmode full --cache=2048 --rpc --maxpeers 100 --verbosity 2

Yet I see messages logged like this:

 WARN [07-26|07:10:11.117] Dropping unsynced node during fast sync  id=711b6ab8f303771e conn=dyndial addr=103.75.212.222:30303  type=Geth/v1.8.2-stable-b8b9f7f4/linux-amd64/go1.9.4

I am wondering what I might have done to put it in this state, perhaps by restarting geth in bad circumstances such as after running out of space and providing more. I have always specified full sync. This is certain because it is script driven and the option is hard coded. I'd much appreciate any enlightenment that anyone can offer.

Bill Michaelson
  • 151
  • 6
  • What version of geth are you using? There was a fork on February 2019 you need to have at least geth v1.8.22. – Ismael Jul 26 '19 at 16:10
  • 1.8.27 -

    root@merle:/cnodes/engines# sum bin/geth 44498 32749 root@merle:/cnodes/engines# sum geth-linux-amd64-1.8.27-4bcc0a37/geth 44498 32749

     – Bill Michaelson Jul 26 '19 at 20:19
  • How many peers are connected to your node? Are you behind a NAT? In a node we have observed that after some time it is left with a single peer and it will stop downloading from it, usually after restarting the node it will start syncing again with the same peer. – Ismael Jul 28 '19 at 06:28
  • Two peers shortly after restarting just now (see below). Yes, behind NAT.

    `

    admin.peers.forEach(function(value){console.log(value.network.remoteAddress+"\t"+value.name)})

    208.88.169.151:30303 Geth/v1.9.1-stable-b7b2f60f/linux-amd64/go1.11.5

    52.38.189.178:30303 Geth/v1.9.0-stable/linux-amd64/go1.10.4 `

     – Bill Michaelson Jul 29 '19 at 20:41
  • Update: I see messages like this in log now:

    WARN [07-29|16:33:20.621] Node data write error err="state node 3c5221…6471a8 failed with all peers (2 tries, 2 peers)"

     – Bill Michaelson Jul 29 '19 at 20:49
  • You have very few peers, forwarding port 30303 should make you available to more peers. – Ismael Jul 30 '19 at 13:48
  • It was just an example. I've been running this configuration for several months and have observed dozens of peers at times. But if insufficient peers is indeed related to the problem, can you explain the causality please? Or are you firing a shotgun? Not trying to be difficult, just assessing probable best course of action. I'm currently rolling back 2 million blocks to see if the behavior persists there. – Bill Michaelson Jul 31 '19 at 08:15
  • If you are behind a nat your external ip is not listening in the p2p port 30303, so if a peer tries to reach you for the first time it will fail. It ony works if you start the connection. – Ismael Jul 31 '19 at 13:46
  • Thank you, I'm familiar with NAT and I understand that. I've always assumed that the protocol delivers new peer addresses from established peers to the application to enable peer connection proliferation. So a single connection can bootstrap multiple connections. This aside, how does a paucity of connections relate to the problem at hand? This is what I'm trying to understand. – Bill Michaelson Jul 31 '19 at 17:58
  • Update: my rollback completed and I restarted geth with the same configuration. Now eth.getBlock("latest").number shows 6214994 nearly instantly instantly upon restart. My balances are once again visible. I will checkpoint and preserve snapshots more carefully so that when/if the behavior recurs I will have some chances of identifying where in the process the failure occurs. – Bill Michaelson Jul 31 '19 at 18:04

0 Answers0