38

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

5
  • 3
    Last time I tried it took 2-3 days.
    – q9f
    May 21, 2017 at 11:11
  • Do you know which number I'm supposed to reach ? Right now I'm at "number=3743185"
    – J. Doe
    May 21, 2017 at 11:25
  • 1
    Then you are done. Check against etherscan.io
    – q9f
    May 22, 2017 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, 2017 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. Dec 1, 2018 at 8:10

6 Answers 6

41

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".

5
  • What does that even mean? Should they be the same, or near each other?
    – Kebman
    Aug 17, 2017 at 20:01
  • 7
    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, 2017 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 Nov 21, 2017 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, 2017 at 18:34
  • 7
    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); } ());
    – user25899
    Dec 17, 2017 at 0:09
10

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
10

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.

2
  • 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, 2017 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. Aug 21, 2017 at 0:29
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.

3
  • 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, 2017 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, 2017 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. Dec 16, 2017 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

3
  • 1
    Note, fast is deprecated and also now default. --syncmode is the new switch for sync behavior.
    – q9f
    May 22, 2017 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, 2017 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, 2017 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

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