I have a fresh new installation of Ubuntu 16.04 and I've followed manual to setup geth

sudo apt-get install software-properties-common
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo add-apt-repository -y ppa:ethereum/ethereum-dev
sudo apt-get update
sudo apt-get install ethereum

And after starting geth it hangs up on

I0925 07:53:21.655924 node/node.go:308] IPC endpoint opened: /home/username/.ethereum/geth.ipc
I0925 07:53:21.656651 p2p/server.go:576] Listening on [::]:30303

0 peers, nothing happens, no syncing. htop shows occasional activity in CPU, console answers but shows 0 peers:

geth attach
Welcome to the Geth JavaScript console!

instance: Geth/v1.5.0-unstable/linux/go1.6.2
coinbase: 0x4c49eed9cc104695593cd2a9745ce108e28efc09
at block: 0 (Thu, 01 Jan 1970 03:00:00 MSK)
 datadir: /home/username/.ethereum
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

> net.listening
> net.peerCount

Am I doing something wrong?

1 Answer 1


The geth Bootnodes Are Down

I've tested, and the peer discovery nodes are intermittently / mostly down.

Update 08:19 Sep 25 2016

I suspect that the bootnodes are congested due to the many geth clients trying to get connections as the clients are being restarted due to the recent memory bug attack and spam / IO transaction attacks.

telnet is able to intermittently connect to some of the bootnodes, but geth has been unable to find any peers for over an hour.

A separate geth node I started many hours ago is working fine with 25 peer connections.

I have checked the blockhash for the latest block I have synced up to and it matches etherscan.io #2,287,735:

> admin.peers
> eth.blockNumber
> eth.getBlock(eth.blockNumber).hash

enter image description here

Update 23:17 Sep 25 2016

@jamiepitts-ethereum in reddit said

Please test this now and reply whether peers are found and the sync begins for you.

In geth 1.4.12, I am now able to find peers and successfully start syncing.

I've tested and my previously non-syncing node now syncs automatically. I retested connectivity to the bootnodes below and the first 3 connect immediately.

It would be interesting to know what caused this non-syncing situation for many geth nodes. Update the node software on their bootnode servers? Reboot their bootnode servers? Make available more connection slots on their bootnode server?

Update 12:09 Sep 26 2016

There is a new version of geth named Geth 1.4.13: Into the Woods (various DoS fixes) that you can download from https://github.com/ethereum/go-ethereum/releases/tag/v1.4.13 .

The .zip files with the source code and some of the different operating systems version have been made available from this page. Download the version appropriate to your operating system (if it is there, or else wait until it is available).

The Ubuntu ppa now contains http://ppa.launchpad.net/ethereum/ethereum/ubuntu/ trusty/main bootnode amd64 1.4.13+87trusty-0ubuntu1 with this new version, so just update your ubuntu installation to pick up the new version.

This version should sync to other peers (problem fixed in the last update), but should process the I/O spam transactions much quicker compared to version 1.4.12 .

Temporary Workaround

See How can I extract create a list of peers from my syncing geth node to manually paste into my non-syncing geth node using the admin.addPeer() command? for a list of admin.addPeer(...) commands you can paste into your geth console to kick-start your node syncing.

My Tests

Update 13:51 Oct 01 2016 Note that the following test are not definitive as the bootnodes normally operated using the UDP protocol on port 30301, but I used the TCP 30303 for my testing. See Why does java Ethereum use UDP? - isn't devp2p TCP only and What is an Enode ID in Ethereum?.

Checking geth version

user@Kumquat:~$ geth version
Version: 1.4.12-stable
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.5.1
OS: linux

The geth bootnodes are listed in https://github.com/ethereum/go-ethereum/blob/master/cmd/utils/bootnodes.go#L25-L30 and are:

discover.MustParseNode("enode://[email protected]:30303"), // IE
discover.MustParseNode("enode://[email protected]:30303"),  // BR
discover.MustParseNode("enode://[email protected]:30303"),  // SG

// ETH/DEV Cpp Bootnodes
discover.MustParseNode("enode://[email protected]:30303"),

Testing the first server:

user@Kumquat:~$ telnet 30303
telnet: Unable to connect to remote host: Connection timed out

Testing the second server:

user@Kumquat:~$ telnet 30303
telnet: Unable to connect to remote host: Connection timed out

Testing the third server:

user@Kumquat:~$ telnet 30303
telnet: Unable to connect to remote host: Connection timed out

Testing the fourth server:

bok@Kumquat:~$ telnet 30303
telnet: Unable to connect to remote host: Connection refused

Expected Results As Demonstrated On The Testnet Bootnode Servers

This is not the normal response for the bootnode servers. Here is the bootnode server for Testnet, listed in https://github.com/ethereum/go-ethereum/blob/master/cmd/utils/bootnodes.go#L37-L38:

discover.MustParseNode("enode://[email protected]:40404"),
discover.MustParseNode("enode://[email protected]:30303"),

The second bootnode server is responding as expected, not the first:

user@Kumquat:~$ telnet 40404
telnet: Unable to connect to remote host: Connection refused

user@Kumquat:~$ telnet 30303
Connected to
Escape character is '^]'.
Connection closed by foreign host.
  • thanks, sync started. Should I expect that bootnodes will go up some time in future?)) Because Ive got only one peer in this way.
    – tazm
    Commented Sep 25, 2016 at 7:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.