Stuck with syncing #3708
Comments
|
|
Same issue: |
|
|
|
|
Will check first error today |
|
Hi. I am experiencing the same exact problem running the same version and the same symptoms and build up to the stuck indexing. I have run the commands suggested and have the same output as above apart from the second one: |
|
First |
|
Also, if you have list of 3 commands and first one failed - I don't advise you run second. It may lead to unexpected result. |
|
@IanBarnesZa show |
|
./build/bin/integration state_stages --datadir=~/.local/share/erigon |
|
./build/bin/integration state_stages --datadir=~/.local/share/erigon --unwind=100 --integrity.fast=false |
|
./build/bin/integration stage_bodies --datadir=~/.local/share/erigon --unwind=100 |
|
@mcseemk |
|
./build/bin/integration print_stages --datadir=~/.local/share/erigon |
|
@mcseemk - you have no data. or your datadir is wrong - try manually resolve |
|
The database was fully synced before upgrade from erigon 2022.02.04-beta. The datadir is correct. $ cd ~/.local/share/erigon/ Erigon logs: |
Thanks. This fix worked partially.
The unwind bodies output is shown below. It was stuck with 14378699. The stages and headers unwinding had shown it went back 100 blocks earlier to 14378599.
|
|
@mcseemk "try manually resolve ~": `./build/bin/integration print_stages --datadir=/home/mcs/.local/share/erigon" |
|
./build/bin/integration print_stages --datadir=/home/mcs/.local/share/erigon |
|
@mcseemk ok, now you know what to do |
|
After re-running integration erigon behaves slightly differently, but still seems to be stuck. There are lots of 'Invalidating anchor' messages in logs. |
|
I am having these stuck issue too when testing kiln. on the same machine, I have both geth and erigon running(and lighthouse/prysm too) so hardware or network should not be a factor. geth sync properly throughout but erigon are very iffy, sometimes it works for a while then it stuck which resulting the beacon node(doesn't matter if it is lighthouse/prysm) starts to complain. If I switch them back to geth, everything works fine |
|
I am having exactly the same behaviour as mcseemk, after resolving the ~ into a full path all three commands worked, and upon startup it went through many blocks, but is now stuck on the same block it was previously with the same Invalidating Anchor error. |
|
@IanBarnesZa we are investigating. you can try unwind |
|
I tried the 'unwind' but it gives me incompatible genesis, I am running the kiln testnet though |
|
set --chain parameter |
|
--chain kiln give me segfault panic: runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: |
|
about Klin better ask in #3451 |
|
@garyng2000 for Kiln, make sure that you run from My command-line for Kiln is see this guide: https://hackmd.io/@4_PBxu6jQtO7qASCOn0H6w/ByrxApj-9 |
|
@mandrigin many thanks 3dbd6be seems to be the culprit as I pull/build again which contains this commit and now seems to be working fine(without any change to other params as it was sort of working but just stuck after a while) |
|
@garyng2000 yep, it fixes a root hash miscalculation at one of the post-merge blocks and similar ones. Without this fix it is impossible to go beyond that block, Erigon goes into a loop. |
|
I'm seeing this as well. I get repeated I did rewind a couple of times (rewound 100, 100, 1000, and 2000 blocks) And now get this: I thought it was a little odd that all the stages after Execution were set back, but Finish wasn't. |
|
Hey Having the same issue here on mainnet. Unwind 100 and 1000 didnt help |
|
To round up my story with stuck with sync, I did another sync for 3 days. I have a working chain data again. |
|
@leafyoung from the start? |
Yes, from the start. I reported earlier that unwinding of bodies was not successful. If this could work, I would guess that re-syncing could be avoided.
|
|
also having the same issue on mainnet. reverting back 1000 or 5000 blocks does not work. is resyncing the entire chain the only option? |
|
Looks like it is for the moment being |
|
You also may try to increase --maxpeers flag (it helped some people on BSC network) |
|
Sadly have the same issue for ropsten with erigon 2022.03.1-beta: |
|
try new release, thanks |
|
just hit this on latest Peers were > 0, Just kept looping like: |
|
good to hear |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Erigon version: erigon version 2022.99.99-dev
OS & Version: Linux
Commit hash : 10aee02
Expected behaviour
I have finished the initial full sync and expected erigon will repeat the cycle of staged sync for new blocks.
Actual behaviour
But it has ever stuck with block=14378699. The screen output is
I noticed that mbox file was last modified a few days ago. It was not updated.
Steps to reproduce the behaviour
I would like to provide more information as requested. Thanks.
Backtrace
The text was updated successfully, but these errors were encountered: