When I restart a container with docker-compose up with an entrypoint it's not stateless, it keep the context of the previous execution of the entrypoint.
docker-compose file:
version: '3.8'
services:
test:
image: debian:buster-slim
entrypoint: ["/entrypoint.sh"]
volumes:
- ./entrypoint.sh:/entrypoint.sh
command: ["echo", "100"]
entrypoint.sh file:
#!/bin/bash
set -e
set -x
mkdir folder
exec "$#"
the first time it log
Creating network "test_compose_entrypoint_default" with the default driver
Creating test_compose_entrypoint_test_1 ... done
Attaching to test_compose_entrypoint_test_1
test_1 | + mkdir folder
test_1 | + exec echo 100
test_1 | 100
if I rerun a docker-compose up , the second time it log
Starting test_compose_entrypoint_test_1 ... done
Attaching to test_compose_entrypoint_test_1
test_1 | + mkdir folder
test_1 | mkdir: cannot create directory 'folder': File exists
test_compose_entrypoint_test_1 exited with code 1
If I run docker-compose down and then it work again, but impossible to run two times in a row.
In fact, docker-compose restart tries re-running the main container process in the existing (stopped) container. docker-compose up will default to reusing an existing container, if one exists with the right configuration, even if it's stopped. This can be a problem for setups like what you show that have the reasonable expectation of starting in a clean environment.
One approach is to code defensively around the possibility of the directory already existing:
# Create `folder` only if it doesn't exist. Could still fail
# if the directory is read-only, or if `folder` is a plain file.
test -d folder || mkdir folder
At a higher level, you could docker-compose rm the existing container before re-launching it, or if you don't mind restarting everything, docker-compose up --force-recreate. This approach isn't compatible with an automatic restart: policy, though.
I have the following situation. I created a build in OpenShift:
oc new-build --strategy docker --binary --docker-image centos:centos7 --name myapp
And locally there is nothing fancy. I have a .war file and Dockerfile:
FROM registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift
COPY pdf-maker##1.2.war /opt/webserver/webapps/
COPY pdfmaker1.0.properties /opt/webserver/conf/
COPY fop.xconf /opt/webserver/_fop/conf/fop.xconf
COPY logo.gif /opt/webserver/_fop/img/
COPY PDF_Transformation.xslt /opt/webserver/_fop/transformation/
RUN mkdir -p /opt/webserver/fop
WORKDIR /opt/webserver
EXPOSE 8080
CMD ["/opt/webserver/bin/catalina.sh", "run"]
And I run the build like:
oc start-build myapp --from-dir . --follow
So far so good... but the application never starts in OpenShift. It says that: "Error: failed to start container "myapp": Error response from daemon: oci runtime error: container_linux.go:235: starting container process caused "exec: \"/opt/webserver/bin/catalina.sh\": stat /opt/webserver/bin/catalina.sh: no such file or directory" I tried to skip the CMD line but with no success. I am 100% the path is correct.
I have tried to build the Docker image from the Dockerfile locally and start it. Locally works as expected but in OpenShift - does not work. I am doing something wrong but I don't know what.
I would much appreciate if someone points me the problem.
SOLVED
It turned out I was relying on centos which was the culprit. The solution was to to use this:
oc new-build --strategy docker --binary --docker-image registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift --name sinergia-pdf-maker
I am new to docker, and follows the instructions at https://docs.docker.com/develop/develop-images/baseimages/ to create a docker image and tried to run:
My docker file is as follows:
FROM scratch
ADD hello.sh /
CMD ["/hello.sh"]
The hello.sh file is as follows. I have applied dos2unix to hello.sh to ensure the right encoding:
#!/bin/sh
echo "this is a test"
I followed the instruction in the doc to run the following command to build an image:
docker build --tag hello .
Then when I ran docker run --rm hello I got the following error:
[FATAL tini (8)] exec /hello.sh failed: No such file or directory
Have searched online and tried solutions from various posts. But none of them worked. Any insights on where I did wrong?
related non-helpful threads:
1. https://forums.docker.com/t/standard-init-linux-go-175-exec-user-process-caused-no-such-file/20025/4
Building an image from 'scratch' means your resulting container is just an empty filesystem. Especially being new to Docker, you should build from a small image like 'alpine' instead of 'scratch' then run your script using sh.
If you are set on building from scratch you will need to compile your own binary then add it as the ENTRYPOINT or CMD of the image Install Bash on scratch Docker image
docker documentation example on building from scratch https://docs.docker.com/develop/develop-images/baseimages/
End of my Dockerfile:
ENTRYPOINT ["ls /etc"]
Terminal:
...Rest of the building above is fine
Step 8/8 : ENTRYPOINT ["ls /etc"]
---> Using cache
---> ea1f33b8ab22
Successfully built ea1f33b8ab22
Successfully tagged redis:latest
k#Karls ~/dev/docker_redis (master) $ docker run -d -p 6379:6379 --name red redis
71d75058b94f088ef872b08a115bc12cece288b53fe26d67960fe139953ed5c4
docker: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "exec: \"ls /etc\": stat ls /etc: no such file or directory": unknown.
For some reason, it won't find the directory /etc. I did a pwd and the current working directory is /. I also did a ls / on the entrypoint and that displayed the /etc directory fine.
OCI runtime create failed: container_linux.go:296
In my experience this is an error with the docker daemon itself, not the container you are trying to run. Try deleting all containers, restarting the daemon. I think we also had to clean up the docker networks.
I appear to be having the same issue. Here is what I am doing.
Dockerfile
FROM gcc:7.2.0
COPY src/ /usr/src/myapp
WORKDIR /usr/src/myapp
RUN set -x gcc -o myapp main.c
CMD ["./myapp"]
Build
$ docker build -t test .
Sending build context to Docker daemon 3.584kB
Step 1/6 : FROM gcc:7.2.0
...
---> 3ec35c7d2396
Successfully built 3ec35c7d2396
Successfully tagged test:latest
SECURITY WARNING: You are building a Docker image from Windows against a
non-Windows Docker host. All files and directories added to build context
will have '-rwxr-xr-x' permissions. It is recommended to double check and
reset permissions for sensitive files and directories.
Run
$ docker run -it test
D:\Docker Toolbox\docker.exe: Error response from daemon: OCI runtime create
failed: container_linux.go:296: starting container process caused "exec:
\"./myapp\": stat ./myapp: no such file or directory": unknown.
Changed CMD to ENTRYPOINT and removed the set -x seemed to resolve the problem. Though we are still unsure what the cause was or if this will also work for you.
Make sure that /etc exists or is created as the main.c wasn't compiling.
Dockerfile
FROM gcc:7.2.0
COPY src/ /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -o myapp main.c
ENTRYPOINT ["./myapp"]
On OSX, I fixed it by clearing the volume data manually. Close docker, and remove everything in ~/Library/Containers/com.docker.docker
I've expirienced the same issue after updating my Windows credentials, try following: Docker settings > Shared Drives > Reset credentials > Select drives again > Apply and re-enter your credentials. This solved the problem for me multiple times
The command you are trying to execute inside the container does not exist. In this case ls /etc does not exist in the image. There's a /bin/ls binary, but not a /bin/"ls /etc" binary, which itself would be invalid since the name of a file on the filesystem cannot include a /, though it can include a space.
Of course what you wanted to run was ls with the argument /etc, and for that, you need to separate each argument if you run with the exec syntax.
ENTRYPOINT ["ls", "/etc"]
Or if you wanted to allow a shell to parse the string, same way as if you were at a bash prompt inside the container running ls /etc on the command line, then switch to the string syntax that runs a shell:
ENTRYPOINT ls /etc
I have a docker image which installs grunt, but when I try to run it, I get an error:
Error response from daemon: Cannot start container foo_1: \
exec: "grunt serve": executable file not found in $PATH
If I run bash in interactive mode, grunt is available.
What am I doing wrong?
Here is my Dockerfile:
# https://registry.hub.docker.com/u/dockerfile/nodejs/ (builds on ubuntu:14.04)
FROM dockerfile/nodejs
MAINTAINER My Name, me#email.com
ENV HOME /home/web
WORKDIR /home/web/site
RUN useradd web -d /home/web -s /bin/bash -m
RUN npm install -g grunt-cli
RUN npm install -g bower
RUN chown -R web:web /home/web
USER web
RUN git clone https://github.com/repo/site /home/web/site
RUN npm install
RUN bower install --config.interactive=false --allow-root
ENV NODE_ENV development
# Port 9000 for server
# Port 35729 for livereload
EXPOSE 9000 35729
CMD ["grunt"]
This was the first result on google when I pasted my error message, and it's because my arguments were out of order.
The container name has to be after all of the arguments.
Bad:
docker run <container_name> -v $(pwd):/src -it
Good:
docker run -v $(pwd):/src -it <container_name>
When you use the exec format for a command (e.g., CMD ["grunt"], a JSON array with double quotes), it will be executed without a shell. This means that most environment variables will not be present.
If you specify your command as a regular string (e.g. CMD grunt) then the string after CMD will be executed with /bin/sh -c.
More info on this is available in the CMD section of the Dockerfile reference.
I found the same problem. I did the following:
docker run -ti devops -v /tmp:/tmp /bin/bash
When I change it to
docker run -ti -v /tmp:/tmp devops /bin/bash
it works fine.
For some reason, I get that error unless I add the "bash" clarifier. Even adding "#!/bin/bash" to the top of my entrypoint file didn't help.
ENTRYPOINT [ "bash", "entrypoint.sh" ]
There are several possible reasons for an error like this.
In my case, it was due to the executable file (docker-entrypoint.sh from the Ghost blog Dockerfile) lacking the executable file mode after I'd downloaded it.
Solution: chmod +x docker-entrypoint.sh
I had the same problem, After lots of googling, I couldn't find out how to fix it.
Suddenly I noticed my stupid mistake :)
As mentioned in the docs, the last part of docker run is the command you want to run and its arguments after loading up the container.
NOT THE CONTAINER NAME !!!
That was my embarrassing mistake.
Below I provided you with the picture of my command line to see what I have done wrong.
And this is the fix as mentioned in the docs.
A Docker container might be built without a shell (e.g. https://github.com/fluent/fluent-bit-docker-image/issues/19).
In this case, you can copy-in a statically compiled shell and execute it, e.g.
docker create --name temp-busybox busybox:1.31.0
docker cp temp-busybox:/bin/busybox busybox
docker cp busybox mycontainerid:/busybox
docker exec -it mycontainerid /bin/busybox sh
In the error message shown:
Error response from daemon: Cannot start container foo_1: \
exec: "grunt serve": executable file not found in $PATH
It is complaining that it cannot find the executable grunt serve, not that it could not find the executable grunt with the argument serve. The most likely explanation for that specific error is running the command with the json syntax:
[ "grunt serve" ]
in something like your compose file. That's invalid since the json syntax requires you to split up each parameter that would normally be split by the shell on each space for you. E.g.:
[ "grunt", "serve" ]
The other possible way you can get both of those into a single parameter is if you were to quote them into a single arg in your docker run command, e.g.
docker run your_image_name "grunt serve"
and in that case, you need to remove the quotes so it gets passed as separate args to the run command:
docker run your_image_name grunt serve
For others seeing this, the executable file not found means that Linux does not see the binary you are trying to run inside your container with the default $PATH value. That could mean lots of possible causes, here are a few:
Did you remember to include the binary inside your image? If you run a multi-stage image, make sure that binary install is run in the final stage. Run your image with an interactive shell and verify it exists:
docker run -it --rm your_image_name /bin/sh
Your path when shelling into the container may be modified for the interactive shell, particularly if you use bash, so you may need to specify the full path to the binary inside the container, or you may need to update the path in your Dockerfile with:
ENV PATH=$PATH:/custom/dir/bin
The binary may not have execute bits set on it, so you may need to make it executable. Do that with chmod:
RUN chmod 755 /custom/dir/bin/executable
The binary may include dynamically linked libraries that do not exist inside the image. You can use ldd to see the list of dynamically linked libraries. A common reason for this is compiling with glibc (most Linux environments) and running with musl (provided by Alpine):
ldd /path/to/executable
If you run the image with a volume, that volume can overlay the directory where the executable exists in your image. Volumes do not merge with the image, they get mounted in the filesystem tree same as any other Linux filesystem mount. That means files from the parent filesystem at the mount point are no longer visible. (Note that named volumes are initialized by docker from the image content, but this only happens when the named volume is empty.) So the fix is to not mount volumes on top of paths where you have executables you want to run from the image.
If you run a binary for a different platform, and haven't configured binfmt_misc with the --fix-binary option, qemu will be looking for the interpreter inside the container filesystem namespace instead of the host filesystem. See this Ubuntu bug report for more details on this issue.
If the error is from a shell script, the issue is often with the first line of that script (e.g. the #!/bin/bash). Either the command doesn't exist inside the image for a reason above, or the file is not saved as ascii or utf8 with Linux linefeeds. You can attempt dos2unix to fix the linefeeds, or check your git and editor settings.
in my case i order params wrong move all switchs before image name
I got this error message, when I was building alpine base image :
ERROR: for web Cannot start service web: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
In my docker-compose file, I had the command directive in which executing command using bash and bash does not come with alpine base image.
command: bash -c "python manage.py runserver 0.0.0.0:8000"
Then I realized and executed command using sh (shell).
It worked for me.
problem is glibc, which is not part of apline base iamge.
After adding it worked for me :)
Here are the steps to get the glibc
apk --no-cache add ca-certificates wget
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk
apk add glibc-2.28-r0.apk
Refering to the title.
My mistake was to put variables via --env-file during docker run. Among others the file consisted of a PATH extension: PATH=$PATH:something, which caused PATH var look literally like PATH=$PATH:something (var resolution hadn't been performed) instead of PATH:/usr/bin...:something.
I couldn't make the resolution work through --env-file, so the only way I see this working is by using ENV in Dockerfile.
I ran into this issue using docker-compose. None of the solutions here or on this related question resolved my issue. Ultimately what worked for me was clearing all cached docker artifacts with docker prune -a and restarting docker.
to make it work add soft reference to /usr/bin:
ln -s $(which node) /usr/bin/node
ln -s $(which npm) /usr/bin/npm