4

Running geth on clean ubuntu 14.04 x64

After running geth --fast syncing stoppes on some point, like that:

I0321 11:31:39.971284 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 188 txs in 3.539956421s. #178700 [f77611b1 / 81122e65]
I0321 11:31:46.274148 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 570 txs in 6.300590994s. #178956 [6dd11d8f / dba1d24d]
I0321 11:31:51.141699 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 252 txs in 4.864679475s. #179212 [bd22d2ba / 95e5cd8a]
I0321 11:32:07.463688 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 941 txs in 16.316555449s. #179468 [d8d6ad74 / 9d3820b7]
I0321 11:32:12.135834 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 256 txs in 4.66919216s. #179724 [c43d0171 / 3ce5ce4d]
I0321 11:32:17.759139 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 199 txs in 5.617463517s. #179980 [e4844648 / 602a284b]
I0321 11:32:24.569821 core/blockchain.go:959] imported 256 block(s) (0 queued 0 ignored) including 195 txs in 6.807623198s. #180236 [7b5c8d4b / 8e9051e3]
I0321 11:32:25.599760 core/blockchain.go:959] imported 60 block(s) (0 queued 0 ignored) including 45 txs in 1.029029976s. #180296 [ec5742fb / 7b71e76e] 

It continue after Ctrl+C and run again. But what is the problem?

  • without --fast flag everything is fine – yanik Mar 21 '16 at 17:00
6

Looking at your logs, fast sync is disabled. Fast is only ever allowed if your database is empty and/or haven't imported any blocks yet, only did previous fast sync attempts.

Given this, it actually doesn't matter if you specify fast or not, your node does not do fast sync, since you started a slow sync at some point and inherently disabled fast sync for life. To re-enable fast sync you need to delete your chaindata folder and start sync from scratch.

I can't say for sure why sync might stall, but if it happens often/regularly/reproducably, please run geth with --vmodule=downloader=6 (which will output a ton of logs as it syncs) and post the logs on our issue tracker with all the logs in a GitHub gist.

  • You are absolutely right. I start slow sync, but switched to --fast after noticing how much time it wood take. I think this is common user case, so you should put some warning. – yanik Mar 30 '16 at 8:56
  • Geth 1.5 will probably switch over to a different model where we have archive nodes and full nodes. Archives would slow sync and retain state by default. Full ones would fast sync and prune state by default. – Péter Szilágyi Mar 30 '16 at 8:59
0

This might be a coincidence, but running geth like this:

geth --rpc

fixed the problem for me. Found the solution using this guide: https://www.cryptocompare.com/mining/guides/how-to-mine-ethereum/

  • Just be careful about the use of --rpc that no one else has access to your computer - see ethereum.stackexchange.com/questions/3887/… . – The Officious BokkyPooBah May 23 '16 at 7:08
  • --rpc has nothing to do with syncing.it's different module, different executable code. Your problem most like was a connection loss, or some other networking problem/. You restarted and it worked because of the restart. – Nulik Aug 23 '18 at 15:37
0

Just a quick addition. I started the sync on slow, then used the fast command and didn't realize it had no effect.

I haven't managed to test the use of the blockchain yet, but I moved most of the files; starting with the earliest (say 70%) from the start of the appdata folder onto another hard drive.

This enabled me to start fast sync from where I left off (I wish I had done this from the start, it's taken 18 hours so far and would probably be finished by now!). Note though that my sync is also suffering from stalling.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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