Add an option to stop geth once in sync

[chevdor]

This is not a bug but a feature request aiming at having more users in sync, faster and more consistently, especially for those not operating nodes running 100% of the time.

Similar issue reported for parity: openethereum/parity-ethereum#8244

In the early days, Geth has been built as a node and the priority was/is obviously to never stop or break.Today, if we consider the users operating nodes on servers, this is still critical that geth nodes never stops.

We also need to consider another class of users: those who use Geth daily (or almost) and start/stop geth all the time. For those, it used to be fast syncing their node: a few minutes or an hour at max would fetch a good week or too of blocks.

This is no longer the case. Nowadays, not syncing every day becomes quickly painful.

I propose the addition of a new flag that would stop and exit when the chain has been caught up.
It could something like:
geth --exit-when-synced N
With N being the number of seconds to keep running once the chain is in sync. N=0 means geth exists immediately once the chain is caught up.

Having this flag means users could sync all their geth chains (fundation, ropsten, rinkeby) overnight on a single machine by simply chaining the syncs:

geth --rinkeby --exit-when-synced 15 && \
geth --ropsten --exit-when-synced 15 && \
geth --exit-when-synced

Once all the syncs are done, the poor (but warm) laptop could go back to rest for a good part of the night.

Recently, as a workaround to that, I published https://github.com/chevdor/ethup. One benefit of ethup is that it supports parity as well but I think it would be more elegant to have a solution directly in geth, without having to install additional npm packages.

[holiman]

I agree, it would be a nice feature. I'll flag this as good-first-issue. If anyone disagrees with this, feel free to undo that.

[holiman]

I would also like something like
geth <options> --exit-at-block <num>.
When the desired block number is reached, geth would act just like if ctrl-c was hit: it would persist to disk and exit orderly. It would also be great if we could dump out the block num+1 as an rlp file.... My usecase is investigating a crash at a certain block, it would help greatly to be able to do these things.

I don't know how we could conceivably do this if it's doing a fast-sync and the num is lower than the pivot point -- in that case maybe it should just exit.

[lsgrep]

@holiman can I work on this?

[holiman]

@lsgrep you'd be very welcome!

[zaq1tomo]

@lsgrep If you are busy, can I do this issue?

[lsgrep]

Hi @zaq1tomo , I am working on it :)

[zaq1tomo]

Thanks for your reply @isghe, I got and leave it to you.

[isghe]

Thanks for your reply @isghe, I got and leave it to you.

@zaq1tomo maybe you meant @lsgrep , not @isghe ;-)

[vs77bb]

Hi @holiman is this issue still open? We are considering adding a Gitcoin bounty for this issue.

[lsgrep]

Hi, sorry for not updating this issue. I've been a bit busy for the past month, and it is over. Now I have the time to work on PR.

[kielbarry]

@lsgrep please let me know if you put down your work on this as I'd like to pick up this issue.

[glaksmono]

Anyone is looking into this issue? Otherwise I want to take my first stab at it @lsgrep @kielbarry @holiman @chevdor

[rbval]

Anyone taking a stab at this? Would be interested in taking this one as my first issue.
Any guidance (gotchas) that would speed up the process of getting faster into solving this? @chevdor @holiman @lsgrep @isghe @zaq1tomo ?

[chevdor]

@rbval Happy to see activity here so thanks for the question.
I doubt I can be of much help here. ethup is simply spying at the geth output and tries to guess (it does a fair job at it) when the sync is complete. I am sure that geth internally has the info and can be much smarter than ethup.

[lhendre]

@chevdor @danrpts is this still being worked on? I have some freetime and have been looking for a first issue to pickup

[chevdor]

I am not working on this so feel free!
https://github.com/chevdor/ethup does the trick so far so I am also not working on it atm.

[lhendre]

Ill take a look then!

[lhendre]

Making some commits looking to have something committed/pushed by monday at the latest

[ahlusar1989]

@lhendre What's your status on this? @chevdor Based on the ethup utility is there some variant that you need to be ported as a separate package in this repo?

[isghe]

please, how can i be removed, from this notification? Someone wrote by mistake my nick isghe against isgrep. I am NOT interested on this PR. Thanks

[lhendre]

@ahlusar1989 I have some code setup and am testing it at the moment, I still need to implement the light mode portion

[lhendre]

I have a lightnode version and have a pull request out, I am awaiting feedback and testing

[lhendre]

Most of it seems to be working and formatted correctly. The main question I am being asked is what should occur if it is archiving, is there any opinions on this

[adamschmideg]

@lhendre I wonder what your suggestion is. Is your code ready for a PR?

[lhendre]

Hi, @adamschmideg my suggestion for that, if it is archiving, is that it also turns off when synced. There is a PR out and they asked me to make a modification. I was using a channel to determine when the code was done syncing and they asked me to change it to an event. The change has been made and the code has been pushed. I am testing on my computer and waiting feedback on the PR.

[adamschmideg]

PR being reviewed: #17321

[adamschmideg]

@karalabe has reservations he'll formulate

[lhendre]

The code has been updated based on the reservations, awaiting feedback on the PR

[lhendre]

Code was merged in. The code takes in a boolean flag and stops when the download done event is fired

[rpagliuca]

I think this issue should be closed.

[lhendre]

Agreed

[holiman]

Indeed!