I have a docker-compose.yml file that runs a shell script, and has been functioning fine, until all of a sudden it started failing with:
ERROR: for pol_app_1 Cannot start service app: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"run.sh\": executable file not found in $PATH": unknown
ERROR: for app Cannot start service app: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"run.sh\": executable file not found in $PATH": unknown
(I have seen similar questions, but they don't address this specific problem)
The only changes I have been making are to the docker images it uses, but even if I change the image to simply centos:latest docker-compose still fails with the errors above.
My docker-compose.yml file:
version: '3.5'
services:
app:
image: paulhollyer/phoenix:1.4.9
ports:
- 4000:4000
volumes:
- .:/app
depends_on:
- db
command: run.sh
db:
image: paulhollyer/postgres:12
command: 'postgres -c "max_connections=200"'
volumes:
- type: volume
source: postgres-data
target: /var/lib/postgresql/data
volume:
nocopy: true
restart: always
environment:
POSTGRES_PASSWORD: "postgres"
POSTGRES_USER: "postgres"
POSTGRES_DB: "pol_dev"
volumes:
postgres-data:
run.sh is next to docker-compose.yml in the root of the project.
Does anyone know why run.sh can't be found? What could I have done unintentionally to cause this?
Thanks
You must refer to it according to the location it has inside the container. Since the file is in your current host directory and you are adding a volume .:/app that would be /app/run.sh:
command: /app/run.sh
Note to avoid weird problems: If /app happens to be the WORKDIR of the pulled image, command: ./run.sh would also work, but be careful with that. For instance, if that's the case, chances are that /app already has some files in there, and your mapping would be mounting your current host directory on top of them, making them inaccessible.
Related
Dockerfile:
FROM hseeberger/scala-sbt:8u222_1.3.5_2.13.1
WORKDIR /code/SimpleStocks
COPY ./SimpleStocks .
RUN sbt dist
WORKDIR /code/SimpleStocks/target/universal
RUN unzip simplestocks-0.0.1.zip
WORKDIR /code/SimpleStocks/target/universal/simplestocks-0.0.1
CMD ["bin/simplestocks"]
docker-compose.yml:
version: "3.7"
services:
app:
container_name: simple-stocks
image: simple-stocks:1.0.0
build: .
ports:
- '9000:9000'
volumes:
- .:/code
links:
- pgdb1
pgdb1:
image: postgres
environment:
POSTGRES_DB: simple_stocks
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
volumes:
- pgdb1data:/var/lib/postgresql/data/
- ./docker_postgres_init.sql:/docker-entrypoint-initdb.d/docker_postgres_init.sql
ports:
- '5432:5432'
volumes:
pgdb1data:
When I manually run simple-stocks container using docker run -it {imageId}, I am able to run it successfully; but, on doing docker compose up I am receiving:
Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused: exec:
"bin/simplestocks": stat bin/simplestocks: no such file or directory:
unknown
Your Dockerfile is building the application in /code/SimpleStocks/target/universal/simplestocks-0.0.1, but then your Compose file bind-mounts a host directory over /code, which hides everything the Dockerfile does. The bind mount is unnecessary and deleting it will resolve this issue.
Bind-mounting a host directory over your entire built application usually is not a best practice. I most often see it trying to convince Docker to emulate a local development environment, but even that approach doesn't make sense for a compiled language like Scala.
You can safely remove the volumes: block. The obsolete links: can also be removed. You don't need to manually specify container_name:, nor do you need to specify both build: and image: unless you're planning to push the built image to a registry. That would reduce the Compose setup to just:
version: '3.8'
services:
app:
build: .
ports:
- '9000:9000'
pgdb1: (as in the question originally)
volumes:
pgdb1data:
I'm trying to use wait-for-it in my docker-compose.yaml to wait for mysql to be ready before creating services that are dependent on it. This is my docker-compose.yaml:
version: '3.5'
services:
mysql:
image: mysql:5.6
ports:
- "3307:3306"
networks:
- integration-tests
environment:
- MYSQL_DATABASE=mydb
- MYSQL_USER=root
- MYSQL_ROOT_PASSWORD=mypassword
entrypoint: ./wait-for-it.sh mysql:3306
networks:
integration-tests:
name: integration-tests
I get this error when trying to run this with docker-compose:
Starting integration-tests_mysql_1 ... error
ERROR: for integration-tests_mysql_1 Cannot start service mysql: OCI
runtime create failed: container_linux.go:348: starting container
process caused "exec: \"./wait-for-it.sh\": stat ./wait-for-it.sh: no
such file or directory": unknown
ERROR: for mysql Cannot start service mysql: OCI runtime create
failed: container_linux.go:348: starting container process caused
"exec: \"./wait-for-it.sh\": stat ./wait-for-it.sh: no such file or
directory": unknown ERROR: Encountered errors while bringing up the
project.
The wait-for-it.sh script is there on the same level as my docker-compose.yaml file so I don't understand why it's not being found.
Your issue here is that you're trying to execute something that is not part of your image. You're telling docker to create a container from mysql:5.6, which doesn't contain wait-for-it.sh, and then you're telling it to start the container by launching wait-for-it.sh.
I would recommend that you create your own image containing the following:
#Dockerfile
FROM mysql:5.6
COPY wait-for-it.sh /wait-for-it.sh
RUN chmod +x /wait-for-it.sh
Then you would replace mysql:5.6 with your image and you should be able to execute wait-for-it.sh. I would also execute it through a command instead of an entrypoint as such:
#docker-compose.yml
...
mysql:
image: yourmysql:5.6
command: bash -c "/wait-for-it.sh -t 0 mysql:3306"
...
Where -t 0 will wait for mysql without a timeout.
You can control services startup order by using the docker depends_on option.
I have a Dockerfile which I can successfully build an image from:
FROM iron/go:dev
RUN mkdir /app
COPY src/main/main.go /app/.
# Set an env var that matches your github repo name, replace treeder/dockergo here with your repo name
ENV SRC_DIR=/app
# Add the source code:
ADD . $SRC_DIR
# Build it:
RUN go get goji.io
RUN go get gopkg.in/mgo.v2
RUN cd $SRC_DIR; go build -o main
ENTRYPOINT ["/app/main"]
However, when I attempt to build the following docker-compose.yml file:
version: "3.3"
services:
api:
build: ./api
expose:
- '8080'
container_name: 'api'
ports:
- "8082:8080"
depends_on:
- db
networks:
- api-net
db:
build: ./db
expose:
- '27017'
container_name: 'mongo'
ports:
- "27017:27017"
networks:
- api-net
networks:
api-net:
driver: bridge
I get:
Removing api mongo is up-to-date Recreating
532e3cf66460_carsupermarket_api_1 ... error
ERROR: for 532e3cf66460_carsupermarket_api_1 Cannot start service
api: OCI runtime create failed: container_linux.go:348: starting
container process caused "exec: \"/GO/src/main\": stat /GO/src/main:
no such file or directory": unknown
ERROR: for api Cannot start service api: OCI runtime create failed:
container_linux.go:348: starting container process caused "exec:
\"/GO/src/main\": stat /GO/src/main: no such file or directory":
unknown ERROR: Encountered errors while bringing up the project.
I suspect that docker-compose is introducing some nuance when it comes to directory build paths, however, I'm at a loss as to why my image is building from the docker file when using docker build ., but failing when I try to incorporate this into docker-compose.
Can someone point me in the right direction as to what I am doing wrong?
I've upgraded to the latest version of Docker CE (18.03.1-ce, build 9ee9f40) and this appears to have resolved the issue.
I am having a funny error when I try to run a docker-compose. I have reinstall the VM several times, everything is update and install but I cannot run a compose.
$ sudo docker-compose up -d
Creating network "apache2_default" with the default driver
Building mysql
ERROR: Error processing tar file(exit status 1): permission denied
My docker-composer.yml file:
version: '2'
services:
mysql:
build: ./mysql
environment:
MYSQL_ROOT_PASSWORD: pass
volumes:
- db:/var/lib/mysql
php:
build: ./php
ports:
- '80:80'
volumes:
- ./html:/var/www/html
depends_on:
- mysql
volumes:
db:
I have run this in Mac and it works
Edit:
Dockerfile fot mysql:
FROM mysql:5.7
COPY ./my.cnf /etc/mysql/conf.d/
The docker build build command can fail with permission error when there are files (or folders) in the build context directory which aren't owned by the current user.
This situation happens when you mount a volume to a host directory ; the files in that directory might be owned by root.
The fix is quite easy: just create a .dockerignore file with the name of the directories/files you don't own and don't require in the docker image build.
For instance:
docker run -d -v $(pwd)/data-volume:/var/lib/mysql mysql
would create a data-volume directory.
If you were to build a Dockerfile, you would have the following content in your .dockerignore:
data-volume
I modified the docker-compose.yml file as given on https://hub.docker.com/_/solr/ by adding a volumes configuration and a change in entrypoint. The modified file is as given:
version: '3'
services:
solr:
image: solr
ports:
- "8983:8983"
volumes:
- ./solr/init.sh:/init.sh
- ./solr/data:/opt/solr/server/solr/mycores
entrypoint:
- init.sh
- docker-entrypoint.sh
- solr-precreate
- mycore
I need to run this 'init.sh' before entrypoint starts, to prepare my files inside container.
But I get following errors:
ERROR: for solr_solr_1 Cannot start service solr: oci runtime error:
container_linux.go:247: starting container process caused "exec:
\"init.sh\": executable file not found in $PATH"
Earlier I found about official image hooks in neo4j from here. Is there a similar thing I can use here also?
Update 1: From comments below, I realized that dockerfile set WORKDIR /opt/solr due to which executable file not found in $PATH. So I tested by providing the absolute path to entrypoint by using /init.sh. But this also gives error, but a different one:
standard_init_linux.go:178: exec user process caused "exec format
error"
It looks like you need to map your volume to /docker-entrypoint-initdb.d/
version: '3'
services:
solr:
image: solr
ports:
- "8983:8983"
volumes:
- ./solr/init.sh:/docker-entrypoint-initdb.d/init.sh
- ./solr/data:/opt/solr/server/solr/mycores
entrypoint:
- docker-entrypoint.sh
- init
From
https://hub.docker.com/_/solr/
Extending the image The docker-solr image has an extension mechanism. At run time, before starting Solr, the container will
execute scripts in the /docker-entrypoint-initdb.d/ directory. You can
add your own scripts there either by using mounted volumes or by using
a custom Dockerfile. These scripts can for example copy a core
directory with pre-loaded data for continuous integration testing, or
modify the Solr configuration.
The docker-entrypoint.sh seems to be responsible for running the sh scripts based on the arguments passed to it. So init is the first argument which in turn tries to run init.sh
docker-compose logs solr | head
Update 1:
I had struggled to get this to work and finally figured out why my docker-compose was not working while the docker run -v pointing to the /docker-entrypoint-initdb.d/init.sh was working.
It turns out that removing the entrypoint tree was the solution. Here's my final docker-compose:
version: '3'
services:
solr:
image: solr:6.6-alpine
ports:
- "8983:8983"
volumes:
- ./solr/data/:/opt/solr/server/solr/
- ./solr/config/init.sh:/docker-entrypoint-initdb.d/init.sh
my ./solr/config/init.sh
#!/bin/bash
echo "running"
touch /opt/solr/server/solr/test.txt;
echo "test" > /opt/solr/server/solr/test.txt;
An alternative solution that worked for me was modifying entrypoint by placing /bin/sh.It looked a bit like this afterwards
version: '3'
services:
web:
build: .
volumes:
- .:/code
entrypoint :
- /bin/sh
- ./test.sh
ports:
- "5000:5000
where test.sh is the required bash script to be run inside the container.