Why Your Ethereum Node Keeps Stalling: Common Sync Errors and Practical Fixes

Background and Server Setup

Many developers encounter difficulties when synchronizing an Ethereum node; to investigate, the author provisioned a 2‑CPU, 4 GB RAM CentOS 7.4 server on Alibaba Cloud with a 500 GB high‑performance cloud disk. Upgrading to 4‑CPU/8 GB or higher is recommended, as low resources can trigger later issues.

Node Startup

The node is launched with the official parameters, setting --cache=512 (adjustable based on available memory) to aid data synchronization.

Data Synchronization Issues

Exception 1 – Runtime Poll Wait Errors

goroutine 10855 [IO wait]:
internal/poll.runtime_pollWait(...)
/home/travis/.gimme/versions/go1.9.2.linux.amd64/src/runtime/netpoll.go:173+0x57
... (additional stack frames)

These stack traces typically indicate insufficient memory or I/O resources; a simple restart often resolves the problem.

Exception 2 – Synchronisation Warnings

WARN [02-03|12:54:57] Synchronisation failed, dropping peer =3616e2d0bcacf32f err="retrieved hash chain is invalid"
WARN [02-03|12:56:02] Ancestor below allowance, peer =64e4dd3f53e5c01e number=4843643 hash=000000… allowance=4843643
WARN [02-03|12:58:55] "no peers available or all tried for download"
WARN [02-03|12:59:23] retrying err="receipt download canceled (requested)"
WARN [02-03|13:00:17] retrying err="peer is unknown or unhealthy"
WARN [02-03|13:03:06] retrying err="block download canceled (requested)"
WARN [02-03|13:03:07] retrying err="peer is unknown or unhealthy"

The log shows the node failing to connect to valid peers, encountering invalid hash chains, and repeatedly retrying downloads. To diagnose, run the console command:

> net.peerCount
0

If the peer count stays at zero, wait for a while; if the stall persists, restart the node to force a fresh peer discovery. Adding peers manually can also help. Below is a curated list of public enode URLs that can be added via admin.addPeer:

"enode://6427b7e7446bb05f22fe7ce9ea175ec05858953d75a5a6e4f99a6aec0779a8bd6276f1959a42fe5948acbe14bcd0652082dc546d3b37ae8f2aea41eba4eca43b@121.201.14.181:30303",
"enode://91922b12115c067005c574844c6bbdb114eb262f90b6355cec89e13b483c3e4669c6d63ec66b6e3ca7a3a462d28edb3c659e9fa05ed4c7234524e582a8816743@120.27.164.92:13333",
... (additional enode strings) ...

Adding these peers can restore connectivity.

Exception 3 – Unexpected Geth Shutdown

The node may terminate without explicit logs, often due to the Linux OOM killer when memory is insufficient. The remedy is to increase RAM; alternatively, monitor the process and restart when killed. Enabling swap can prevent OOM kills but will significantly slow synchronization.

Exception 4 – Excessive Import Logs

INFO [02-03|13:07:24] Imported new state entries count=1142 elapsed=5.888ms processed=84671 pending=1907 retry=0 duplicate=0 unexpected=170

When such INFO lines flood the console for hours without advancing the block height, the underlying cause is usually network or disk bottlenecks. Continuing for extended periods is rarely productive; consider aborting the sync and investigating infrastructure.

Personal Experience

The author deployed the server at 18:00, observed rapid initial sync, but the node stalled after reaching within ~200 blocks of the tip. Multiple restarts were required due to OOM kills and the above exceptions. Patience during the long “struct loading” phase (when the node is near the tip) is essential, and frequent restarts should be avoided.