Sync stalling

[mzdici]

My Parity (last version) synchro with the Ethereum blockchain stalled at ~block 700000 (it remained there for ten hours despite constant bandwidth consumption, per nethogs)

Intrigued, I checked the hidden Parity folder in /home and found out that despite max bdwth consumption for hours, very few data had actually been downloaded (~600MB).

[arkpar]

Could you please run with -l sync=trace and share the produced log?

[mzdici]

Ok, will do that tomorrow, not free today

[chervol]

Looks like I have the same issue with one node, here logs https://gist.github.com/chervol/acff780ba384869c94ea3402d1912996

[AlbieC]

I have the same issue ...

[keorn]

@chervol Make sure your system clock is synchronised. Also the first run you posted is pretty short, it sometimes take time to find peers to sync from.

[AlbieC]

Why does Parity use so much bandwidth during this extended time it's stuck if there are no peers to sync from then ?

[keorn]

If your clock is synchronised, then it will just be trying to do peer discovery via UDP.

[AlbieC]

Log.txt

[keorn]

Happens on latest master. parity -l sync=trace log.

[keorn]

It starts being stuck after a bunch of:

2016-10-06 16:11:58 UTC Bad header 336389 (c101…3f08) from 11: Parity/v1.3.2-beta/x86_64-linux-gnu/rustc1.11.0, state = ChainHead
2016-10-06 16:11:59 UTC Bad header 336389 (c101…3f08) from 61: Parity/v1.3.3-beta/x86_64-linux-gnu/rustc1.12.0, state = ChainHead
2016-10-06 16:11:59 UTC Bad header 336389 (c101…3f08) from 56: Parity/v1.4.0-unstable-862feb7-20160922/x86_64-linux-gnu/rustc1.11.0, state = ChainHead
2016-10-06 16:12:01 UTC Bad header 336389 (c101…3f08) from 29: Geth/v1.4.12-stable-421df866/linux/go1.5.1, state = ChainHead
2016-10-06 16:12:01 UTC Bad header 336389 (c101…3f08) from 11: Parity/v1.4.0-unstable-862feb7-20160922/x86_64-linux-gnu/rustc1.11.0, state = ChainHead

After restart it manages to keep going, sometimes for a long while, before getting stuck again.

[arkpar]

@chervol all of your peers are either too far behind or on ethereum classic chain. Could it be that you have synced the ethereum classic chain on the same machine before?

[keorn]

Please try the 1.3.4 release or the latest master, it appears to have fixed my issues.

[AlbieC]

ok, I tried 1.3.4 from the 1 line installer, but unfortunately still the same issue. Still stuck on the same last block as previous. Does one have to resync from scratch with 1.3.4 ?

[splix]

I have same problem. Tried yesterday to do a fresh sync with v1.3.0, but it stuck on block 731956 (12+ hours of waiting). Today I've tried build 1.3.5, started from empty datadir, and it stuck on 731737 (4+ hours, no progress so far)

[splix]

If you really need parity right now there is a workaround:

1. run Geth sync in parallel
2. run Parity with --reserved-peers <file that contains geth enode addr> --reserved-only

[apesfromspace]

Parity 1.3.5, OSX
I'm stuck on block #2398294

Here is some log

log.txt

[keorn]

Please start by going through the steps in the FAQ. Only then and if you are fine with trying unstable you can check out the sync-fix branch and see if it helps.<\s>

[chervol]

@keorn @arkpar I successfully synchronised from scratch after cleaning chain data. Just hoped the log would give you hints. Have never mined the ethereum classic, even with geth.

[gabx]

@chervol may you elaborate on what you did as for "cleaning chain data" ? And which build did you use: this one (sync fix) or the regular master one ?

[keorn]

The potential fix has been merged into master, please try it and see if it helps. Again, make sure to first follow the steps in the FAQ.

[gavofyork]

Please go to time.is and check it says this:

If not, get your clock synced!

[AlbieC]

My time is "exact", and also all the other FAQ ...
I don't see why it used to work, and suddenly after updating to a new Master version last week, it get's stuck at around 750 k blocks suddenly when doing a fresh sync, since upgrading my old database also got corrupted ...

Anyways, just did the latest master install from the 1-liner. Still the same issue for me.
I deleted/moved the database folder again, and now doing fresh sync , so well see if the issue appears at the same place again.

1 possible thing could be the fact that upon starting Parity reference an old public enode of mine on another computer that do not exist anymore, but that was a Classic node. This node text is in a file, but even removing the file , it still gets shown on startup ?

