If all mining stop for few hours, network peers will colapse? #1890
Comments
|
Can you show some logs of the stuck nodes? |
|
I remember that qt wallet show all the time stuck, that was in sync process since the last generated block. Give me some hours to provide logs. |
|
Did it show that block sync was stuck or MN sync? Was the wallet freshly started or did it run for some time and then suddenly showed a stuck sync? Did you continue mining when you've seen that and if yes, did the Qt wallet get synced? |
|
I was mining fine for ~2 days, all the network was fine until I stop mining for ~12 hours or a little more. In my setup network don't have yet masternodes online, but it worked in that way until mining stop. In some hours will provide logs and more info. |
|
Logs before the problem, at one node 2018-01-30 12:27:47 CInstantSend::CheckAndRemove -- Lock Candidates: 0, Votes 0 |
|
In the hours with zero mining we see this logs at one node: 2018-01-31 18:36:08 CMasternodeMan::CheckAndRemove -- Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, nDsqCount: 0 |
|
After some hours without mining the logs change to this at nodes 2018-01-31 21:54:20 ThreadSocketHandler -- removing node: peer=428 addr=ip2:34706 nRefCount=1 fNetworkNode=0 fInbound=1 fMasternode=0 real ip port replaced |
|
Network looks stuck at block=1401 |
|
New nodes in the network get stuck in a loop with this log repeated >> 2018-02-02 01:15:23 trying connection 219.25.22.23:9999 lastseen=0.1hrs |
|
Main reason looks >> |
|
header is detected as invalid from all peers, will be reviewing the related code |
|
Will try now, set one node without internet and put date before the problem(~block 1401 date) at the related computer. |
|
Hmm not sure which behavior you expected, but what you observe seems to be normal. The "ERROR: detected bad peer for initial headers sync, disconnecting" you see means that it connected to a peer which did not provide recent enough HEADERs to be considered as up-to-date, which is to be expected after some time if there is no mining peer in the network. It should however heal itself when a peer starts to do mining again. Were you able to restart mining after the errors appeared? Or is it exactly the mining node that struggles now? |
|
I am not able to continue mining, mining node get stuck connecting and disconnecting from all accessible peers. I was able to start mining in one node after setup old date on node server. |
|
My network is working again following this steps:
I imagine that should exist other more easy way to do the same thing, unknown from me. |
|
@rrguardo i guess you could change the time network can be abandoned. but this might break it in a long run |
|
Appears to be issue with local date/time settings but difficult to re-produce without more information. Closing as OP was able to find a fix. |
|
It's old issue, but just for reference. As far as I see, if current time is more than 6 hours more than last block mined, just started node will never sync. It is by design (or, say, by code). If node is running and no new blocks mined for a long time, this node will continue running. But if you restart it, it will always wait for more recent block (not older than 6 hours). |
I was experiment with an independent private DASH copy network(fork), and note that after ~12 hour not mining, all the nodes get stuck synchronizing.
Is DASH daemon not prepare to work under that non realistic conditions?
Maybe I miss something, I am new with the related tech.
The text was updated successfully, but these errors were encountered: