"Waiting for enough suitable peers before syncing" prefix=initial-sync required=3 suitable=0 #10920
Comments
|
I had exactly the same problem for a couple of days setting up a new server to take part in the upcoming Goerli/Prater merge testing. Geth synced fine with Goerli chain and Beacon connected to local Geth and processed deposits before it went into a "Waiting for enough suitable peers" cycle for over 24 hours. It seem to never reach 3 peers which is required. Tested older versions of Prysm, --bootstrap-node parameter, delete beacon folder and resync a couple of times. My solution was in the end to use an old Prater genesis file.
I hope this information can help to narrow down the cause for this, and help others in the same situation. Test system Beacon-chain config |
|
I'm still running in to this issue. With Goerli and Mainnet and Sepolia. Running from a kubernetes cluster in EKS. The same helm chart/config works fine in 3 of my other clusters, but constantly fails in one. I've tried destroying the data volume, setting "--force-clear-db", and restarting multiple times with different chains. Below is the trace log. I've confirmed the genesis is correct, the Geth node is running normally, and I'm able to telnet to random peers :13000. I notice the "WHOAREYOU" step never happens. Any ideas on how I can further debug this? Here are the responses from a couple prysm endpoints |
|
Assuming you are using the correct genesis file as mentioned above, is port 12000 open ? We use that for discovery via UDP |
|
Is that required to gather outbound peers? We are using the same config in all of our clusters, which contain secure components. Our other clusters were able to acquire an acceptable amount of outbound peers without opening inbound ports |
|
It isnt required, but it does appear something is blocking outbound udp packets in your cluster. So I am not too sure: |
|
@nisdas I was able to confirm that outbound UDP works fine. There is nothing blocking and test packets went through. Any other suggestions? |
|
If I manually add a long list of peers, I am able to retain a couple and start processing blocks. |
|
I worry that these peers will drop over time and the node will not be able to recover. Any ideas on what might be causing the peer discovery to fail in this way? |
|
As suspected, the peers dropped off one by one and eventually the node stopped bootstrapping because of a lack of suitable peers. |
I am not too sure, the fact that your 3 other clusters work might point to some specific issues with firewalls in the current cluster. How did you test the UDP networking ? Were you able to make a roundtrip connection with a remote peer ? Ex: The error logs do indicate that it isn't able to get a response back from the bootnodes. |
|
I am getting the same repeating pattern in the logs. It does not seem to surpass 2 peers in the last 2 hours. I'm trying Goerli. |
|
I'm on arch linux, latest prysm, latest geth. Managed to sync up to latest about a week ago, afterwards gracefully shutdown. Since then for a week: Waiting for enough suitable peers before syncing required=3 suitable=0 Increasing --p2p-max-peers did not solve the issue. Deleting .eth2 and trying to start over did not solve the issue either. |
|
For those stuck on this, either you are running for goerli incorrectly. The correct way is detailed here: If not, it would most likely point to an issue with your firewall. If you have verified the above both are fine and you are still having issues, feel free to ping this issue and I will reopen it. If not, I am closing the issue for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐞 Bug Report
Description
beacon-node sync question. Syncing for about 10 minutes causes this problem:
some info:
sync "deposits=16384" case this question
🔬 Minimal Reproduction
🔥 Error
beacon-node :
validator:
🌍 Your Environment
Operating System:
What version of Prysm are you running? (Which release)
Importantly
see issue:
But there is no problem to solve the substance.
The text was updated successfully, but these errors were encountered: