Mist: Mist wallet syncs nodes and then runs but then does not sync

[OmniEdge]

Node type: geth/eth
OS: linux Ubuntu 14.04
Network type: main
Mist version: 0.5.2

History: Mist would sync very slowly and get stuck. Every time I had to restart Mist in order to d/l more of the blockchain. I then started syncing blockchain using geth --fast. Then the current issue started.
Work around: I have to restart Mist in order to get my blocks synced.

omniedge@omniedge-Inspiron-3542:~/.config/Mist$ cat node.log
I0327 08:29:16.986566    3507 database.go:71] Alloted 433MB cache to /home/omniedge/.ethereum/chaindata
I0327 08:29:18.404659    3507 database.go:71] Alloted 78MB cache to /home/omniedge/.ethereum/dapp
I0327 08:29:18.428764    3507 backend.go:314] Protocol Versions: [63 62 61], Network Id: 1
I0327 08:29:18.469989    3507 backend.go:362] Blockchain DB Version: 3
I0327 08:29:18.551794    3507 blockchain.go:214] Last header: #1227115 [b2acf601…] TD=10907556565264717722
I0327 08:29:18.551823    3507 blockchain.go:215] Last block: #1227115 [b2acf601…] TD=10907556565264717722
I0327 08:29:18.551833    3507 blockchain.go:216] Fast block: #1227115 [b2acf601…] TD=10907556565264717722
I0327 08:29:18.575036    3507 handler.go:92] blockchain not empty, fast sync disabled
I0327 08:29:18.626754    3507 cmd.go:114] Starting Geth/v1.3.5-34b622a2/linux/go1.6
I0327 08:29:18.652734    3507 server.go:311] Starting Server
I0327 08:29:19.371041    3507 udp.go:212] Listening, enode://79d9985dfa5841b0c1d4265ff47b64c8bcc9d8132b4517decec59428bad27e44a8923a5638479ecc6b90f1907cd35d5b66382a0e2e32dfacb579d81951cbae33@[::]:30303
I0327 08:29:19.371341    3507 backend.go:526] Server started
I0327 08:29:19.371372    3507 server.go:552] Listening on [::]:30303
I0327 08:29:19.411149    3507 ipc.go:112] IPC service started (/home/omniedge/.ethereum/geth.ipc)
I0327 08:30:19.371656    3507 downloader.go:288] Block synchronisation started
I0327 08:30:22.914172    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 1.78558889s. #1227116 [bd860f34 / bd860f34]
I0327 08:30:22.991465    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 2 txs in 77.20923ms. #1227117 [0f7d12b6 / 0f7d12b6]
I0327 08:30:26.569785    3507 blockchain.go:1251] imported 10 block(s) (0 queued 0 ignored) including 16 txs in 558.343086ms. #1227127 [85e40cac / 7a6021eb]
I0327 08:30:47.340896    3507 blockchain.go:1251] imported 54 block(s) (0 queued 0 ignored) including 309 txs in 19.653552323s. #1227181 [3b219259 / 96274755]
I0327 08:31:41.713366    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 3 txs in 8.049493ms. #1227182 [cc36180e / cc36180e]
I0327 08:31:41.766637    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 3 txs in 18.854739ms. #1227183 [e0d1b92a / e0d1b92a]
I0327 08:31:41.840033    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 26 txs in 69.045363ms. #1227184 [7b375797 / 7b375797]
I0327 08:31:41.867839    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 7 txs in 23.010235ms. #1227185 [a3a71ebe / a3a71ebe]
I0327 08:31:42.391949    3507 blockchain.go:1251] imported 0 block(s) (0 queued 3 ignored) including 0 txs in 4.991573ms. #1227185 [e0d1b92a / a3a71ebe]
I0327 08:32:00.997397    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 15 txs in 23.39737ms. #1227186 [b7e8bcb0 / b7e8bcb0]
I0327 08:32:16.978882    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 6 txs in 12.076068ms. #1227187 [34693745 / 34693745]
I0327 08:32:49.560106    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 6 txs in 116.734689ms. #1227188 [45550e8b / 45550e8b]
I0327 08:33:20.526587    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 13 txs in 26.303391ms. #1227189 [a0f87402 / a0f87402]
I0327 08:33:36.444646    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 22 txs in 46.736795ms. #1227190 [e411bc25 / e411bc25]
I0327 08:34:27.710431    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 14 txs in 33.357254ms. #1227191 [75f7af92 / 75f7af92]
I0327 08:36:18.152791    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 1 txs in 9.01289ms. #1227192 [0b3745c2 / 0b3745c2]
I0327 08:36:19.238321    3507 queue.go:331] Header #1227195 [9c906fe4] broke chain ordering, expected 1227193
I0327 08:36:20.275236    3507 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 40 txs in 2.117191233s. #1227193 [16db41e5 / 16db41e5]

