Go-ethereum: Geth light sync - Stucks at "IPC endpoint opened"

[PanosChtz]

System information

Geth version: v1.6.7-stable
OS & Version: Windows & Ubuntu 16.04LTS

Actual behaviour

ubuntu@ip:~$ geth --light
INFO [08-05|18:24:51] Starting peer-to-peer node               instance=Geth/v1.6.7-stable-ab5646c5/linux-amd64/go1.8.1
INFO [08-05|18:24:51] Allocated cache and file handles         database=/home/ubuntu/.ethereum/geth/lightchaindata cache=128 handles=1024
INFO [08-05|18:24:51] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Metropolis: 9223372036854775807 Engine: ethash}"
INFO [08-05|18:24:51] Disk storage enabled for ethash caches   dir=/home/ubuntu/.ethereum/geth/ethash count=3
INFO [08-05|18:24:51] Disk storage enabled for ethash DAGs     dir=/home/ubuntu/.ethash               count=2
INFO [08-05|18:24:51] Added trusted CHT for mainnet
INFO [08-05|18:24:51] Loaded most recent local header          number=0 hash=d4e567…cb8fa3 td=17179869184
INFO [08-05|18:24:51] Starting P2P networking
WARN [08-05|18:24:51] Light client mode is an experimental feature
INFO [08-05|18:24:51] RLPx listener up                         self="enode://4fbbe0ca345e2959812b622a8040685d45896381b0b0b29d081fce7c682e0291e0a435e25685d139baaa6df3f7b91946c25efdf5fc5f40c887d42d36703ee1a9@[::]:30303?discport=0"
INFO [08-05|18:24:51] IPC endpoint opened: /home/ubuntu/.ethereum/geth.ipc

It stops there even if I wait for hours.
Exactly the same happens in a different Windows machine in a different network and location.
Tried deleting the whole ethereum directory (including the old chain data) but same thing happens.

[ligi]

Currently facing the same problem - having a bit more in the log - no suitable peers available sounds pretty helpful to find the cause:

⋊> ~/g/3/go-ethereum on mobile_use_eip155signer ⨯ build/bin/geth --syncmode light                                                                              10:26:33
INFO [08-06|10:26:39] Starting peer-to-peer node               instance=Geth/v1.7.0-unstable-a682e9a4/linux-amd64/go1.8.3
INFO [08-06|10:26:39] Allocated cache and file handles         database=/home/ligi/.ethereum/geth/lightchaindata cache=128 handles=1024
INFO [08-06|10:26:39] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Metropolis: 9223372036854775807 Engine: ethash}"
INFO [08-06|10:26:39] Disk storage enabled for ethash caches   dir=/home/ligi/.ethereum/geth/ethash count=3
INFO [08-06|10:26:39] Disk storage enabled for ethash DAGs     dir=/home/ligi/.ethash               count=2
INFO [08-06|10:26:39] Added trusted CHT for mainnet 
INFO [08-06|10:26:39] Loaded most recent local header          number=2587304 hash=1dcae8…649233 td=87260543596335437690
INFO [08-06|10:26:39] Starting P2P networking 
INFO [08-06|10:26:41] UDP listener up                          self=enode://15d395ea43168914bafb009feb8a5b5483c23026ddb87b0888a722a99d5c9f63c3afec0a013028915de2a0206d6019b42b08b43b44fc18b2d3329efc948dc860@[::]:30303
WARN [08-06|10:26:41] Light client mode is an experimental feature 
INFO [08-06|10:26:41] RLPx listener up                         self=enode://15d395ea43168914bafb009feb8a5b5483c23026ddb87b0888a722a99d5c9f63c3afec0a013028915de2a0206d6019b42b08b43b44fc18b2d3329efc948dc860@[::]:30303
ERROR[08-06|10:26:41] Failed to retrieve current release       err="can't fetch trie key 49a295384b42457a1807b32f95fcb021d7862d2134f1110e2f2a8dcb71b7409d: no suitable peers available"
INFO [08-06|10:26:41] IPC endpoint opened: /home/ligi/.ethereum/geth.ipc 

Perhaps some key nodes switched off the light feature for some reason? Adding some static nodes might help in the meantime. Anyone knows some nodes with switched on light support?

EDIT: was just not patient enough and confirmed the error to early - after some time it started syncing:

