1

I don't usually keep my Geth instance running, but I would like to keep my Ethereum blockchain synced so that starting Geth is not slow. I reason that I can create a cronjob for this.

So my question is: how can I tell geth to start up, sync, and then immediately exit?

  • New blocks will be added every 15 seconds on average. So, do you want to run this cronjob every 15 seconds? – galahad Nov 13 '16 at 20:46
  • No. I don't expect it to be perfectly synced; just synced enough that it will not have to download many days of blocks on startup. – Matthew Piziak Nov 13 '16 at 20:47
  • I was thinking once a week, to be honest. – Matthew Piziak Nov 13 '16 at 20:48
1

Yet another answer you did not look for: parity --mode passive

I know, parity is not geth, but the --mode passive does exactly what you asked for.

--mode MODE            Set the operating mode. MODE can be one of:
                       last - Uses the last-used mode, active if none.
                       active - Parity continuously syncs the chain.
                       passive - Parity syncs initially, then sleeps and
                       wakes regularly to resync.
                       dark - Parity syncs only when the RPC is active.
                       offline - Parity doesn't sync. (default: last).

I'm using the passive mode on all my devices, because it goes in sleep mode after syncing for around one hour and then checks again for new blocks. This saves a lot of resources most of the time on my machines.

See also:

--mode-timeout SECS    Specify the number of seconds before inactivity
                       timeout occurs when mode is dark or passive
                       (default: 300).
--mode-alarm SECS      Specify the number of seconds before auto sleep
                       reawake timeout occurs when mode is passive
                       (default: 3600).
0

I don't know why you require Geth specifically, but it's possible that Parity may be the solution you're looking for.

Specifically, Parity allows for syncing such that the content of blocks isn't checked, and your client simply downloads the most up to date version of the state. This can be executed using parity --warp, and will remove the lengthy sync-time you are experiencing with GETH.

  • Even with --warp, the whole set of blockchain data will still be downloaded eventually, it's just a majority of the data is synced in the background. If the OP wants a complete set of chaindata, then --warp doesn't really speed things up. – Richard Horrocks Nov 14 '16 at 18:58
  • It seems to me like OP's problem is that every time he spins up his node, it takes a long time. Instead of trying to keep a more up-to-date version of the blockchain consistently (with a cronjob) you can just sync up every time using --warp, thus giving you the same time cut without even having to run this consistently. Ultimately it comes down to trusting the confirmations that have occurred while you were gone are legit and not fraudulent. – Mark Beylin Nov 15 '16 at 1:41
  • As far as I can tell, --warp doesn't decrease the amount of blockchain data downloaded. It first syncs a subset of the data in an initial pass, and later in the background fills in the gaps with the rest of the data. It's the initial pass that takes an order of minutes, and on which the headline "sync within 10 minutes" is based. I don't believe there's a way to stop the sync after just this initial pass - if there was, then yes, the OP would have to trust this subset of data. As it is, he'd also have to account for the second, background sync stage in his cron script. – Richard Horrocks Nov 15 '16 at 14:42

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.