[OmniEdge]

Console update:

[taoteh1221]

Same exact error on 2 different machines, same Ubuntu / Mist versions. Both are semi decent quad core CPUs with 4GB RAM. Disk drive is also running for over a hour at 100%, HDD light never stops the entire time. No issues at all on 8 core / 8GB machine with same Ubuntu / Mist versions.

[taoteh1221]

Almost forgot: only 1.1GB RAM used out of 3.9GB, so HDD Light was definitely _NOT_ swap space usage.

[taoteh1221]

Same issues on Win 10 with the same slow machine (no hard drive heavy I/O issue though), fast machine is fine.

[azulmarino]

same here Mac OS X El Capitan , update 10.11.5 Beta (15F18c) installed today
instance: Geth/v1.3.5/darwin/go1.6
mist 0.6.2

Worked prior to update.

....go:1251] imported 1 block(s) (0 queued 0 ignored) including 51 txs in 394.246002ms. #1323433 [8b53b882 / 8b53b882]
I0412 16:11:24.745759     699 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 5 txs in 22.968726ms. #1323434 [99b573ca / 99b573ca]
I0412 16:12:54.836852     699 queue.go:331] Header #1323441 [061d71fc] broke chain ordering, expected 1323447
I0412 16:12:55.160755     699 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 15 txs in 381.52267ms. #1323435 [d8cbb53a / d8cbb53a]
I0412 16:12:55.575936     699 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 4 txs in 408.594804ms. #1323436 [a550be95 / a550be95]
I0412 16:12:55.932137     699 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 5 txs in 351.687766ms. #1323434 [83bd2f19 / 83bd2f19]
I0412 16:12:56.045645     699 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 3 txs in 112.276906ms. #1323436 [26528c2e / 26528c2e]

CONSOLE
---------------
Failed to load resource: net::ERR_FILE_NOT_FOUND

de099c7….js:289 Logs of Token Unicorns couldn't be received Error: CONNECTION ERROR: Couldn't connect to node on IPC.
    at Object.module.exports.InvalidConnection (/Users/Dean/Ethereum-Wallet-macosx-0-6-2/Ethereum-Wallet.app/Contents/Resources/app.asar/node_modules/web3/lib/web3/errors.js:28:16)
    at IpcProvider._timeout (/Users/Dean/Ethereum-Wallet-macosx-0-6-2/Ethereum-Wallet.app/Contents/Resources/app.asar/node_modules/web3/lib/web3/ipcprovider.js:172:48)
    at /Users/Dean/Ethereum-Wallet-macosx-0-6-2/Ethereum-Wallet.app/Contents/Resources/app.asar/node_modules/web3/lib/web3/ipcprovider.js:83:15
    at EventEmitter.<anonymous> (/Users/Dean/Ethereum-Wallet-macosx-0-6-2/Ethereum-Wallet.app/Contents/Resources/app.asar/modules/ipc/ipcProviderWrapper.js:51:13)
    at emitTwo (events.js:87:13)
    at EventEmitter.emit (events.js:172:7)

[azulmarino]

any update ?

[frozeman]

Hi.

Sore for answering late. I'm beeing traveling right now.
The fist screens seem fine. The second ones it looks like it looses the nodes ipc connection to mist.

We are aware of the sync issues, but this shouldn't result in ipc connection issues.

@bas-vk and @fjl any idea?

Concerning the ipc I assume some request is leading to a canceled socket and I might not reconnect correctly.

Concerning the sync. It need to be fixed in geth itself.

[frozeman]

It says ipc error connectreset? Any idea bas? I'm. Urgently only on my phone can't really check.

[bas-vk]

There are several reasons why the node drops the connection. Since @taoteh1221 mentioned that this is not occurring on faster machines and @JRogiest said a restart of mist works (temporary) it might be a timeout related issue. If geth doesn't get a new request within 1 minute it will drop the connection. Normally this should not happen, but maybe on slower machines which are synchronizing it can happen.

Mist should reconnect and resume operations as normal when this happens.

From geth 1.4 the whole RPC backend is re-implemented. Important changes:

• no timeout for the IPC channel
• improved logging which can help trace down the issue
• uses a different IPC package on Windows (made bij Microsoft guys)

[frozeman]

Thanks for the response. I will soon upgrade to geth 1.4 once we released it.

Though i will look into why its hanging the socket sometimes.

[taoteh1221]

@bas-vk @frozeman I thought of, and did a quick test to see if it would fix this issue on at least my fast Windows machine (which would not sync well at all in recent Mist builds, but synced fine before, months ago). I deleted all mist / ethereum user files from my user directory, except for my keystores, and it seems to have fixed the issue...I finally stayed in sync on mainnet fine. I think _maybe_ it correlates to fast sync on a blockchain database that was not originally fast-synced from the genesis block (geth been on that machine syncing for many months before these recent Mist builds). Just a correlation to ponder over, if you all get any more issues reported like this. I will test on my laptop on Linux next (including before / after Mist upgrade to latest), and report back.

[radekradekradek]

I have a similar sync issue with my Mist wallet, but with a twist....

After Mist opens up, I don't see any peers connected and the block number doesn't change but when i go to view the log, it says it's keeping up with new blocks:

Is Mist really connected to peers and not just showing up on the UI?

If it is synced, I'm not able to transact between accounts through the UI.

Thanks in advance for any comments/help,
radek^3

[taoteh1221]

Ubuntu 14.04 LTS / Mist v0.7.2 even on my 8 core / 8GB RAM machine is choking now, disk drive running a TON of heavy I/O non-stop for 20/30/40 minutes or more. Geth even does this by itself CLI, not sure Mist is to blame, but here are the wallet UI logs anyway:

Failed to load resource: net::ERR_FILE_NOT_FOUND
Connect to node...
EVENT LOG: Checking Deposits and ConfirmationNeeded for XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (_id: XXXXXXXXXXX) from block # XXXXX
EVENT LOG: Checking Custom Contract Events for XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (_id: XXXXXXXXXXX) from block # XXXXX
EVENT LOG: Checking Custom Contract Events for XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (_id: XXXXXXXXXXX) from block # XXXXX
IPC Connection Error Object {code: "ECONNRESET", errno: "ECONNRESET", syscall: "read"}
Logs of Token DAO couldn't be received Error: CONNECTION ERROR: Couldn't connect to node on IPC.(…)
Logs of Token Unicorns couldn't be received Error: CONNECTION ERROR: Couldn't connect to node on IPC.(…)

[taoteh1221]

Follow up: switching to testnet, then back to livenet calmed things down...hard drive stopped doing endless I/O and blockchain finally stayed in sync. Odd.

[OmniEdge]

@taoteh1221 Did you quickly go to the test net and back or did you also have to download the testnet blockchain?

[taoteh1221]