[AlbieC]

I can now confirm that my new and latest Parity installation, with a fresh sync, once again stalled at around 750 k block mark ...

[pikos-apikos]

I have the same problem on windows 10 both on my laptop and desktop using parity 1.3.3 and above.
It was stuck so I stared a new sync on my desktop & laptop after installing 1.3.5 on both.
I let the desktop finish the sync and turned it off. Today i start parity (1.3.5) is again stuck at #2,404,092. After installing 1.3.6 still the same.

I let the laptop sync for some time and then stopped it and turned it off, today i installed 1.3.6 and it is also stuck at #2,398,524

some logs form the desktop:
parity-logs.txt

[bamos01]

Time is in sync but having problems syncing on Mac OSX - 4 gb RAM - see trace output attached - any ideas? thanks
Terminal Saved Output.pdf

[arkpar]

A few of the issues mentioned here have been fixed in 1.3.9. Please report if you still have problems with a new version.

[Free-Peace]

I'm having a sync-related issue, though it seems to be different from some of these listed above. I am having trouble connecting to peers on the ethereum classic chain using "--chain=classic --geth" at the end of the parity "target" field.

Parity keeps reporting back that I am connected to 0/0/25 peers and then lists what looks like one packet over and over.

What is going on and how can I fix this?
Free-Peace Log.txt

#2744

[AlbieC]

I'm still stuck with my syncing on 2 Parity nodes. One new Windows version install stuck at #731770 and also a Linux machine with latest 1 liner installed today at # 731773 . I cannot sell or transfer my mined blocks without a synced node ...

[Free-Peace]

I haven't had a chance to update my threads yet but I've fixed my issue/non-issue. It was a very simple networking error as hinted at by arkpar within #2744. I needed to properly set up port forwarding.

AlbieC - I've had a stalled sync happen once or twice so far and was able to get the system to work again by either closing geth and/or parity and rebooting the applications. Dumb question, but have you given that a go yet?

Have you attempted to completely backup and then delete/uninstall all references to Parity + geth and then retry the install and sync? At it's most extreme you could format a drive really quickly and boot up a new Linux machine and give two fresh installs (parity & geth) a go.

I have the feeling this issue is due to old files/references confusing your new sync. I'm also extremely new to this and my advice should be taken with a grain of salt.

[AlbieC]

Why did you need to properly setup port forwarding if your node was working perfectly previously ?
In my case everything worked fine on my Linux system, then 1 day I upgraded to latest parity version, it tried to update the database, got corrupted of course (like normal) and then when I deleted the database directory and tried a new sync from scratch, it started with the stalling issues at around the same block number every time ...

[brenzi]

I'm stuck at #2421559
My time is in sync (-0.077s)
My network doesn't block UDP
Deleting the nodes.json file didn't change a thing

parity-sync-trace.txt

[arkpar]

Block after #2421559 are slow to import, especially if you are on an HDD

[brenzi]

@arkpar: what do you mean with "slow to import"? My peer stalled for more than 8h at the very same block

[Free-Peace]

@AlbieC - good question. I don't have a definitive answer. My best guess is that my original install was using ETC Mist with the built in 1.4 geth and that I had everything set up properly but after the attacks on the network, switching over to parity and geth necessitated resetting port forwarding. Maybe Classic Mist Wallet's version of geth uses a different set of ports than the most recent, standalone version (which I haven't before used).

[AlbieC]

Did another fresh Windows install of Parity on completely virgin high spec machine with SSD, etc.
Parity started syncing very fast but after about 2 hours sync stalled at around 2.3 million blocks ...

[rphmeier]

@AlbieC Seems like you've run into the attack blocks. Try running with the --cache-size-state 256 (meaning 256MB -- provide however much you're comfortable with). This will speed things up a bit, unfortunately the last batch of attacks (~2420k -> 2463k) will sync extremely slowly.

[wiryonolau]

Hi, My servier time is sync, but parity been stuck for over a week in
2016-11-16 11:30:44 Syncing #2475046 542c…a865 0 blk/s 0 tx/s 0 Mgas/s 0+ 0 Qed #2475046 2/25/25 peers 459 MiB db 74 MiB chain 0 bytes queue 257 MiB sync

what does this mean

I use clean data

[arkpar]

There have been a few issues reported here, most of which are fixed in latest releases. In case you still experience stalling please open a new issue.