can't fetch trie key xxxx: no suitable peers available

[jacktang]

Version: `0.9.2`
OS & Version: windows/linux/osx
Node version: `geth 1.7.2` 
Number of blocks synchronized: N/A
OS: OSX
Mode: light wallet

My mist wallet was sync blocks about 5% percent and I shutdown the application yesterday. When I restart the application. It tells Ethereum node connected and I can't launch the main application. I check the log(attched). And it shows error message can't fetch trie key cb4fc7eee3d463bef0958e03a385071ba472ade9c4bc6b64cca038d1b20ac332: no suitable peers available. Then I try to restart geth and it stops at current screenshot .

node.log
node.log.0.txt

If I run geth removedb, it will re-sync from the beginning, should I keep my laptop always on to keep the sync running? or just wait checking the network with patience ? Thanks!

[jacktang]

Update the node.log.
It seems enter a loop:
restart geth -> sync -> sync failed(download cancel) -> no suitable peer -> have to restart geth ...

[tobiv]

Please try it with the new version 0.9.3

[gamerate]

I have same problem with 0.9.3 of Fedora geth removedb don't helps too
Is there any workaround about this problem known yet?

Also I have effect like this:
INFO [12-08|23:02:16] Imported new block headers count=192 elapsed=62.649ms number=4608 hash=368d89…1cd7d7 ignored=0
INFO [12-08|23:02:16] Imported new block headers count=192 elapsed=67.932ms number=4800 hash=e26684…e91df7 ignored=0
INFO [12-08|23:02:16] Imported new block headers count=192 elapsed=62.567ms number=4992 hash=c6c053…2f14d4 ignored=0
WARN [12-08|23:02:52] Rolled back headers count=2048 header=4992->2944 fast=0->0 block=0->0
WARN [12-08|23:02:52] Synchronisation failed, retrying err="block body download canceled (requested)"

and then nothing happens

[ShamanReaper]

Same issue here... not syncing light wallet.

[jacktang]

@tobiv thanks, 0.9.3 with geth 1.7.2 works fine :)

[KainniaK]

I have the same problem, in light mode it only ever finds one or two peers and it dissconects from them all the time. When I don't run ethereum wallet for a while and then load it it takes a long time in light mode to get all the blocks but now since a couple of days ago it just won't completely sync. Is there a bug in the software or are there just not enough light peers? I have geth 1.7.3 and I don't know how to go back to 1.7.2

[vaioco]

Hi,
same here, running latest Mist on Mac OSX I keep getting errors because of "no suitable peers available".
thanks

[richh94]

Edit: not related anymore

[kbirken]

Same problem here, 0.9.3 with geth 1.7.2 on MacOS 10.13.2 (High Sierra).

[cryzed]

This is ridiculous. This is not the first time I've run into this bug (and I think even reported it), the only workaround is to delete the light chaindata and restart the whole synchronization -- after that is done, don't close geth, start Mist and do your transactions. After quitting geth once, you'll most likely get this error and it won't ever synchronize again. I'm surprised how Ethereum got this big, this quickly, with such terrible bugs in some of the core software.

[brandoncurtis]

@cryzed "no suitable peers" is just a peering problem. By default, Geth nodes are configured to ignore light clients, and node operaters need to set geth --lightserv to a non-zero value to change that. Parity nodes only support Ethereum Light Subprotocol v1 (Geth uses LESv2), so Parity nodes can't serve Geth light clients either. The universe of compatible LESv2-friendly full nodes might be very small.

If you wait patiently, the light client eventually finds a suitable full node and syncs. This should also be remedied by passing Geth a list of known-good fully-updated Geth light-client-friendly full nodes with the --bootnodes option. Not great, but this should become less of a problem as LES matures and Parity also supports LESv2!

[cryzed]

@brandoncurtis given the messages in the debug log, it really looks like as if all connections to peers are dropped and the synchronization stops entirely. I assumed that this was a bug (and not simply me being impatient) because finding peers is no issue if you start synchronizing the light blockchain from the beginning, however once you restart geth, you suddenly run into this issue. While it initially takes a few minutes to find peers with a new light blockchain, it's not comparable to the time you presumably have to wait for peers to be discovered after getting this error, at least in my experience.

Regarding the bootnodes option, is there any chance you have such a list?

[KainniaK]

Is this finally going to get fixed? I only have internet a couple of hours a day and right now I have been unable to use the application for over a week! Please fix!!!!!!!!!!!

[mcneish]

I've been experiencing the same issue with the same error at startup, but I'll echo @brandoncurtis and say that Geth does eventually find peers... for a little while, at least. It's very start-and-stop, and there's no consistent syncing, but it works. Seems to have been getting better during the day, though, even if the peak number of peer connections indicated in Ethereum Wallet has been 1. For now I'll just assume there aren't enough --lightserv nodes for the demand.

