Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Parity gets stuck syncing #3635

Closed
etherai opened this issue Nov 27, 2016 · 7 comments
Closed

Parity gets stuck syncing #3635

etherai opened this issue Nov 27, 2016 · 7 comments
Assignees
Labels
F0-consensus 💣 Issue can lead to a consensus failure. M4-core ⛓ Core client code / Rust.
Milestone

Comments

@etherai
Copy link

etherai commented Nov 27, 2016

Version: Parity/v1.4.5-beta-a028d04-20161126/x86_64-linux-gnu/rustc1.13.0
OS: Ubuntu 16.04
HD: SSD
System: VPS Digital Ocean

Parity 1.4.4 seemed to be perpetually syncing so I upgraded to 1.4.5 deleted chain data and did a warp sync with the new --testnet option. Geth is currently at block 52828.

Parity output:

 4 MiB sync
2016-11-27 19:47:01 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:11 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:16 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:21 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:26 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:31 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:36 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:41 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:46 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:51 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync
2016-11-27 19:47:56 UTC Syncing   #52799 c705…ccf6      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #52766    1/ 7/25 peers      3 MiB db    5 MiB chain  0 bytes queue   
 4 MiB sync

Upon restarting Parity it continues "Importing" in sync with Geth for a short period before returning to a perpetual "Syncing" state.

@mtbitcoin
Copy link

I can confirm the issue above, it eventually stops synching

@etherai etherai changed the title Parity gets stuck syncing on Ropsten Parity gets stuck syncing Nov 27, 2016
@gavofyork gavofyork added the F0-consensus 💣 Issue can lead to a consensus failure. label Nov 27, 2016
@gavofyork gavofyork added this to the 1.5 Tenuity milestone Nov 27, 2016
@gavofyork gavofyork added the M4-core ⛓ Core client code / Rust. label Nov 27, 2016
@gavofyork
Copy link
Contributor

i can confirm something strange is up.

image

@mtbitcoin
Copy link

I am only seeing this on 1.4.5 , 1.4.4 seems ok

@SinErgy84
Copy link

SinErgy84 commented Nov 28, 2016

1.4.4 seems to have also issues.
running 2 separated nodes in daemon mode with Parity/v1.4.4-beta-a68d52c-20161118/x86_64-linux-gnu/rustc1.13.0 on ropsten.
node 1 stucked at 54400
node 2 stucked at 51987

edit:

  • node 2 get's synced after killing daemon process and restarting in normal mode. but after stopping normal mode and rerunning daemon mode again the sync process stops and hangs on last synced block (55629) from normal mode.
  • on node 1 I killed the daemon process and started immediately a new daemon process. on this node the sync started flawless and new blocks are processed without issues.

strange thing is, that both nodes runs the same version, but had different block state / number while stucked.

@gavofyork
Copy link
Contributor

gavofyork commented Nov 28, 2016

if you could run with -l sync=trace and redirect stderr to a file (2> /tmp/log), then post the log when it happens again that'd be very useful.

@SinErgy84
Copy link

SinErgy84 commented Nov 28, 2016

@gavofyork hmmm, after waiting 20 mins within a loop of calling getCurrentBlockNumber() on node 2 parity seems to be resynced again... the block number raised from 55629 to 55750 immediately between two calls.

sorry, have no clue what magic is happening here.
if the client get stucked again I will rerun with logging.

@SinErgy84
Copy link

@gavofyork issue appears again.
auswahl_001

last timestamp before issue occured:

2016-11-28 11:58:05  Verifier #0 INFO import  Imported #56170 85bf…dc5a (0 txs, 0.00 Mgas, 1.01 ms, 0.53 KiB)
2016-11-28 11:58:07  IO Worker #2 INFO import  Syncing   #56170 85bf…dc5a      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #56143    2/15/25 peers    684 KiB db  616 KiB chain  0 bytes queue   41 KiB sync
2016-11-28 11:58:12  IO Worker #2 INFO import  Syncing   #56170 85bf…dc5a      0 blk/s    0 tx/s   0 Mgas/s       0+    0 Qed     #56138    2/15/25 peers    684 KiB db  616 KiB chain  0 bytes queue   41 KiB sync

Log file attached
parity.sync.issue.txt

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F0-consensus 💣 Issue can lead to a consensus failure. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

4 participants