geth v1.8 unable to download the last 65 blocks for the mainnet

Question

Currently running geth 1.8 on Ubuntu 17.10 on an SSD. Anytime I start geth, it will always sync until it hits the last 65 blocks where it just hangs and looks like it stays stuck at downloading the chain structure.

Started geth like so: geth --cache=4192

> eth.syncing
{
  currentBlock: 5111107,
  highestBlock: 5111172,
  knownStates: 334023,
  pulledStates: 319685,
  startingBlock: 5105310
}

startup logs:

INFO [02-17|22:47:12] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-17|22:47:12] Starting peer-to-peer node               instance=Geth/v1.8.0-stable/linux-amd64/go1.8.3
INFO [02-17|22:47:12] Allocated cache and file handles         database=/media/solidity/Data/mainnet/geth/chaindata cache=3144 handles=512
INFO [02-17|22:47:22] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Engine: ethash}"
INFO [02-17|22:47:22] Disk storage enabled for ethash caches   dir=/media/solidity/Data/mainnet/geth/geth/ethash count=3
INFO [02-17|22:47:22] Disk storage enabled for ethash DAGs     dir=/home/solidity/.ethash                        count=2
INFO [02-17|22:47:22] Initialising Ethereum protocol           versions="[63 62]" network=1

Answer 1

The "last 65 blocks" part is normal. When the "fast sync" mode was first introduced in eth/63, it was even more.

I suggest you take a look at that PR for a general description on what geth's --syncmode=fast actually does.

In short: not downloading all the blocks up to the head is done so that chain reorgs can be handled gracefully - especially since the node won't have any earlier "state snapshot" to revert to if a reorg does happen in the time you're syncing, earlier than the pivot block that you're fast-syncing to.

As is mentioned in the comments, after syncing blocks up to the pivot, the node has to also sync the state at the pivot, - which these days takes a while, perhaps even longer than syncing the blocks.

---

Slightly OT:

On slow machines (network or storage IO-wise), if syncing blocks takes too long, by the time a node would start syncing the state, there might not be any peers that actually still have a snapshot of it. (Remember, the network is not just geth peers; some nodes might have a radically different outlook on historic state retention - and what's to be considered "historic".)

A common mistake at this point is restarting the sync after clearing the database. Try without doing that first! Otherwise, you'll have to download the blocks again, likely running into the same issue (over and over).