[one10]

Same here, even in non-light mode was getting 5-6 peers max, then stopped finding any. I removed all chaindata (in full mode), resync took several days and >50GB of data, I had to keep deleting files to make room, finally lost patience and switched to light mode. It synced like 4,000,000 out of 4,000,100 (you gotta be joking, right?) and now stuck forever in this "node connected" "no suitable peers available" mode, does't retry, doesn't try to find peers, just sits there forever. How is this software even usable? In light mode there are no peers, in full mode it blows past 50GB of data and never stops.
(also 0.9.3 with geth 1.7.2 on MacOS 10.13.2)

[garyng2000]

while ethereum is designed to be a P2P, in actual usage it seems that only a handful of dedicated nodes(say infura) is reliable enough to be used for anything that is production quality. I have at least 3 separate machines at 3 different locations(in different countries) running both full and light. NONE can last a few days before they are stalled which requires me to stop and start again. Each time, they will catch up eventually but during that period, no transaction submission is possible.
Our whole Dapp architecture needs to be designed around this reliability issue of nodes.

edit:
this has nothing to do with Mist BTW, just the core 'geth' system which AFAIK is launched by Mist/Ethereum Wallet if it is not started. So my advice is start it in a console then launch Mist and observe the console to see if get stuck and recover. Ok for personal/home use but no way for production Dapp, use infura instead.

[cryzed]

... hence my confused comment from above:

I'm surprised how Ethereum got this big, this quickly, with such terrible bugs in some of the core software.

If the software at least didn't simply stall and continued searching for peers instead, I'm sure the problem wouldn't even exist in the first place. IMHO this is completely unacceptable for the core software of an emerging cryptocurrency.

[brandoncurtis]

I've been running several nodes for months: a mix of Geth and Parity, fastsync and full archive, five of them running this instant. There are a dearth of suitable peers for light clients, but I haven't had a problem with the other pruning modes.

Check your firewalls—nodes find eachother on port 30303. If your routers don't support upnp, you can set up port forwarding manually. See Connecting to the Network for details.

[garyng2000]

You mean my router works sometimes but not other times ? Not sure how geth does its port things but it is not like it never worked. It is more like it works for a few days then stalled forever because it cannot find peers or whatever. Whenever I see this, I would just cancel(ctrl-c) and restart it and it would be fine(for the full mode almost always, light mode however is a matter of luck like it can find peers with 10 minutes or so but at a bad day, can wait a few hours).
So I would say it is a matter of luck what peers it finds. also when it is in the 'stalled' state, it cannot even gracefully shutdown and I need the 'kill' command to kill the process.

[KainniaK]

@ garyng2000 If Ethereum is designed to work in P2P why don't Ethereum Wallet users connect to other Ethereum Walllet users, even in client mode, why don't clients help other client? Just give the clients an option to set a limit to upload rate or maximum upload amount. That would probably help with node discovery

[garyng2000]

I believe that is basically what geth(or parity) is already doing. Ethereum Wallet(or Mist or any other Dapp accessing via rpc/ipc) just use geth as their 'service manager'. I would say it is the availability of the node that is the problem. We have these issue since the very early day of P2P be it Napster or Skype or bitorrent, it took time for it to get mature. For now it probably is easier to delegate that to infura but that means 'trust infura' which kind of beat the original intend of everyone runs their own node(not mining but at least verifying)

[Riftr]

I got this with the light version and might have a fix. In my node.log I received the same can't fetch trie key error. Doing the below successfully worked for me and I managed to finish the updates.

I went into my lightchaindata folder and renamed the last .ldb file (by alphanumeric name) by appending OLD to the front (effectively removing it as far as Mist is concerned). I then started up the client again and although I was still on the Ethererum Node Connected screen, the error no longer appears in my node.log file and I could see that the lightchaindata folder has redownloaded the .ldb file successfully and continued on.

For reference, the .ldb file that seemed to fail for me was 001517.ldb. It was only 1KB in size whereas the others are all 2079KB. It may be a different file for others. It would appear as if something is getting corrupted during download.

[evertonfraga]

The Geth Light Client mode is still experimental, as informed.

I invite you to the Light Client gitter channel so you can talk with the maintainers in order to troubleshoot/debug this issue: http://gitter.im/ethereum/light-client

I'm closing this for now as the provided link is the best place to keep this discussion.

[ryanvolum]

I haven't found a clean fix to this problem, but when running geth --syncmode light --verbosity 4 I see more details. With verbosity on high you can see the geth client attempting to connect to peers over time - eventually (every half hour or so...) I generally seem to connect to one or two

[KainniaK]

I stopped using Ethereum all together. But if I would ever use it again I would use it over myetherwallet
Light clients are apparently very low priority for the devs and I have had enough.

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.