-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Sync gets stuck in parity private network (connectivity problems) #10778
Comments
Hey @miguelmartinezinf thanks for the issue and logs! Can you please clarify more details? Are your nodes not able to connect totally or is it just a stuck at the nodes' startup and after some time connectivity backs to normal? I'm asking this, because the reason of the observed behavior in network logs is hanging on the handshake session, that prevents other sessions to be created. And your log finishes exactly on the place, where this hanging session killed with timeout (5 sec): parity_authority0 | 2019-06-25 10:28:29 UTC IO Worker #3 TRACE network Connection timeout: 0 So the most important question for me, what was happening after this exact moment, was Parity able to restore connectivity or not. If not, can you please collect logs with network trace enabled for about 3 minutes after the startup? That would be very helpful for the investigation. |
Hey @grbIzl , thanks for your comment. Nodes are not able to connect anymore after an "InternalBacktrace" error appears... If I re-launch each node individually or both nodes at the same time, they are working but not able to inter-connect, they get stuck in the handshake (as you can see in logs). I think I know what exactly the problem is. This connectivity problem started to happen after an "InternalBacktrace" error appeared with the name of "InvalidChainId". This error appeared in logs just after send some transactions indicating a wrong "chainId" as transaction options (my networkId is 0x2323 and chainId was 4 idk why). The transactions got mined and block height increased. My theory is that after this thing, parity node is not able to keep stable, because starts to get connectivity and sync problems. Should parity node rejects the transaction if there is no chain working with the supplied id? I saw is a good idea to add chainId on tx options when submitting txs for replay protection or choosing between ETH or ETC chains, but should be use also with private chains? Do you think this config option is needed? why? Thanks in advance |
@miguelmartinezinf Can you please just make a little bit longer log for both nodes with the same network trace level? 2-3 minutes will be enough. Simply launch nodes and wait a little bit, don't restart or do anything. If you're saying, that the nodes cannot connect to each other, it is the real problem already, and anything else (like issues with chainid etc) can be just a side effect. |
I think that chainId issue is not a side effect, but the main problem here... This time I work with 3 nodes: node0 is the signer one, node1 and node2 are just replicas.
|
Hey @miguelmartinezinf while the chainId issue is certainly a valid issue (and a known one at that, discussion in #10411), it's a different issue from what @grbIzl has been looking into recently and trying to fix. While your logs are certainly helpful, what would be most helpful to resolve this issue is |
Thanks, as @grbIzl is looking into the 2 nodes network I explained at the initial issue description, I decided to take that sceneario (2 nodes network). Here you have the network trace level logs for a 2 node network: node0.log node1.log Workflow followed:
|
@miguelmartinezinf thanks for the logs! After looking into them I can confirm, that the issue is in the incorrect chainId on node0. Node1 disconnects on every BlockHeader packet, code is here: |
Great, thanks a lot @grbIzl @joshua-mir |
I am running a parity private network using docker-compose locally. The network is compound by two nodes (node0 and node1) and using aura consensus with 1 signer (from node0). When node1 looses connectivity with node0 or is restarted, is not able to reconnect with node0. WHen node1 is restarted is not able to resync the new produced blocks (I guess because the connectivity stuff).
Here is the
reserved_peers
: (both enodes match)Here is the
authority.toml
:Log with network trace level:
Logs with sync trace level:
Any idea? Thanks in advance
The text was updated successfully, but these errors were encountered: