Ctrl+C on Ubuntu 14.04 LTS doesn't kill geth, geth takes massive amounts of CPU

[VoR0220]

@iurimatias I've already made this issue clear via Gitter, but I want to see if there would be other people willing to help tackle this.

This happens after I try to end the session following a embark blockchain command. It kills geth in the shell, however, geth is not dead and lives. PIDs show that it takes up to 50% of CPU resources. Prior to this, the automatic miner works just as you would expect. It's kind of an annoyance having to go into the task manager and seek out and kill geth, so any and all help in solving this is greatly appreciated. Much thanks guys.

[tom-seddon]

I've got this problem too. I'm using Vagrant to set up a VM to run this stuff. See: https://gist.github.com/tom-seddon/407df5a095043a954448 (for OS X - tweak the vb.cpus setting if running on Linux/Windows)

You can reproduce it by setting up the above VM then doing something like:

cd ~
embark demo
cd embark_demo
embark blockchain run

then once it's done the building DAG, and mined a couple of blocks, and decided to stop (since the default is the mine-on-demand mode), press Ctrl+C. Then use top or pidof geth to note that geth is still running.

The fix I've found seems to be to set mine_when_needed: false in blockchain.yml. Obviously this disables mining on demand, but at least it works.

When geth does get stuck, you can attach remotely with something like geth attach ipc:/tmp/embark/geth.ipc, type web3, then exit with Ctrl+D. Then both copies shut down. I can only assume something gets in some funny state somewhere.

--Tom

[tom-seddon]

Another option might be to clone https://github.com/jesuscript/vagrant-dapp-env and replace its setup.yml with this very similar one that just specifies versions for a few components: https://gist.github.com/tom-seddon/0dd45250f95121451229

(I decided which versions to use in both these cases by running a VM that does work - vagrant-dapp-env, but built a couple of weeks ago - noting version numbers for geth and solc, and then installing packages on a new VM until I found ones that installed versions of geth and solc that purported to be the same version. Though I note that the geth I get today was supposedly built with go 1.5, whereas the one from 2 weeks ago was built with go 1.4.2.)

--Tom

[VoR0220]

Interesting thing I also discovered.

If you set console: true with mine_when_needed: false, then you will not only kill the mine_when_needed function (it mines constantly once that is activated), but you will also no longer get this error. I definitely think it has something to do with either console or mine_when_needed

[domschiener]

Having the same issue on #123 . Removing the /tmp/embark folder will make it possible to run embark blockchain. But obviously shutting down the geth leads to the same issues of geth being stuck at IPC Service Started.

Setting console: true in turns makes it impossible to start again as it will be stuck at IPC Service Started.

[iurimatias]

this was an issue with geth that has been fixed since then. as for the /tmp/ folder, embark 2.0 no longer uses that folder and shouldn't have the same issue