@jRogiest Just a quick switch back and forth, did not fully sync testnet before switching back to mainnet.

[luclu]

Please try to run geth 1.4 in the background until Ethereum-Wallet 0.7.3 (edit: 0.7.4) (bundling newer geth) is released.

Similar issue report: https://github.com/ethereum/mist/issues/558

[jskvbinmv]

I'm having the same issue as @radekradekradek . Blocks seem to get updated, but don't show up in Mist.

I also have trouble finding peers but I get some 1-3 eventually.

Ubuntu 15.10 64bit, Mist 0.7.2, geth 1.4.3

[taoteh1221]

@jskvbinmv It looks like geth (the under-the-hood p2p node software bundled with Mist) is responsible, see my screenshot in this stackexchange question: http://ethereum.stackexchange.com/questions/3789/any-idea-why-geth-1-4-1-rc-4b9de75-is-such-heavy-disk-i-o-at-startup

Slower computers, or computers with a normal hard drive (_not_ an SSD drive) may take 30-40 or more minutes to have geth 'chill out' on the heavy disk drive input / output _even after the blockchain is fully synced_...then Mist may be able to connect to geth successfully and run properly.

[jskvbinmv]

@taoteh1221 Thanks for your reply. I left it running the whole night and now again for some hours but still the same.

[taoteh1221]

@jskvbinmv It looks like they just released v0.7.3 with some sync / timeout fixes, maybe that will help your issues: https://github.com/ethereum/mist/releases

[taoteh1221]

One last update by myself to this thread: I got Mist (latest v0.7.3) to finally stay in sync with the bundled version of geth it includes, _ON A SLOWER MACHINE_. I did this by removing all 'watch token' items and removing all 'watch contract' items, then switching quickly to testnet and back to mainnet. This _includes removing ALL unicorn token related stuff_ (which I believe are bundled in latest Mist versions). I still had issues _UNTIL AFTER_ I did that unicorn token removal. So the watch contract / token stuff heavily correlates to massive disk I/O in geth it seems to me, which in turn seems to break the the connection to Mist (as geth still syncs in background but does not reflect this in the Mist UI). Done all I thought to try now, glad something worked on my lower end laptop finally. Good luck to all resolving these IO issues.

[michaelc2000]

Same issue, i think.

Mac OS X El Capitan , update 10.11.4.
MBPr 15 (i7 2.3GHz - late 2013).
Started with 0.7.2 UI, which initially worked fine. Stayed in sync and i could send successfully.

Then i created a watch token and a watch contract item. Problems began. Sync's when i start up the UI, but then stalls once the UI opens. Upgraded the UI to 0.7.3. No difference. Still not sync'ing after opening.

I thought it might be a block chain corruption issue, so i deleted the blockchain and now rebuilding it from scratch. Halfway there after 1.5 hours.

Just saw @taoteh1221 advice...and will delete my token & contract once the UI starts.

[taoteh1221]

@michaelc2000 I forgot to mention, try deleting any wallet contracts too (all you need to backup is the address). It seems Mist and geth are currently too high on disk I/O usage when getting token / contract information on any mid to low range PC / Mac. Only really high end hardware (8+ core / thread or SSD drive, etc) seems to handle watching tokens / contracts, at least on v0.7.3. Mist v0.7.4 was just released which may help, as they dropped having a timeout on Mist's geth connection. Good luck.

[michaelc2000]

What a headache..... hopefully now resolved.

After the blockchain rebuilt and state sync'ed (0.7.3), i exited and upgraded to 0.7.4. I believe this has geth 1.4, which works a little better and resolves some issues. I also deleted my tokens and custom contract. No watch contracts or tokens left.

Anyway....it still did not work. Would not sync after opening UI. I then tried to send some ETH. This worked and seem to prompt sync'ing. It has continued to sync, all be it slowly. I notice i now have a lot more established peers (9). Previously, with this issue, i would have between 1 & 3 peers.

Thanks all for assistance.