⋊> ~/g/3/go-ethereum on mobile_use_eip155signer ⨯ build/bin/geth --syncmode light                                                                              10:26:33
INFO [08-06|10:26:39] Starting peer-to-peer node               instance=Geth/v1.7.0-unstable-a682e9a4/linux-amd64/go1.8.3
INFO [08-06|10:26:39] Allocated cache and file handles         database=/home/ligi/.ethereum/geth/lightchaindata cache=128 handles=1024
INFO [08-06|10:26:39] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Metropolis: 9223372036854775807 Engine: ethash}"
INFO [08-06|10:26:39] Disk storage enabled for ethash caches   dir=/home/ligi/.ethereum/geth/ethash count=3
INFO [08-06|10:26:39] Disk storage enabled for ethash DAGs     dir=/home/ligi/.ethash               count=2
INFO [08-06|10:26:39] Added trusted CHT for mainnet 
INFO [08-06|10:26:39] Loaded most recent local header          number=2587304 hash=1dcae8…649233 td=87260543596335437690
INFO [08-06|10:26:39] Starting P2P networking 
INFO [08-06|10:26:41] UDP listener up                          self=enode://15d395ea43168914bafb009feb8a5b5483c23026ddb87b0888a722a99d5c9f63c3afec0a013028915de2a0206d6019b42b08b43b44fc18b2d3329efc948dc860@[::]:30303
WARN [08-06|10:26:41] Light client mode is an experimental feature 
INFO [08-06|10:26:41] RLPx listener up                         self=enode://15d395ea43168914bafb009feb8a5b5483c23026ddb87b0888a722a99d5c9f63c3afec0a013028915de2a0206d6019b42b08b43b44fc18b2d3329efc948dc860@[::]:30303
ERROR[08-06|10:26:41] Failed to retrieve current release       err="can't fetch trie key 49a295384b42457a1807b32f95fcb021d7862d2134f1110e2f2a8dcb71b7409d: no suitable peers available"
INFO [08-06|10:26:41] IPC endpoint opened: /home/ligi/.ethereum/geth.ipc 
INFO [08-06|10:27:06] Block synchronisation started 
INFO [08-06|10:27:11] Imported new block headers               count=192 elapsed=2.751s number=3297471 hash=89be77…abbb67 ignored=0
INFO [08-06|10:27:11] Imported new block headers               count=192 elapsed=45.582ms number=3297663 hash=bc9779…0b21b5 ignored=0
INFO [08-06|10:27:11] Imported new block headers               count=2048 elapsed=482.349ms number=3299711 hash=779b52…6ea02d ignored=0
INFO [08-06|10:27:14] Imported new block headers               count=1984 elapsed=2.334s    number=3301695 hash=331371…64ec13 ignored=0
INFO [08-06|10:27:14] Imported new block headers               count=384  elapsed=92.892ms  number=3302079 hash=90173c…25a7b0 ignored=0
INFO [08-06|10:27:14] Imported new block headers               count=1920 elapsed=435.581ms number=3303999 hash=4234c7…a2fc5e ignored=0
INFO [08-06|10:27:14] Imported new block headers               count=192  elapsed=55.264ms  number=3304191 hash=3e534c…0a4a07 ignored=0

[mikedarke]

@bomberb17 I've been stuck with this all day and then realised if instead of using the deprecated geth --light I use geth --syncmode "light" it starts synchronising straight away

[0xBADCODE]

@mikedarke I don't know how you did this, you can't run --syncmode and --light at the same time, --light is by default now.

I'm having the same issue for teh past week.
Lightchaindata is not syncing. I can restart a full node sync but lightnode is not working at all. No peers and adding peers manually doesnt help. Halp?!

[mikedarke]

@bomberb17 no I didn't run --syncmode and --light at the same time. Instead of running geth with the --light option I ran it using geth --syncmode "light", I believe the default syncmode is "fast".

Using the --syncmode option with either "light" or "fast" has replaced using either --fast or --light options. If you run geth --help you can see that --light and --fast are listed as deprecated options.

I tested this in multiple environments that were all not progressing past the "IPC endpoint opened" stage using the --light option. Using geth --syncmode "light" they synced in a few minutes.

[PanosChtz]

You are right, --syncmode light works fine on me as well.
Thanks!

[0xBADCODE]

