Unable to sync ethereum blockchain

[aliabbas2810]

System information

Geth version: 1.6.5-stable-cf87713d
OS & Version: Ubuntu 16.04

I am trying to sync the blockchain. I have tried all the available solutions but still unable to sync.
Please have a look.

INFO [06-02|08:05:35] Imported new block headers count=0 elapsed=209.738ms number=43813 hash=d7d8db…68a468 ignored=2048
INFO [06-02|08:05:36] Imported new block headers count=0 elapsed=210.337ms number=45861 hash=bfde9a…0b6344 ignored=2048
INFO [06-02|08:05:36] Imported new block headers count=0 elapsed=72.898ms number=46565 hash=c19ebf…5b6645 ignored=704
ERROR[06-02|08:05:37] Failed to unregister sync peer peer=ae0d06cdbe191fd1 err="peer is not registered"
ERROR[06-02|08:05:37] Peer removal failed peer=ae0d06cdbe191fd1 err="peer is not registered"

And then the whole process in rolled back and start again and this continues in a loop

d=3.598ms processed=43990 pending=61509
INFO [06-02|08:14:12] Imported new state entries count=20 elapsed=8.518ms processed=44010 pending=61494
INFO [06-02|08:14:12] Imported new block headers count=192 elapsed=171.646ms number=24960 hash=685eb7…05d468 ignored=0
WARN [06-02|08:14:14] Rolled back headers count=2048 header=24960->22912 fast=16663->16663 block=0->0
INFO [06-02|08:14:14] Imported new block receipts count=1495 elapsed=1.152s number=18158 hash=d3a174…33e7da ignored=0
INFO [06-02|08:14:14] Imported new block receipts count=341 elapsed=176.320ms number=18499 hash=3ba281…e731c7 ignored=0
WARN [06-02|08:14:14] Synchronisation failed, retrying err="state data download canceled (requested)"
WARN [06-02|08:14:15] Synchronisation failed, dropping peer peer=1761901b12c7a509 err="action from bad peer ignored"
INFO [06-02|08:14:23] Imported new block headers count=0 elapsed=28.055ms number=18883 hash=70afc2…0ee143 ignored=384
WARN [06-02|08:14:26] Synchronisation failed, retrying err="block body download canceled (requested)"
WARN [06-02|08:14:30] Synchronisation failed, dropping peer peer=62c9cdfd34a1acb8 err="action from bad peer ignored"
INFO [06-02|08:14:37] Imported new state entries count=1 elapsed=702.766µs processed=44011 pending=17
INFO [06-02|08:14:42] Imported new state entries

[jfcg]

same here :/

[Baconaetor]

I'm having what seems to be at least a similar issue. I'm also on 1.6.5 stable. When I run geth it will sync as expected until it's within 100 blocks or so; then start to just lag behind. It will then catch back up to within 100, and then just lag behind again, and so it repeats as long as I run it. I've run it for 24 hours straight without progress and I've tried deleting the chaindata and restarting two or three times.

[clueware]

The behaviour you describe looks similar to what I had running geth in a VM - I have a simple setup at home, so I/Os are rather limited. The syncing process was just really slow, and then the closer it was getting to the current block, the longer each block processing was, even with high cache allocation.
You can try the --cache option (in Mb, so beware not overloading the system memory).

The amount of i/o geth generate is staggering: with a raid 0 it's constantly trashing the disks, whether it's syncing or already synced. There was a few issues logged on the subject but it seems that not much have changed.

[Baconaetor]

I've been running it with a 2 Gb cache. . . I upped it to 4 gigs and ran it for ~7 hours today to no avail. I'm only on an regular hard disk drive, but it's still a decent one. Although windows currently reads that it's maxing out at around 8mb/s.

[Baconaetor]

Also, at times when I check with eth.syncing on the console, it doesn't even show the most current block as the highest block. i.e. when I just checked it said the highest block was ~70 behind what the actual highest block is, and the current block, or block I've most recently synced, was another ~90 behind that.

[pebwindkraft]