[michaelc2000]

Mac OS X El Capitan , update 10.11.4.
MBPr 15 (i7 2.3GHz - late 2013).
Mist UI: 0.7.4

I got cheeky.

Tried to create a watch token for DAO. Bad move. User cpu went up from 3.4% to 13%....and you guessed it, sync'ing stopped within the UI. Removed the watch token....cpu still 13%. Shutdown Ethereum wallet and then restarted......Sync'ed and then kept sync'ing within the UI. User cpu 3.5%, system 2.85%.

Good to see the UI updates coming thru fast. Look forward to a new one. I would like to create a contract and maybe a watch token.

Probably time for me to install/work out how to use the console.....

[joelcan]

I'm very interested in the resolution of this issue. I own some DAO tokens but I can't do anything with them because Mist doesn't work on Ubuntu.
Are there any workarounds? How do we interact with The DAO from geth?

[taoteh1221]

@joelcan An 8 core / 8 thread CPU or higher and SSD drive should make the Mist wallet usable for contract / subtoken features, until they fix the performance issues.

[taoteh1221]

A quick post to everyone in this issue thread: I think I finally figured out what is going on here with this Mist syncing issue. Seems that if you are using a contract-based wallet or are watching ANY contracts / tokens, and you do not have an SSD hard drive Mist will fall out of sync while geth is busy scanning the blockchain for contract / token updates. See this Reddit thread here, a slower machine syncs fine with an SSD hard drive, even watching TheDAO contract: https://www.reddit.com/r/ethereum/comments/4kkxfp/for_those_having_issues_with_windows_syncing_im/

[phonikg]

...So then really what you meant to say was that dragonfrugal @bobsummerwill and I finally figured it out;) If there is any further testing that can confirm/deny/test this further for the dev's I am willing to help.

Same system as in reddit thread, 2 days later, and geth only using 7-30% CPU(as per top)

[taoteh1221]

@phonikg I am dragonfrugal, just use my biz name on Reddit instead of taoteh1221 :) Thanks very much for chatting with me on Reddit, I have a Sandisk x400 SSD arriving today for my lower end laptop...will post results here after installing.

[phonikg]

@taoteh1221perfect...and thanks for recognizing that I was just having some fun with you, there is always the risk that that may not be conveyed via text-only communication. Also... Great effort here in providing other details of the issue thus far!

[taoteh1221]

@phonikg Lol, you got me. :smile: Thanks for the compliments. Will be cloning my HDD to SSD tomorrow (waiting on a USB 3.0 external case to do disk-to-disk with clonezilla), will post results of watching contracts in Mist afterwards to this thread. Hopefully it remedies the issue as expected, although Mist Wallet v0.7.4 does at least re-sync immediately with geth when sending a transaction which solves half the issue. I think they removed a timeout on IPC in geth v1.4.x that may have fixed that, but not 100% sure.

[taoteh1221]

Can confirm cloning my hard drive over to an SSD drive in my laptop solved my out of sync issues quite nicely. Horray. :+1: :smile: Many thanks to @phonikg .

[phonikg]

Good to hear @taoteh1221 !! ...hopefully this contributes some ideas regarding this issue to the Dev's. Or maybe they were already aware...

[taoteh1221]

@phonikg Or at least keeps them from having to answer to a lot of issue threads like this until they workout the heavy disk I/O watching contracts / tokens. It's a decent workaround.

[ScrambleKid]

Hi Guys

I'm running SSD on my MacBook Pro and having the same / similar issue. I have DAO on a wallet contract and not feeling confident about backing it up (my first attempt to restore on another user account failed).

I've tried everything in this thread (except for deleting wallet contracts because I am not confident about restoring them), but still have major sync and usage problems with 0.7.4.

Pretty new to this all. I guess a first step would be reliable backups (I have my Mist and keystore directories backed up, but restoring them elsewhere failed).

[taoteh1221]

