search

openethereum / parity-ethereum

The fast, light, and robust client for Ethereum-like networks.
Other
6.83k stars 1.69k forks source link

Suggestion: don't show sync status if the port is already in use #11722

Open shanefontaine opened 4 years ago

shanefontaine commented 4 years ago

This is a suggestion regarding something I ran into when running OpenEthereum. If the port (30303) is already in use, the client should not continue to show the sync status: 2020-05-18 08:46:14 0/25 peers 72 KiB chain 17 MiB db 0 bytes queue 836 bytes sync RPC: 0 conn, 0 req/s, 0 µs. Instead, maybe don't show anything (further than the startup logs), or add information to the sync status that says the port is in use. The continued sync status messages with 0 peers may lead a user to think there is something wrong with the peer discover, as opposed to the port.

As it stands, if you run OpenEthereum and the port is already in use, there is a single message that is sandwiched between many of the startup logs that people generally overlook:

Network port V4(0.0.0.0:30303) is already in use, make sure that another instance of an Ethereum client is not running or change the port using the --port option.

For some background, I had an Geth instance running on that port that I had forgotten about. I ran OpenEthereum and saw the startup logs, but did not inspect them closely, as they looked like the normal logs you see when running OpenEthereum or Parity.

adria0 commented 4 years ago

This makes a lot of sense. I've been checking go-ethereum and also panics if the port is busy.

@dvdplm, do you see any problem to panic! (or at least warn!) on the Network port V4(0.0.0.0:30303) is already in use, make sure that another instance of an Ethereum client is not running or change the port using the --port option. message?

dvdplm commented 4 years ago

We do panic with Io(Os { code: 98, kind: AddrInUse, message: "Address already in use" }) but only if the node is using some kind of RPC. If you run the node with --no-jsonrpc or --no-ws then the ports the node usually reserves for those protocols are not used and I think it's actually ok to run several instances of a node on the same port (if RPC is off) but atm I struggle to come up with a valid use case for it (maybe as a sort of poor man's fail-over?).

I'm not opposed to make it a hard error, but it's worth investigating further why the node does not immediately shut down: intentional or oversight?

adria0 commented 4 years ago

I'm not opposed to make it a hard error, but it's worth investigating further why the node does not immediately shut down: intentional or oversight?

I'm trying to figure out what this is happening: related to dark mode? something related to client upgrades? I cannot see any rational explanation also.

I'm in to panic!, like as any another server there when trying to allocate a primary TCP port.

@vorot93, thoughts?