similiar here. GETH 1.6.5 on Linux.
Command: geth --fast --chache=512 console
(Some history here: https://ethereum.stackexchange.com/questions/18709/geth-chaindata-copied-syncd-keystore-account-updated-balance-0-heavy-act?noredirect=1#comment20162_18709).

I renamed my old chaindata directory, and created a new directory for chaindata, and started from scratch (at 0). It took 3 days to fully synchronize up to the latest blocks, with du -h -s chaindata showing ~24Gigs, and about 12.000 files. Heavy disk I/O until blocks was synced. Then disk I/O calmed down. Currently eth.syncing is showing:

  currentBlock: 3962216,
  highestBlock: 3962334

I think I never found a status, were both numbers were the same (which is ok, given the nature of the ever increasing block count, right?). Maybe I have never tried often enough...

Once the system had sync'd up to the lates block, I can see my CPU load average going down from roughly 3.something below 1, disk I/O is going down dramatically, and network traffic is going down dramatically. All in the range of my expectation.
I had several "error" messages (failed to unregister, peer removal failed, geth.ipc->@: write: broken pipe) but the process obviously continues.
Funny thing is, that my coinbase is still 0 (eth.coinbase), whereas eth.account shows the correct address (and web explorers the correct amount). eth.defaultBlock shows "latest" (it did that from the very beginning), peerCount is always between 3 and 8. eth.blockNumber remains 0.

Observation: During the first two days the knownStates showed ~ 4.5 mio, and similiar for pulledStates. Over the weekend I shut down the system, and restarted later during the week. These state figures were completly down, starting to count upwards from 0. It is unclear to me, what they are, and I couldn't find in the docs. My system now shows:

{
  currentBlock: 3962216,
  highestBlock: 3962334,
  knownStates: 1316924,
  pulledStates: 1217542,
  startingBlock: 3954831
}

The geth console shows many, many lines like this:
> INFO [07-02|14:58:32] Imported new state entries count=107 elapsed=2.109s processed=1217649 pending=100558
where the numbers for processed increases, and the numbers for pending is varying between 50.000 and 150.000. I am now waiting for the figures for knownStates and pullesStates go "up" (I hear it can go to +8mio), and see what happens then. CPU, network and disk I/O remain low, and spikes from time to time, when a new block comes in.

If someone can point me to the right documentation, I'd be thankful.
Hey: code is no doc :-)

[gvsmirnov]

Until about 500 blocks are left, syncing goes smoothly, but then gets stuck indefinitely. Likewise, large number of pending entries that fails to reach zero. Sometimes reaches one, but then:

INFO [07-10|05:34:44] Imported new state entries               count=0   flushed=0   elapsed=496.845µs processed=8696 pending=1    retry=1   duplicate=0 unexpected=1312
WARN [07-10|05:35:19] Stalling state sync, dropping peer       peer=9067508301728d7a

./geth version
Geth
Version: 1.6.6-stable
Git Commit: 10a45cb59bd9bc9f717817afc029a57b222e558d
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.8.3
Operating System: darwin

And then sometimes this happens:

INFO [07-10|05:52:28] Committed new head block                 number=3999889 hash=c075c4…5a7826
ERROR[07-10|05:52:29] Impossible reorg, please file an issue   oldnum=3999898 oldhash=70485d…63e66a newnum=3999898 newhash=70485d…63e66a

[kevin-vilbig]

I suspect that the phenomenon that we have here is greedy miners up at the head who aren't sharing their findings openly.

I found a solid peer to add with the JavaScript console in the Management API documentation.

I got to about 150 blocks from the head of the chain and killed the geth daemon and restarted it without --fast and used geth attach from another window. Y'all can figure out the rest.

[davidbongcc]

Same here! I have been spending two days to investigate this particular issue. Just quick one, here could it be due to the VM Ubuntu instance time setting issue?

Thank you.

[JohnAllen]

Geth gave me a pretty clear time not synced warning on a machine that wasn't synced, so if it doesn't warn (latest v1.7.2 btw) I would guess time is not an issue.

[davidbongcc]

Hi John, Good Day! Thank you for your reply. Any idea I am getting the error message " Syncronization failed ,dropping peer , err="retrived has chain is invalid" Thank you. Best, David

…

On Sat, Oct 21, 2017 at 12:20 AM, John Allen ***@***.***> wrote: Geth gave me a pretty clear time not synced warning on a machine that wasn't synced, so if it doesn't warn (latest v1.7.2 btw) I would guess time is not an issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14571 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUZGnWfDL_mldnh1SKoe1dhkVvzuwblZks5suLpEgaJpZM4NtnMw> .

[wtfiwtz]

The error Synchronization failed, dropping peer with err="retrived has chain is invalid" is probably not that relevant, unless you are getting a lot of them...

Have a look at this post: #14647 (comment)

or this thread: #15001

[JohnAllen]

@davidbongcc I got tons of those messages near the end of syncing. Once I got close (within 200 blocks), eth.syncing stopped incrementing and lots of new logs were logged, like the one you mentioned.

I stopped and restarted at this point (you need to wait until you're close to the end to stop and restart or your progress will be lost) and finished syncing within the next few minutes. This was on a brand-new high-end machine so older machines will likely take considerably longer FYI.

[davidbongcc]

Thank you for all the helpful comments and feeedbacks. At last, I got the ether value updated. You all were right, it was due to the slow performance on the Ubuntu instance running on the VM environment. I just checked with eth.syncing command and the status is False. My guess was the local node it is up to date. Thank you.

[WhiteHatCryptoMiner]

Hi, we are using hardware ETH NODEs to sync up our miners and wallets. If you would be interested in getting more info, contact me via PM.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.