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

Very long Control-C delay during first minute or so is annoying #585

Closed
jlokier opened this issue Apr 13, 2021 · 3 comments
Closed

Very long Control-C delay during first minute or so is annoying #585

jlokier opened this issue Apr 13, 2021 · 3 comments

Comments

@jlokier
Copy link
Contributor

jlokier commented Apr 13, 2021

During the first minute or so after starting nimbus, pressing control-C is trapped and has no effect for a rather long time. This is very annoying, if you just started something to debug then want to do something else. It's easily worked around by Control-Z then killing the process, but this is still a poor experience.

After the first minute or so, control-C exits reasonably fast, so it can do this.

@jlokier
Copy link
Contributor Author

jlokier commented Jun 14, 2021

The cause of this unresponsiveness is slow sequential initialisation in nimbus.start.

There are a number of steps which take time depending on network activity, during which Control-C is ignored. The worst of these is the discovery phase, which effectively runs as a "foreground task" for some minutes before allowing the sync phase to be initialised. This waitFor during initialisation takes several minutes:

waitFor nimbus.ethNode.connectToNetwork(conf.net.bootNodes,

There are other steps which are usually fast, but could be slow if you are unlucky (e.g. UPNP/NAT-PMP configuration). So the issue isn't one single waitFor. All steps should be abortable.

Async cancellation tokens (set by the Control-C signal) are a general solution to this problem, but that may require a change to Chronos. A more pragmatic (but ugly) immediate solution is to make P2P connectToNetwork busy-wait with short timeouts and check for the Control-C condition.

@jlokier
Copy link
Contributor Author

jlokier commented Jun 14, 2021

Note, in configurations where no peers are successfully connected to, the waitFor doesn't return.

This happens when static nodes are set and discovery is disabled. If the static node is down or refuses connection, Nimbus Eth1 doesn't retry, connectToNetwork never completes, and Control-C doesn't work no matter how long you wait. When this happens, 100% of the time you want to use Control-C :-)

@kdeme
Copy link
Contributor

kdeme commented Jun 15, 2021

Yes, I was having similar issues with the p2p implementation of nim-eth when using it for nim-waku wakunode.

Back then I just did this: https://github.com/status-im/nim-waku/blob/master/waku/v1/node/wakunode1.nim#L61
But it is still flawed in several ways, and the peer management could really use some rework in nim-eth (well it is rather non existent right now)

I'm pretty sure I had created an issue for this back then but can't seem to find it back.

@jangko jangko closed this as completed in 25302f4 Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants