31

I've been running Geth (latest version) for around 12 hours and it's still not finished.

The command prompt shows this :

INFO [05-21|12:05:00] Imported new chain segment               blocks=1  txs=9   mgas=0.748 elapsed=40.047ms   mgasps=18.687 number=3742904 hash=f8fd6e…fce9f8

INFO [05-21|12:05:29] Imported new chain segment               blocks=1  txs=2   mgas=0.044 elapsed=16.018ms   mgasps=2.741  number=3742905 hash=04b0be…3d64cd

INFO [05-21|12:05:38] Imported new chain segment               blocks=1  txs=66  mgas=2.851 elapsed=95.126ms   mgasps=29.971 number=3742906 hash=157014…c50cc5

By the way, my Internet speed isn't that bad, check it out

Internet Speed

Is this normal ? Should I try using another client such as Parity ?

PS : I've run Geth using this command line : geth --fast --cache=1024

  • 2
    Last time I tried it took 2-3 days. – Waqar Lim May 21 '17 at 11:11
  • Do you know which number I'm supposed to reach ? Right now I'm at "number=3743185" – J. Doe May 21 '17 at 11:25
  • 1
    Then you are done. Check against etherscan.io – Waqar Lim May 22 '17 at 11:54
  • Another day, I executed the synchronization with the command geth attach that dont work out today. So, I tried geth --fast --cache=1024 and this is working. – Arefe Dec 21 '17 at 0:22
  • For your information, at this moment (2018-11-29), I tried --syncmode=full --gcmode=archive. After about 18 hours I reached block 2702327. The highest block is 6799556. – lllllllllllll Dec 1 '18 at 8:10
37

Do following steps to check the sync state:

1.) open a new geth instance and type in geth attach 2.) now type in eth.syncing

This shows you the "currentBlock" and the "highestBlock".

  • What does that even mean? Should they be the same, or near each other? – Kebman Aug 17 '17 at 20:01
  • 4
    They should be close to each other. In other words, run 100 * eth.syncing.currentBlock / eth.syncing.highestBlock to get the percent completed. When it is close to 100, you are synced. – johndodo Nov 16 '17 at 14:32
  • If eth.syncing is false, it's already sync and you can check eth.blockNumber against a block explorer if you want to double-check. Source – William Ardila Nov 21 '17 at 14:57
  • So it should be CLOSE or EXACT the same number of block? It's crucial Because I'm 99.99335% synced and I'm wating for hour still on the same block. I wonder am I synced or not yet. – magos Dec 2 '17 at 18:34
  • 6
    Fun fact: geth attach is actually a complete JavaScript environment! If you're looking to repeatedly print out the percentage on a timed loop, you can simply run (function percentage() { console.log(100* eth.syncing.currentBlock / eth.syncing.highestBlock); setTimeout(percentage, 10000); } ()); – Chef Cyanide Dec 17 '17 at 0:09
9

I think you should edit the question to ask, "How do I know when geth is done syncing?"

The question you asked was vague, but I believe this is the answer you were after:

Geth will continue running forever. Once it is "done", it will just sit there and wait for the next block. The "numbers" you refer to are block numbers, and they shall increment for all of eternity. Once your current block reaches the highest block, you are all synced up. As mentioned by 5chdn, the highest block can be determined by checking someplace such as etherscan.io.

I let Geth run for hours thinking that I was waiting for it to "finish" when in fact it had been done for a long time. As of this writing, the highest block is 3854270

Thanks to 5chdn's comment which was really the key to the answer.

  • So do we just stop it once it's in sync? Wouldn't that put it out of sync because it wouldn't have the latest blocks? – dhruvm Aug 15 '17 at 16:46
  • It will be in sync until the next block is released. You can stop it, but yes that means that you will fall out of sync eventually. If you want to always stay up-to-date, then you can leave it running. The point being, the app is never "done", per se. But it does come to a point where it is all "caught up", for the time-being. – Evan de la Cruz Aug 21 '17 at 0:29
8

Assuming you are using a Linux flavoured OS, you can check the sync status as well (run this as the user under which geth is running):

$ geth --exec eth.syncing.currentBlock attach
3991639

If it's not syncing, it will only display 'false'.

Or, if you want to get a little more fancy and see how many blocks / second are syncing, here is an idea:

A=$(geth --exec eth.syncing.currentBlock attach)
while true; do
  echo "Currently at block ${A}"
  sleep 1
  B=$(geth --exec eth.syncing.currentBlock attach);
  echo "Reached block ${B}"
  echo "$B-$A"|bc; A=$B
done
5

If you start geth with "--verbosity 5", it will print out a bunch of debug info. It won't speed things up, but it will let you know that geth is not hung.

I think what people do is run geth. It starts churning on something. They wait and wait. And then they kill geth because it appears hung. If you do that, geth will just have to start that long process over again taking it even that much longer to sync.

Verbosity 5 lets you have the patience to let it run until it finishes because you can see that it's not hung.

  • Well the numbers keep increasing, right now I'm at "number=3744194". So I don't think it's stuck. Thanks tho, I'll remember that option next time I launch geth :) – J. Doe May 21 '17 at 16:00
  • verbosity level 5 will significantly slow down your import process. do not change it, just check the import status with javascript console – Nulik Dec 16 '17 at 19:25
  • You can turn verbosity on and off. I’m suggesting you turn it on during the DDos attack so you know that the node is not hung. If you constantly kill the node because you think it’s hung, it’s going to restart on the same transaction that it was processing previously and take that much longer. – Thomas Jay Rush Dec 16 '17 at 20:47
3
INFO [05-22|08:14:16] Imported new chain segment               blocks=1   txs=2    mgas=0.067  elapsed=11.000ms  mgasps=6.104   number=3745188 hash=9b8973…920c7e

Has been running for about 32 hours. Ran Geth with geth --rpc --fast -cache=1024

Ethereum folder size: 17.9Gb

  • 1
    Note, fast is deprecated and also now default. --syncmode is the new switch for sync behavior. – Waqar Lim May 22 '17 at 11:55
  • Thanks! I'll remember that. And I also noticed that I had -cache instead of --cache. Restarted the sync last night and up to number=3753194.. Alot better. – HamDogg May 23 '17 at 7:41
  • I could be wrong here, but I believe my blockchain is up to date and I didn't realize until I compared where my geth client was at compared to the network status for Eth. So I'm up to here: INFO [05-29|23:07:27] Imported new chain segment blocks=1 txs=8 mgas=0.168 elapsed=19.999ms mgasps=8.400 number=3786778 And checking ethstats.net I can see I have the latest and am even one block ahead. So I'm basically ready to start mining now. I believe I was actually up to date a few days ago but didn't know being new. – HamDogg May 29 '17 at 11:08
3

I personally prefer using Parity because of the snapshot feature they have. Using a GCE cloud instance I was able to sync the full chain in 30 minutes.

Here is an explanation of how it works : https://github.com/paritytech/parity/wiki/Warp-Sync-Snapshot-Format

protected by Community Jul 8 '17 at 23:20

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.