: No such file or directoryenv: node on docker

[jooshxp]

Running on windows with Docker Toolbox after : docker-compose build and docker-compose --file=docker-compose-windows.yml up this logs shown :

Starting zenbot_mongodb-data_1 ...
Starting zenbot_mongodb-data_1 ... done
Starting zenbot_mongodb_1 ...
Starting zenbot_mongodb_1 ... done
Starting zenbot_server_1 ...
Starting zenbot_server_1 ... done
Attaching to zenbot_mongodb-data_1, zenbot_mongodb_1, zenbot_server_1
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] MongoD
B starting : pid=1 port=27017 dbpath=/data/db 64-bit host=6f04527b4111
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] db ver
sion v3.4.6
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] git ve
rsion: c55eb86ef46ee7aede3b1e2a5d184a7df4bfb5b5
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] OpenSS
L version: OpenSSL 1.0.1t 3 May 2016
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] alloca
tor: tcmalloc
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] module
s: none
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] build
environment:
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] di
stmod: debian81
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] di
starch: x86_64
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] ta
rget_arch: x86_64
mongodb_1 | 2017-08-04T05:11:53.423+0000 I CONTROL [initandlisten] option
s: { storage: { mmapv1: { smallFiles: true } } }
zenbot_mongodb-data_1 exited with code 0
mongodb_1 | 2017-08-04T05:11:53.426+0000 I - [initandlisten] Detect
ed data files in /data/db created by the 'wiredTiger' storage engine, so setting
the active storage engine to 'wiredTiger'.
mongodb_1 | 2017-08-04T05:11:53.426+0000 I STORAGE [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.426+0000 I STORAGE [initandlisten] ** WAR
NING: Using the XFS filesystem is strongly recommended with the WiredTiger stora
ge engine
mongodb_1 | 2017-08-04T05:11:53.426+0000 I STORAGE [initandlisten] **
See http://dochub.mongodb.org/core/prodnotes-filesystem
mongodb_1 | 2017-08-04T05:11:53.426+0000 I STORAGE [initandlisten] wiredt
iger_open config: create,cache_size=256M,session_max=20000,eviction=(threads_min
=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=
true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),check
point=(wait=60,log_size=2GB),statistics_log=(wait=0),
mongodb_1 | 2017-08-04T05:11:53.647+0000 W STORAGE [initandlisten] Detect
ed configuration for non-active storage engine mmapv1 when current storage engin
e is wiredTiger
: No such file or directoryenv: node
mongodb_1 | 2017-08-04T05:11:53.647+0000 I CONTROL [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.647+0000 I CONTROL [initandlisten] ** WAR
NING: Access control is not enabled for the database.
mongodb_1 | 2017-08-04T05:11:53.647+0000 I CONTROL [initandlisten] **
Read and write access to data and configuration is unrestricted.
mongodb_1 | 2017-08-04T05:11:53.647+0000 I CONTROL [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten] ** WAR
NING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten] **
We suggest setting it to 'never'
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten] ** WAR
NING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten] **
We suggest setting it to 'never'
mongodb_1 | 2017-08-04T05:11:53.648+0000 I CONTROL [initandlisten]
mongodb_1 | 2017-08-04T05:11:53.650+0000 I FTDC [initandlisten] Initia
lizing full-time diagnostic data capture with directory '/data/db/diagnostic.dat
a'
zenbot_server_1 exited with code 127
: No such file or directoryenv: node

must runn mongodb first on cmd ? or what ?

[DeviaVir]

Are you using https://github.com/carlos8f/zenbot/blob/master/docker-compose-windows.yml ?

[jooshxp]

yes, already use that.

docker-compose --file=docker-compose-windows.yml up
and try
docker-compose up

same result.

[co-l]

Same here. Couldn't solve it. Switched to some linux VPS for playing around.

[cmroche]

@DeviaVir I'm getting this with docker-compose.yml and docker-compose-windows.yml. If I attach to the running docker container using /bin/sh and attempt to call the zenbot.sh script directly I get the same error. /bin/bash does not exibit the same problem. It looks like the path variables are not setup properly in the docker image. My solution locally has been to rename zenbot.sh back to zenbot.js and use a simple zenbot.sh script to wrap the call to node as this has been more consistent working in an out of windows. I can issue a push request to fix it once I'm done testing if you would like.

[bpringe]

I'm having the same issue trying to run on Windows 10 Pro with Docker. @cmroche I tried your solution but may have been doing something incorrectly with this step:

use a simple zenbot.sh script to wrap the call to node

What exactly should this script look like? I tried a few things with no success.

[cmroche]

My solution for the problem is to rename zenbot.sh to zenbot.js, remove the shebang at the top of the file, then I have two simple shell scripts to launch it based on os.

On windows, zenbot.bat which calls node zenbot.js %@

On osx, linux, zenbot.sh which calls env node zenbot.js $@

I also modified my Dockerfile to use neither, and just invoke node directly (since it is a well defined enironment the Dockerfile can be specific to the OS setup)

ENTRYPOINT ["/usr/local/bin/node", "zenbot.js"]
CMD [ "trade", "--paper" ]

[dextervip]

It looks like incorrect line ending style when cloning via windows. Open your sh files such zenbot.sh and check whats line ending style you are using. It should be unix line ending style and not windows style.

[bpringe]

@cmroche Thanks for the quick response. @dextervip I just tried your suggestion and it worked. My line endings after cloning were CRLF for zenbot.sh. I changed the line endings to LF for that file and re-ran docker-compose --file=docker-compose-windows.yml up and the server started successfully. Thanks! @JohnBerlin and @Newb1ez, this may work for you too.

[bpringe]

@cmroche Would it be a good idea to submit a PR to add a .gitattributes file to the repo to ensure the zenbot.sh file is always checked out with LF line endings? See here.

[cmroche]

Ok I've thought about this some. Honestly I don't like this as a solution since it prevent windows users from being able to modify the file without potentially causing more issues.

The use of a .sh file to bootstrap the bot is an inherently non-windows thing to do, even though this modification would allow docker builds to work it doesn't support development of this project in that environment.

My personal opinion is that we should rename it back to .js and use shell scripts to boostrap the launch when it is convenient for users, but not require it. All around I feel this is more robust.

But it isn't my call.

[DeviaVir]

@cmroche if that is the solution that works on both platforms, I don't see a reason not to use it. In that sense, it is your call :)