search

almindor / etherwall

Ethereum QT5 Wallet
GNU General Public License v3.0
142 stars 59 forks source link

"Unable to establish IPC connection to Geth... " #142

Closed verbal007 closed 2 years ago

verbal007 commented 2 years ago

When launching Etherwall Ethereum Wallet 3.0.3 on latest build of Manjaro, it is not able to connect to the wallet but instead displays the following error:

"Unable to establish IPC connection to Geth. Fix path to Geth and try again."

almindor commented 2 years ago

This happens if geth isn't running for some reason. Do you have geth installed an is Geth Path in settings tab correct? If so check the logs to see if geth itself doesn't show errors.

verbal007 commented 2 years ago

Thank you for the quick reply.

I've checked the path in the settings and verified that geth is in the location. This would have been strange, as Etherwall was working find for over a year now.

When trying to execute geth from the terminal, this is the output:

INFO [02-12|09:00:49.476] Starting Geth on Ethereum mainnet... 
INFO [02-12|09:00:49.476] Bumping default cache on mainnet         provided=1024 updated=4096
INFO [02-12|09:00:49.478] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-12|09:00:49.478] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
Fatal: Failed to create the protocol stack: datadir already used by another process

Note: Etherwall is closed when I run the command. When Etherwall was open, I received the same error.

almindor commented 2 years ago

Fatal: Failed to create the protocol stack: datadir already used by another process indicates that another geth instance is running. Does this persists accross reboots? Can you try something like ps aux | grep geth? or lsof | grep <datadir path>

verbal007 commented 2 years ago

While running geth from terminal, I did eventually get it to execute and it started to sync. I then copied the arguments that were listed in Etherwall, and used them in the terminal: --syncmode=fast --cache 512 This presented me with the following error: invalid value "fast" for flag -syncmode: unknown sync mode "fast", want "full", "snap" or "light"

So I tested this in the terminal, substituting "fast" to "light" and all was good.

I then changed this option in Etherwall's Geth args and... problem resolved.

I've never messed with these settings, so not sure where this invalid "fast" setting came from.

almindor commented 2 years ago

Ah this might actually be a bug. The --syncmode fast flag was the original default in older versions of geth and got replaced by --syncmode snap now. By default when using Etherwall in "thin client" mode geth is only used to handle account encryption and operations so Etherwall disables syncing, but a syncmode flag was always provided.

I've added code to replace the fast with snap. Sadly you overrode your settings already so I can't get the values to see why that replace failed. I'll have to look at all the places it might have happened.

verbal007 commented 2 years ago

I have another machine w/ same OS that also has Etherwall. I just started it up and seeing the exact same issues. How can I help test?

almindor commented 2 years ago

I have another machine w/ same OS that also has Etherwall. I just started it up and seeing the exact same issues. How can I help test?

If you still didn't fix this manually please copy your ~/.config/Etherdyne/Etherwall.conf file and send the contents of [geth] [node] and [program] sections (do not send the others as they contain your address and tx info). This will help me see which arg didn't get fixed and I can try on my local. Thanks!

almindor commented 2 years ago

I was able to identify one bug, where because the QSettings gethArgs value didn't get refreshed on the UI after replacing during init, it was still re-saved to the old --fast or --syncmode=fast case on application quit. Fixed in master now.

verbal007 commented 2 years ago

Gotcha. Sounds like you might have found the source. Let me know if you still need the config info from my other machine. Might take me a day or two to get to it.

almindor commented 2 years ago

Gotcha. Sounds like you might have found the source. Let me know if you still need the config info from my other machine. Might take me a day or two to get to it.

If you do get the args line it'd be good to confirm it all works but I think we're good without it.