@ScrambleKid Backup your keystores again if the backup failed. You may possibly have a corrupt backup.

[ScrambleKid]

Thanks for the suggestion. I've managed to import keys into MyEtherWallet - so keystores aren't corrupt. But Mist seems to be completely b0rked. I think I need to wait for the next version with geth 1.4.6 for bigger loads. At least I've managed to move my DAO tokens and wallet contract balances out of there for now. Have to move quickly - Mist becomes completely unusable after a minute or two (slowdown). I'm also still missing transactions from some wallet contracts, which I hope is just a temporary sync issue. Luckily not large amounts.

[taoteh1221]

@ScrambleKid Yeh, it's a pre-release ATM, so Mist can actually get slightly buggier as new larger features are added...to be expected. The freezing could easily be memory leaks, those have been reported a lot by others so I suspect that may be fixed relatively soon (I don't know, I'm not an ethdev team member).

I'd report the keystore import issue if I were you, or add your 2 cents to any related open issues...sounds like you may have found a real bug in the Mac release. They look at that stuff when patching things up, it could help them fix it.

[ScrambleKid]

@taoteh1221 I definitely will do. Thanks again for the replies.

[taoteh1221]

@ScrambleKid Your welcome! :)

[chevdor]

Still running into this issue on OSX (i7, 16 GB, fusion drive).

Mist 0.8.2
Geth 1.4.10-stable-5f55d95a

I previously did not have this issue. I just did a 'geth removedb' and a full resync without any improvement.

I noticed that I have less than 1 minute after I start Mist to pass a transaction, passed that time, everything hangs and no more blocks make it to Mist. Same issue wether I run geth 'automagically' from Mist or manually.

[chevdor]

Following some of the comments, I unwatched all the token (2) I had => no improvement
I also unwatched the DAO contract => no improvement.
Mist fetches the blocks at startup, then nothing anymore although I see geth getting new blocks.

[luclu]

@chevdor please double check that you don't have any heavy watched contract. Use 0.6.2 as a last resort to clean those.
Please also try to backup the ~/Library/Application Support/Mist folder and recheck if you still encounter this behaviour.

[chevdor]

Thank you @luclu for getting back to me.
I took some time to look into the issue. Here are my tests.

I did have a few contract and token I watched before but as I mentioned above, even removing them does not improve.

By "~/Library/Application Support/Mist", you mean backup and empty I suppose?

I tried running:
mv "~/Library/Application Support/Mist" "~/Library/Application Support/Mist_old"
and started Mist
=> with no effect beside 'forgetting' my accounts names and the wallet contracts.

The result is always similar: when Mist starts, after a little while, the last blocks are fetched. Once done, no more block comes in, no matter how long I wait. If I kill Mist and start again, it fetches again the last blocks and hangs once done.

I noticed however that when I start geth manually prior to starting Mist, things look much better.
When I start geth manually, it uses:
geth Version: 1.4.10-stable-5f55d95a

I see that Mist spins up another version of geth:
Version: 1.4.10-stable

I tested the following:

geth --rpc
start Mist

=> WORKS

mv "/Applications/Mist\ 0.8.2.app/Contents/Frameworks/node/geth/geth" "/Applications/Mist\ 0.8.2.app/Contents/Frameworks/node/geth/geth_ori"
ln -s `which geth` geth
geth --rpc
start Mist

=> FAIL

I also tested running geth manually but using the version shipped with Mist:

./geth_ori --rpc
start Mist

=> FAIL

Starting geth as (I am a lucky random winner of the jitvm=true):
./geth_ori --rpc --jitvm=false console
=> FAIL

New test with geth started prior to Mist (geth --rpc)
=> WORKS

[chevdor]

I also tried copying geth 1.4.10-stable-5f55d95a and replace the geth shipped with Mist.
Then I started Mist
=> FAIL

So far, the only way to get things running fine is to start geth manually as described above and then to start Mist.

[lock[bot]]

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.