1

After the synchronization of block chain is complete, what happens if you close the geth console while it continues to run the current block chain data?

In the future, I would like to turn off synchronization and close the command prompt geth console so that I can do maintenance on the system.

Is there some duration of time where you can have your system turned off and still start synchronizing again at the last block chain found on your system?

I guess I am asking because it seems that after I had finished synchronization and it was processing through a block, I closed the geth command prompt window.

I then tried to restart geth console and it seems to find the most recent local full block (which on my system seems to be 4058127)

It then goes through this process:

INFO [07-22|11:58:30] IPC endpoint opened: \\.\pipe\geth.ipc
INFO [07-22|11:58:30] HTTP endpoint opened: http://127.0.0.1:8545
INFO [07-22|11:58:30] Mapped network port                      proto=tcp extport=30303 intport=30303 interface=NAT-PMP(192.168.2.1)
INFO [07-22|12:01:00] Block synchronisation started
INFO [07-22|12:01:03] Imported new chain segment               blocks=2 txs=148 mgas=12.617 elapsed=303.788ms mgasps=41.532 number=4058129 hash=ac2f90…89e00a
WARN [07-22|12:01:08] Synchronisation failed, dropping peer    peer=1cd4c9e09b903579 err="retrieved hash chain is invalid"
WARN [07-22|12:05:13] Synchronisation failed, dropping peer    peer=416475e24fa54674 err="retrieved hash chain is invalid"
WARN [07-22|12:10:49] Synchronisation failed, retrying         err="block download canceled (requested)"

It doesn't seem to be able to sync now and it keeps dropping peers.

Does this 'handshake' process just take a long time or did I kind of mess up by stopping the geth console and then trying to restart it.

If it is just a question of patience vs. restarting from scratch, what general time frame should I expect before the handshake completes and I can catch up again to the end of the block chain.

Cheers, John

0xcaff
  • 2,477
  • 1
  • 14
  • 29
John H
  • 55
  • 2
  • 4

1 Answers1

1

Running geth keeps the local copy of the chain in sync with the global chain when it is running. geth console is a REPL which connects to an instance of geth and allows you to run commands in the context of the blockchain. Closing geth console using Ctrl + C or Ctrl + D will not stop the synchronization process. If you kill the geth command (for example by closing the shell it is running in), synchronization will stop. Otherwise, geth will keep the local copy blockchain of the blockchain up to date, even after being disconnected from the network for a long time. You will just have to wait for the peer discovery process to finish and the new blocks to be pulled in from the network. It takes a while.

0xcaff
  • 2,477
  • 1
  • 14
  • 29
  • Thanks so much Oxcaff. I am trying to figure out what you mean by the shell as I am not a programmer and really lack significant knowledge in this area. So, when I open windows command prompt, and I input 'geth --rpc' to start the process – John H Jul 22 '17 at 16:36
  • Thanks so much @Oxcaff. I am trying to figure out what you mean by the shell as I am not a programmer and really lack any knowledge in this area. So, when I open windows command prompt, and I input 'geth --rpc' to start the synchronization process, am I running the geth command in the windows command prompt 'shell'? Also, what is a REPL? Then, when the command prompt window is closed that is running geth sync, I have stopped sync and when I restart, the peer discovery takes a long while. Is this a "punishment" so to speak for disconnnecting from geth? – John H Jul 22 '17 at 16:45
  • The shell is the windows command prompt in your case. The shell is just a program to run and manage other programs. A REPL is a Read Print Eval Loop, a place where you can type in code and it will execute, returning the result of the expression. since you're not running the geth console command you don't have to worry about it. The long sync times are required. It's not a "punishment", it's more like doing research because the chain needs to be verified. – 0xcaff Jul 22 '17 at 16:50
  • 1
    You can think of peer discovery after disconnect as an unidentified person who wakes up from a coma with full cognitive abilities after several decades. Now, imagine this person needs to regain access to identification documents, bank accounts, etc. This person is going to need other people to vouch that this person is who he/she claims to be. Our coma patient is going to look for people he/she knew before going into a coma (this is exactly what peer discovery is) and then try to contact them. Some of them may be dead (off-line), some may have changed addresses/phone numbers (new IP address) – lungj Jul 22 '17 at 22:03
  • 1
    and some will still be reachable. That's who the coma patient manages to contact to rebuild his/her social network -- and that's what your geth client does after reconnecting to a peer after restarting. – lungj Jul 22 '17 at 22:04
  • @lungj, thanks for the colorful analogy. :) Well, I gave it a good 8 hours to try to resynch, but it just kept dropping peers and was unable to sync. The initial fast sync itself took about 6 hours so I am assuming I must have blundered along the way or maybe thought sync was complete when in fact it was not. I will clear old blockchain data and let it roll overnight again. – John H Jul 23 '17 at 00:08
  • Is your network blocked in any way? @JohnH – 0xcaff Jul 23 '17 at 00:10
  • 1
    To add to @0xcaff, If your system clock is wrong by more than a few seconds, you'll have trouble syncing. – lungj Jul 23 '17 at 00:12
  • @0xcaff, I don't think so. I have a fast fiber connection and there is no monthly upload/download limit and it doesn't seem like I am being blocked by a firewall. I believe my system clock (displayed in the lower right corner of windows 10) is synchronized with world time for eastern standard time (EST) and looks to be in-line with other time-keeping devices (iphone, ipad, etc... ) that are also synced via wifi to the world clock. – John H Jul 23 '17 at 01:11
  • I had the same issue, then I came back the next day and it was up to date. Give it a bit more time. I don't know the details of the peer discovery protocol. – 0xcaff Jul 23 '17 at 01:14
  • I started over again and used geth --rpc this time instead of geth fast sync so we'll see if that makes any difference. I started that roughly 1 hour ago and the number is up to 2270038 so it seems like it has made good progress re-starting. I'll let it run overnight to make sure its reached the most current block chain. – John H Jul 23 '17 at 01:15
  • @0xcaff. Will do. I like messing around with stuff so will likely try the experiment again in the morning. If the whole synchronization process at this point in the ethereum chain takes less time than a resynch after downloading all block chains, then there must be something I am not doing right. – John H Jul 23 '17 at 01:18