~ $ geth --syncmode "light"
Fatal: flags --light, --syncmode can't be used at the same time
~ $ geth --syncmode light
Fatal: flags --light, --syncmode can't be used at the same time

:(

[0xBADCODE]

OK. on an arm6 node I can run --syncmode light option but on my x64 mode I get that fatal error. weird.

[AndreasThom]

I can confirm this:

geth -- light

doesn't work past

INFO [08-05|18:24:51] IPC endpoint opened: /home/ubuntu/.ethereum/geth.ipc

whereas

geth --syncmode "light"

works without problem.

[ShawnMcGough]

I can also confirm the comment above on version 1.6.7 for windows.

geth --light hangs indefinitely. geth --syncmode "light" works after a brief delay.

Perhaps geth --light could be more fully depreciated and return a message. Something like geth --light has been deprecated, did you mean geth --syncmode "light"?

[ayang99]

I set up a new node on Ubuntu 16.04.03 LTS with geth version 1.6.7-stable-ab5646c5 on the Ropsten testnet:

geth --testnet --syncmode "light" --cache=1024

Both geth --light and geth --syncmode "light" hang at "IPC endpoint opened".

geth --syncmode "fast" worked though.

Is the ~/.ethereum/testnet/geth/lightchaindata/LOG file useful? There isn't much in there.

[ryancody]

Same as ayang99, I am running Ubuntu 16.04 LTS on amazon web service server:

works fine:
geth --testnet --rpc --rpcapi "admin,db,eth,debug,miner,net,shh,txpool,personal,web3" --syncmode "fast" --rpccorsdomain '*' --rpcaddr 0.0.0.0 --rpcport 8545

freezes at "Failed to retrieve current release err="can't fetch trie key":
geth --testnet --rpc --rpcapi "admin,db,eth,debug,miner,net,shh,txpool,personal,web3" --syncmode "light" --rpccorsdomain '*' --rpcaddr 0.0.0.0 --rpcport 8545

only difference is "fast" vs "light"

thanks

[SimonHausdorf]

ERROR[10-21|01:57:38] Failed to retrieve current release err="can't fetch trie key ...: no suitable peers available"

1.7.2

[PanosChtz]

delete everything in chaindata folder and run geth again. This happens me all the time when I sync in light mode and I have to sync again.

[ligi]

"can't fetch trie key ...: no suitable peers available"

might have to do with - https://github.com/ethereum/go-ethereum/issues/15342 - I also had to switch off lightserv so the node is not crashing. I think there are very little nodes serving les now. Very unfortunate.

[SimonHausdorf]

deleting chaindata didn't help, switching to fast mode

[skozin]

I have the same issue. After deleting chaindata, it works the first time (though I have to wait quite a lot of time until it imports all headers), but after restarting it prints this Failed to retrieve current release err: can't fetch trie key xyz: no suitable peers available error, and most of RPC method calls fail with the same no suitable peers available error.

Using --syncmode light instead of --light doesn't help.

This is on Geth/v1.7.2-stable-1db4ecdc/darwin-amd64/go1.9.1.

[Zolmeister]

For me it eventually recovers (<2hr)

Update: it still crashes ~daily

[bovcan]

we will see, facing the same problem last week. Last time left it on for 10h but nothing moved.

[cherurg]

Removing lightchaindata folder works for me. Only temporary though. geth 1.7.3-stable.

[dobdob]

I can also confirm seeing similar behavior using light mode with "no suitable peers available" when I run geth from the CLI.
Also deleting the lightchaindata will work once and at next restart it's broken again
If I do an in-app switch from light to normal in Ethereum Wallet it finds peers almost immediately.

[cryptonic-p]

Solution:"can't fetch trie key ...: no suitable peers available"-->

is not about Chaindata, is about connecting nodes. probably you run geth with a firewall, this is a issue for light users, solved it: delete your node key from your saved data dir, and boot geth like

geth console --datadir <your data dir> --ipcpath <ipc path> --port "35555" --light --cache 1024 --rinkeby

this is for connecting to the rinkeby test network.

after this step you can connect the mist wallet manually by:
running

/Users/USERNAME/Desktop/Ethereum\ Wallet.app/Contents/MacOS/Ethereum\ Wallet --rpc /Users/USERNAME/Library/Ethereum/rinkeby/geth.ipc

:)

[Snerken]

