1

to be honest, I'm already tired of fighting with the eternal geth bugs. Now, after a hosting failure, the node, which had been working normally for weeks, stopped syncing and hung on "Syncing: state healing in progress". In the geth console, web3.eth.blockNumber returns 0. Prysm beacon client is fine, and continues approving blocks. I studied this problem on the Internet, and tried everything that was offered to me, including changing geth builds to unstable. None of this helped me. I notice that only block headers are imported, and block receipts are imported a little bit at node startup, but then I only see such messages:

Feb 19 10:25:27 Imported new block headers               count=1    elapsed="364.699µs" number=16,661,727 hash=ee51c8..aabdb1
Feb 19 10:25:27 Downloader queue stats                   receiptTasks=0    blockTasks=0    itemSize=276.22KiB throttle=950
Feb 19 10:25:35 Syncing: state healing in progress       [email protected]    [email protected]   [email protected] nodes=18,720,[email protected] pending=14404
Feb 19 10:25:37 Forkchoice requested sync to new head    number=16,661,728 hash=e33a23..70c586
Feb 19 10:25:39 Imported new block headers               count=1    elapsed=4.820ms     number=16,661,728 hash=e33a23..70c586
Feb 19 10:25:43 Syncing: state healing in progress       [email protected]    [email protected]   [email protected] nodes=18,722,[email protected] pending=14328
Feb 19 10:25:48 Forkchoice requested sync to new head    number=16,661,729 hash=55444d..ef9584
Feb 19 10:25:51 Imported new block headers               count=1    elapsed="404.091µs" number=16,661,729 hash=55444d..ef9584
Feb 19 10:25:51 Syncing: state healing in progress       [email protected]    [email protected]   [email protected] nodes=18,723,[email protected] pending=14227

here is the command I use to launch the node:

/geth/geth/geth --cache 2048 --maxpeers 16 --syncmode full --datadir /ethereum/execution --http --http.api eth,net,engine,admin,web3

Improve this question

1 Answer 1

Reset to default
1

You are currently starting Geth as a full node, from geth docs source:

A full block-by-block sync generates the current state by executing every block starting from the genesis block. A full sync independently verifies block provenance as well as all state transitions by re-executing the transactions in the entire historical sequence of blocks. Only the most recent 128 block states are stored in a full node - older block states are pruned periodically and represented as a series of checkpoints from which any previous state can be regenerated on request. 128 blocks is about 25.6 minutes of history with a block time of 12 seconds. To create a full node pass --syncmode full at startup.

Also, by default, full sync mode have a internal cache default value equals to 4096 and you are lowering it, it can reduce the performance.

Executing every block could take really a long time, did you really need to start a node as a full node? Try the default "snap" sync mode, you can find more on the source page linked before

Improve this answer
1
  • I really need a full node. As for the cache, I increased it, and did not notice any changes. At startup, I see that the last full block is 0: Loaded most recent local full block number=0 hash=d4e567..cb8fa3 td=17,179,869,184 It seems that full mode should behave in a different way
    – Mod diller
    Feb 20 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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