Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to stop geth once in sync #16400

Closed
chevdor opened this issue Mar 28, 2018 · 32 comments
Closed

Add an option to stop geth once in sync #16400

chevdor opened this issue Mar 28, 2018 · 32 comments

Comments

@chevdor
Copy link

@chevdor chevdor commented Mar 28, 2018

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
Copy link
Contributor

@holiman holiman commented Mar 28, 2018

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
Copy link
Contributor

@holiman holiman commented Mar 28, 2018

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
Copy link
Contributor

@lsgrep lsgrep commented Mar 29, 2018

@holiman can I work on this?

@holiman
Copy link
Contributor

@holiman holiman commented Mar 29, 2018

@lsgrep you'd be very welcome!

@zaq1tomo
Copy link

@zaq1tomo zaq1tomo commented Apr 3, 2018

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

@lsgrep
Copy link
Contributor

@lsgrep lsgrep commented Apr 3, 2018

Hi @zaq1tomo , I am working on it :)

@zaq1tomo
Copy link

@zaq1tomo zaq1tomo commented Apr 3, 2018

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

@isghe
Copy link
Contributor

@isghe isghe commented Apr 3, 2018

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

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

@vs77bb
Copy link

@vs77bb vs77bb commented Apr 23, 2018

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

@lsgrep
Copy link
Contributor

@lsgrep lsgrep commented Apr 24, 2018

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
Copy link
Contributor

@kielbarry kielbarry commented Apr 27, 2018

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

@glaksmono
Copy link

@glaksmono glaksmono commented May 4, 2018

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

@rbval
Copy link

@rbval rbval commented May 23, 2018

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
Copy link
Author

@chevdor chevdor commented May 24, 2018

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

danrpts added a commit to danrpts/go-ethereum that referenced this issue Jun 18, 2018
danrpts added a commit to danrpts/go-ethereum that referenced this issue Jun 18, 2018
danrpts added a commit to danrpts/go-ethereum that referenced this issue Jun 18, 2018
danrpts added a commit to danrpts/go-ethereum that referenced this issue Jun 18, 2018
@lhendre
Copy link
Contributor

@lhendre lhendre commented Jul 24, 2018

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

@chevdor
Copy link
Author

@chevdor chevdor commented Jul 24, 2018

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
Copy link
Contributor

@lhendre lhendre commented Jul 26, 2018

Ill take a look then!

@lhendre
Copy link
Contributor

@lhendre lhendre commented Jul 27, 2018

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

@ahlusar1989
Copy link

@ahlusar1989 ahlusar1989 commented Aug 24, 2018

@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
Copy link
Contributor

@isghe isghe commented Aug 26, 2018

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
Copy link
Contributor

@lhendre lhendre commented Aug 26, 2018

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

@lhendre
Copy link
Contributor

@lhendre lhendre commented Aug 30, 2018

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

@lhendre
Copy link
Contributor

@lhendre lhendre commented Sep 6, 2018

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
Copy link
Contributor

@adamschmideg adamschmideg commented Oct 15, 2018

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

@lhendre
Copy link
Contributor

@lhendre lhendre commented Oct 15, 2018

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
Copy link
Contributor

@adamschmideg adamschmideg commented Oct 16, 2018

PR being reviewed: #17321

@adamschmideg
Copy link
Contributor

@adamschmideg adamschmideg commented Nov 27, 2018

@karalabe has reservations he'll formulate

@lhendre
Copy link
Contributor

@lhendre lhendre commented Jan 11, 2019

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

@lhendre
Copy link
Contributor

@lhendre lhendre commented Feb 5, 2019

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

@rpagliuca
Copy link

@rpagliuca rpagliuca commented Oct 19, 2019

I think this issue should be closed.

@lhendre
Copy link
Contributor

@lhendre lhendre commented Oct 19, 2019

Agreed

@holiman
Copy link
Contributor

@holiman holiman commented Sep 10, 2020

Indeed!

@holiman holiman closed this as completed Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

14 participants