I just wanted to have a test run to set up an account and typed this at the command prompt.
$ geth --rpc --rpcapi="eth, web3, personal"
Three hours later and the synchronisation is still going on with no end in sight...good grief!

Something tells me I should be using ethereumjs-testrpc instead.

[lmars]

@Snerken if you just want to run a local chain for test purposes, try geth --dev.

[SherSlick]

FWIW for me to get the Light mode to work I had to delete the following:
ethash/
lightchaindata/
chaindata/
LOCK
nodekey
nodes/

THEN I could start Geth with --syncmode "light"

TL;DR: if you ran Geth in full or fast modes prior, you have to "start from scratch" to get it going in light mode.

[fredcrs]

@SherSlick I did this and still didnt work.... =(

[Anderseta]

--syncmode "light" is not working confirmed for geth 1.7.3 (windows).
--syncmode "fast" works

[fair18]

--syncmode "light" is not working confirmed for geth 1.7.3 (docker ethereum/client-go).
--syncmode "fast" && "full" works as well

[cloudzhong]

why --syncmode "light" is not working now.

[kofiasare]

same --syncmode "light" not working

[Cloetn]

I'm having the same issue here. It worked yesterday with syncmode light. Now it's not starting anymore.
Stuck on 'Mapped Network Port'. This is for Geth 1.8.1.

Edit:

• Shutting down several OneDrive sync clients & Spotify somehow did the trick. I'm going to keep watching this.

[mahuaibo]

same --syncmode "light" not working

This is for Geth 1.7.3 & 1.8.2

> geth --syncmode "light" --identity "PICCetherum" --rpc --rpcaddr "172.20.10.2" --rpcapi "personal,db,eth,net,web3,miner" --rpccorsdomain "*" --datadir "./mainchain" --port 8545 --networkid 1

Don't worry too much ，The second day .

INFO [03-11|14:13:25] Imported new block headers count=1 elapsed=9.379ms number=5234579 hash=899bd5…a31604 ignored=0
INFO [03-11|14:13:25] Imported new block headers count=0 elapsed=192.915µs number=5234579 hash=899bd5…a31604 ignored=1
INFO [03-11|14:13:26] Imported new block headers count=1 elapsed=12.965ms

[Jay-Way]

geth --syncmode "light" for Geth v1.8.2 stucks at IPC endpoint opened but works after a while on an arm7 node, up and running since several days now.

[9nix00]

It's still stuck. I have to use "fast" mode. so sad.

[shazow]

I believe this error happens when the light client is unable to find an available connection slot on a full node.

If you have access to a full node, you can add your light client's enodeID to the trusted/reserved set and connect to it directly using the static-nodes.json feature.

If not, you can try using vipnode where you execute a smart contract to get whitelisted on a full node: https://vipnode.org/

(Disclaimer: This is my project, and it's being developed further thanks to an Ethereum Foundation grant. I wrote more it here: https://medium.com/@shazow/an-economic-incentive-for-running-ethereum-full-nodes-ecc0c9ebe22)

[karalabe]

Closing as this is normal (perhaps annoying) behavior. Sometimes it takes a lot of time to find a light server. We're working on alternative discovery mechanisms too, but there's not much to do in between. You need to wait it out for a server to be found.

[aekazitt]

When I set verbosity to 4, I saw a lot of failed handshakes because of mismatched chainId (1 != 3).
So I ran removedb for both chaindata & lightchaindata (both on testnet and mainnet) as well and restarted a new geth on light with entirely separate data directories, ie.

Mainnet

geth --syncmode 'fast' --datadir /path/to/.geth
... This creates /path/to/.geth/geth/chaindata/ folder

Mainnet-lite

geth --syncmode 'light' --datadir /path/to/.geth/light
... This creates /path/to/.geth/light/geth/lightchaindata/ folder

Testnet

geth --syncmode 'fast' --datadir /path/to/.geth/testnet
... This creates /path/to/.geth/testnet/geth/chaindata/ folder

Testnet-lite

geth --syncmode 'light'--datadir /path/to/.geth/testnet/light
... This creates /path/to/.geth/testnet/light/geth/lightchaindata/ folder

---

The non-responsive light server and slow synchronization seemed to have disappeared for me.
I suspect that restarting geth with --syncmode 'light' while also having chaindata/ folder in datadir makes your local instance bipolar with mismatched chainId & chaindata, therefore unsynchable.

---

Hope this helps.