-
Notifications
You must be signed in to change notification settings - Fork 20.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synchronisation failed, dropping peer - even from trusted local 2nd node #16825
Comments
I got the same issue @SvenMeyer. Geth server usually get "Synchronisation failed, dropping peer" and make server sync slow. I also got it more after upgrade server to v1.8.9-stable. |
I got same problem with one geth node after I upgrade from v1.8.8-stable to v1.8.9-stable. System informationGeth Version: 1.8.9-stable console logs
and the geth console get stuck.When I try to restart the geth command using ctrl +C.The geth get stuck on
|
I upgrade to v1.8.10-stable and everything seems to be okay now. |
@keysonZZZ I have already updated to v1.8.10-stable but it got the same issues in v1.8.9-stable :(.
It "Synchronisation failed, dropping peer" many time and make sync block very slow |
I have the same experience. Upgraded both my local nodes to 1.8.10, still the nodes produce timeouts, are often 20 - 30 blocks behind. |
@SvenMeyer I think it will make the server catching up with the latest blocks. But why should we need to open connection to the outside again, could you explain more about it, pls? |
@pk209 (as far as I understand), if you open the 30303 port to the outside world, then other nodes can also discover your node. In that case the number of nodes mine was connected to also jumped from about ~ 5 to about 45 ! ... I also enabled to accept (up to 2) LightClients, which increased the upload data volume by quite at lot and made the node even more unstable .... |
Same problem here. Can't get Geth stable since one month. Constantly peer timeouts and sync faillures. Tried different servers, all versions of Geth . |
Confirm the issue. On one of my nodes. Hangs on block 5756748, now actual block 5757090.
|
Daemon stopped and deleted all except for folder with blockchain, only [ /nodes/, transactions.rlp, /ethash/ ], the daemon works. Then after some hours hangs again. |
is there a solution to this issue. Seems this is in the queue for long and no one has a reason on How to resolve this. Mostly restarting geth does the trick, but it's lot manual work. The transaction drops peers every now and then and blockchain is out of sync. |
after waiting for a while my node continue to sync 1.8.11 |
Having this issue on 1.8.11-stable. Restarted a couple times. Now, it just hangs on IPC endpoint opened. |
As right now the only solution to bring it back is restarting the nodes. So is it possible to setup 2 geth nodes(Server 01 and Server 02) and protect the nodes in a private network like the temp solution, connect 01 and 02. And then expose 01 as your mainly work node for application, on the contrast, server 02 used to make sure it sync the latest blocks by automatically restart in 30 mins or etc. Then the server 01 can sync the latest block from your server 02. |
I gave it up. Dead end. I can't get Geth stable last 2 months. Tried different servers, different locations in the world , tried it several times. Nodes will sync first and but after a few minutes they will start dropping peers and failing sync. Don't understand why the Geth developers can't make this stable. |
I gave up as well. I do not understand if/how other people manage to get the geth nodes running stable. I recently upgraded to 1.8.12, but as soon as the node catches up to the lasted block, then the problems start: "Synchronisation failed, dropping peer" , even with 2 nodes within the same network. |
I have three nodes running on the same network, even they fall out of sync with each other with 100+ blocks occasionally... I've had some luck the last day or so with blocking port 30303 ingress on nodes you need to fetch very recent data from, we'll have to see how this goes though. |
I've had this similar problem |
1.8.17 |
1.8.17 |
is #18072 related to this issue? |
I think I'm seeing this issue.
Then it happened again 20 minutes later.
And again right now:
Closing port 30303 might help, but that doesn't seem like a good suggestion for the network as a whole. EDIT: Actually, I just checked and port 30303 is closed on my node. |
Constant issue. Managed to see Geth spit out a combination of "time out" and "block download canceled" (mostly timeout) for 5 hours solid before I intervened with a reset. |
This ticket is stale -- the p2p networking is changed from time to time, and we there's no real info we can use here to investigate. The last issue from @marcosmartinez7 is unrelated (Clique deadlock), and from @wysenynja -- that looks good, if it drops peers sometimes but continues syncing it's not an issue, it's to be expected. |
I am still seeing this issue at random. My node has run fine for about a month, but now suddenly I cannot find peers. |
1.8.27 same. seriosly.... |
Sorry for the delay. @holiman, when my node drops peers, it stops syncing. I restart it manually and it starts catching up right away. There is definitely a bug here that needs investigating. I don’t check my node every day so I don’t usually notice until I see my server CPU load is lower than normal. Then I’ll check and see that the latest block is like 3 days behind. I’m contemplating just checking the node every hour with a cron script and restarting it. Not very graceful, but it should work |
Check that the system time is correct. If the node's clock is materially off then the node will not synchronize or function properly. ... at least that is my experience. |
time is always automatically synced with ntp |
In windows, when i made time sync automatically from windows server, the error is fixed and i managed to stake |
System information
Geth Version: 1.8.9-stable
Git Commit: ff9b146
OS & Version: Linux Mint 18.3
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.10
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go-1.10
Expected behaviour
geth should sync and download new blocks block by block
Actual behaviour
Synchronisation failed, dropping peer
Steps to reproduce the behaviour
I have two nodes in my local net work
192.168.1.201
geth 1.8.9-stable
Lubuntu 18.04
192.168.1.202
geth 1.8.9-stable
Linux Mint 18.3
both nodes know each other and show up in the peer list
node ...201 is syncing fine
node ...202 produces a lot of "Synchronisation failed, dropping peer" message even for the definitely "not bad" other node ...201 (peer=81b95b9bc444563d)
Backtrace
The text was updated successfully, but these errors were encountered: