Stuck at block height 17999999 #8796
Labels
imp2
Medium importance
Comments
|
—internalcl |
|
@AskAlexSharov Erigon is stuck at 16999999 and not moving for 2 days. Any other suggestion? |
|
@sebicas no logs - no honey |
|
Having similar issues with goerli sync (tried restarting multiple times) PS: internalcl was added later on, after it got stuck at the block 0x81b31f
|
|
Try some external CL for goerli |
|
Thanks @AskAlexSharov It looks like progression is being made, however I've noticed the service I've setup for Erigon (using the command above, now with If more logs are desired, let me know. The node currently seems to be dormant, sitting at 10k pending TXs; More data leading up to above, including the service crash; |
|
Nevermind, it's alive again! However, it looks like it's starting from the position it was at a couple days ago. :( |
|
@AskAlexSharov you are right, sorry about that. Here is my Erigon config: Logs show some progress, but when I check via RCP it stills stuck at block # 16999999 for over 3 days Here are the latest logs: Any idea what could it be? |
|
If it's "stuck" at some xxx999, that is often an indication that the snapshots(older blocks) are downloaded and executed (or executing). After this erigon will wait for what to do next, has to be directed by the CL (Nimbus, internalcl, etc.) for what new blocks to fetch/execute. |
|
Thanks @somnathb1, that means that the syncing still progressing just fine? |
|
It looks like my node has just crashed for the 2nd time today. Anyone have any suggestions? |
|
Since changing to |
|
I don't see any problem in this logs. probably OOM-killer is not happy at some point. |
|
Thanks @AskAlexSharov Hopefully a system restart will resolve the sync issues. |
|
Same issue here. This problem is mostly caused by erigon-node errors imo, which are usually fixed after node upgrades.
|
|
When mem is high: |
|
Had another crash, trying with OOM killer, disabled. |
|
@caedmo - network? |
|
@AskAlexSharov mainnet Just had another OOM killer event This was after a Will keep digging... |
|
in my case it is stuck at block 18299999, we have tried to upgrade to lastest release 2.55.1, it has been days in the same block, is this normal? how long it will take to process snapshots |
|
@kkx —internalcl |
|
I've given up trying to fix this sync, it's stuck in a loop, breaking and restarting from 18000000 Restarting sync from 0 |
|
After deleting everything and syncing again, back to the exact same issue. Service exits during the sync phase from block 18m+ Updating to 2.56.1, and allowing sync to continue |
|
Attempting to run 2.56.1 - need to resolve missing lib; Aftering |
|
@caedmo use Then make sure the |
|
try add |
|
cc: @battlmonstr |
Hello, is there any solution? I seem to have the same problem |
@caedmo , please try this solution: it copies both erigon binary and a proper version of libsilkworm_capi.so CC @maxmilton , @AskAlexSharov , @yperbasis |
|
Thanks @battlmonstr Erigon now running again. |
|
Running Erigon I am now seeing a much better Erigon log output I'm currently still see seeing block height My payload height has remained current, with the network (great news!). Block bodies aren't, at this time - and are slowly trailing behind, every so often. I'll update here, when I finally reach that ultimate goal of GQL serving latest blocks. The block disparity for me (every 6 hours) of the last 24; What I am seeing on the logs; Seems like I am almost there - hope it helps some of you! If it helps anything, I'm also including all warnings (collated) over the last 24 hours; |
|
Erigon service has been 9/KILL'd twice in the last 24 hours. |
|
I restarted syncing from 0 due to a disk failure; now facing the same issue here (stuck at 18299999). |
|
Erigon reached tip, then threw an error on insertion
Has now restarted sync from 18299999 Also had another OOM a couple hours ago - nothing specific in the logs as to why, and it seems the node continued that time round, instead of restarting sync from snapshot tip |
|
Moved to |
Hi, You are running internalcl while forcing the connection to an externalcl, please turn off the external consensus layer |
Hi, the eth_blockNumber does not work well with Erigon, do logs show progress? |
|
not sure if it is related, but my other (healthy, not stuck) node crashed (it has the "bad blocks" msg from caplin in common) |
External consensus is offline. Unfortunately, saw another error when attempting to insert blocks. Service |
|
After resyncing from scratch my node got stuck at Erigon config Erigon log |
|
@ehsanhajian |
|
@AskAlexSharov yes. I Already added |
|
then you are good |
|
@AskAlexSharov, sorry for asking again. It's been stuck at 18999999 for three days. So, is it normal? Do I need to wait for it to get synced? |
|
i don't know anything about your node: show logs |
|
@AskAlexSharov In logs everything looks good The only thing is when I restart erigon I see filesize mismatch in logs. |
|
Update: after 4 days stuck at 18999999 it paased the block and got fully synced. |
|
it's not "stuck" - it's how erigon works: https://github.com/ledgerwatch/erigon/blob/devel/eth/stagedsync/README.md |
|
@AskAlexSharov is it correct that does not matter whatever pruning I set, it will syncing the same days? I am also stopped on 18999999 and waiting. My prune config (it's already syncing 9 days, NVMe drive) is: |
|
|
|
"stopped on 18999999" - probably you forgot |
|
@AskAlexSharov now it synced, took 12 days. |
|
we recently released more aggressive pruning - see https://github.com/ledgerwatch/erigon/releases/tag/v2.59.0 show "integration print_stages" |
|
@AskAlexSharov yes, I have exactly this version: |
|
@AskAlexSharov so, aggressive pruning does not work as expected? Or I did wrong steps when installing? As I wrote above, I set pruning before 1 Jan 2022. So only 2 years and 4 months took 2.1Tb |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi all
I'm wondering if I'm stuck, given a reused Beacon chain (previously running with Geth), against a fresh Erigon full sync?
Appreciate any help/suggestions!
Notes
Versions
Execution chain: Erigon 2.53.4-c4843268
Beacon chain: Nimbus v23.10.0-8b07f4
Go: go1.20.10 linux/amd64
OS: Fedora 36, Intel XEON
CPU
Erigon configuration
Output
Eventually building over time, to output the same following lines;
Thanks for your help!
The text was updated successfully, but these errors were encountered: