3

I'm using geth to connect to the rinkeby network with fast sync. However, every time I restart geth I receive the following output:

Maximum peer count                       ETH=25 LES=0 total=25
Starting peer-to-peer node               instance=Geth/v1.8.2-stable-b8b9f7f4/windows-amd64/go1.9.2
Allocated cache and file handles         database=C:\\Users\\<name>\\AppData\\Roaming\\Ethereum\\rinkeby\\geth\\chaindata cache=768 handles=1024
Persisted trie from memory database      nodes=355 size=65.27kB time=971.4µs gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
Initialised chain configuration          config="{ChainID: 4 Homestead: 1 DAO: <nil     DAOSupport: true EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 1035301 Constantinople: <nil     Engine: clique}"
Initialising Ethereum protocol           versions="[63 62]" network=4
Head state missing, repairing chain      number=1926960 hash=1246ad…3bfcb0
Rewound blockchain to past state         number=1925246 hash=119ab4…1e5f81
Loaded most recent local header          number=1926960 hash=1246ad…3bfcb0 td=3569384
Loaded most recent local full block      number=1925246 hash=119ab4…1e5f81 td=3566020
Loaded most recent local fast block      number=1926960 hash=1246ad…3bfcb0 td=3569384
Loaded local transaction journal         transactions=0 dropped=0
Regenerated local transaction journal    transactions=0 accounts=0
Blockchain not empty, fast sync disabled 
Starting P2P networking 
UDP listener up                          self=enode://<address>
RLPx listener up                         self=enode://<address>
IPC endpoint opened                      url=\\\\.\\pipe\\geth.ipc

It then starts to sync after some peers were discovered, but it always throws me back 500-3000 blocks. This is quite annoying, because my PC is pretty slow and when I close geth by accident or because I don't need it for a while, I always have to wait a few extra minutes until I'm in sync again.

Does anyone have a clue what is causing this? This happened to me with geth 1.8.0, 1.8.1 and 1.8.2.

2

If you kill the geth instance or it crashes, it won't write the latest status of the cache, and will be forced to drop the "fast" sync state and fall back to the last "full" state on next startup.

Graceful shutdown options: SIGINT, SIGTERM, Ctrl+D (if run with a console), Ctrl+C1

Unsafe shutdown options: SIGQUIT, SIGKILL, Windows' [X] button

First make sure that the way you are shutting down Geth results in a clean shutdown. Check <data_dir>/geth/chaindata/LOG. It must end with:

xx:xx:xx.xxxxxx db@close closing
xx:xx:xx.xxxxxx db@close done

If it does, start Geth, wait for it to sync, then cleanly shut down and restart. That should fix the state.

If it doesn't and you have more than one node, try these steps:

  1. Make sure you have the original genesis file.
  2. geth removedb
  3. geth init genesis.json
  4. Start and wait for for the node to sync, then cleanly shut down.

1 Ctrl+C does not always shut down Geth cleanly, e.g. not in combination with the js option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.