I cannot believe it was that easy.
My previous experience with Docker was terrible - error upon error, some configuration issues. I guess it was on the application level, not Docker level.
This time around - it just works! EOS running in 2 lines of code: https://developers.eos.io/eosio-nodeos/docs/docker-quickstart
Pull the image from the repository:
I've compiled and run it without any problems on Ubuntu 18.04, which is great because it's an LTS. We're asking for an DEB package (see https://github.com/EOSIO/eos/issues/1021) to make it easier to install. It's planed to be supported in the near future.
I've been using Docker lately for several reasons.
Easier than a VM by just running a couple of commands
I can segregate my host node, keosd and cleos node on 3 different instances in 3 seconds.
Starting from scratch is a matter of rebooting.
Debugging or sending my environment to another person might prove useful than working out how to cart ...
Nodeos requires that it is shutdown cleanly. Make sure you allow enough time for the state to be written to disk. On a big blockchain with a slow disk, shutdown could take a minute or more.
If you don't shutdown cleanly, then you will need to replay the chain from scratch to rebuild the state or or use a previously saved state snapshot file. More details ...
You can specify the path where wallets are stored in the keosd-config.ini in ~/eosio-wallet/config.ini permanently. If you do, keosd will always try to find the wallet-files in this directory.
# The path of the wallet files (absolute path or relative to application data d$
wallet-dir = "path-to-wallet-files"
To use the modified configuration you ...
You can't access mongodb from smart contract at all. It is executed in closed and segregated context and can't communicate with external network except for internal state. Internal state here means data stored by eosio::multi_index.
Once transaction is recorded, you can make a monitoring daemon to read it from block and do something for your demand like ...
For the first issue, you could be exceeding the maximum CPU usage time allowed for a transaction. You can see below where this is hard coded:
const static uint32_t default_max_block_cpu_usage = 200'000; /// max block cpu usage in microseconds
const static uint32_t default_target_block_cpu_usage_pct = 10 * percent_1;
[Solved] You can find the correct config.ini file from the developers portal. (I was altering the wrong config.ini file earlier.)
In the .local/share/eosio/nodeos/config/config.ini file, commenting out the unlock-timeout and wallet-dir settings fixed the problem.
I was able to solve it by
~/scripts $ sudo service docker stop
[sudo] password for user:
~/scripts $ sudo service docker start
~/scripts $ ./docker_init.sh
docker: Error response from daemon: Conflict. The container name "/eosio" is already in use by container "a449dc043cd46b79775c239fc2c356637c888c704a4cf11299ae0d605d5a34b1". You have to remove (or ...
./eosio_build.sh # no sudo for build
I had similar problems with WSL 16.04.
Using the 18.04 image brought up better results.
Note that I finally did not manage to stabilize the eos-tests on WSL, and switched to a VirtualBox 18.04.
WSL is currently unsupported by the team.
Used Thomas5577's instructions but created an opt directory in /usr/ and then a boost directory within opt. Then I installed the boost library, but I changed the bootstrap setup command to ./bootstrap.sh --prefix=/usr/opt/boost, and the eosio build worked.
You will probably be better off installing boot manually. That is what I had to do https://www.boost.org/:
Install the required packages
sudo apt-get update
sudo apt-get install build-essential g++ python-dev autotools-dev libicu-dev build-essential libbz2-dev
Install the Boost libraries
wget -O boost.tar.gz https://dl.bintray.com/boostorg/release/1.67....