When I am running my docker image on windows 10. I am getting this error:
standard_init_linux.go:190: exec user process caused "no such file or directory"
my docker file is:
FROM openjdk:8
EXPOSE 8080
VOLUME /tmp
ADD appagent.tar.gz /opt/app-agent
ADD services.jar app.jar
ADD run.sh /run.sh
# Install compiler and perl stuff
RUN apt-get update
RUN apt-get install -y build-essential
RUN apt-get install -y gcc-multilib
RUN apt-get install -y perl
# Install Percona Toolkit
RUN apt-get install --yes percona-toolkit
RUN ["chmod", "+x", "/run.sh"]
ENTRYPOINT ["/run.sh"]
and the script is start with #!/bin/sh
#!/bin/sh
set -e
JAVA_OPTS="-Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/urandom"
if [ "${APPD_APP_NAME}" != "" ]; then
JAVA_AGENT="-javaagent:/opt/app-agent/javaagent.jar
fi
exec java ${JVM_OPTS} ${JAVA_OPTS} ${JAVA_AGENT} -jar /app.jar
Tried method1: Tried changing #!/bin/sh to #!/bin/bash but getting same error.
Tried method2: added dos2unix in docker file
RUN apt-get install -y dos2unix
RUN dos2unix /run.sh
Use notepad++, go to edit -> EOL conversion -> change from CRLF to LF.
update: For VScode users: you can change CRLF to LF by clicking on CRLF present on lower right side in the status bar
I had the same issue when using the alpine
image.
My .sh
file had the following first line:
#!/bin/bash
Alpine does not have bash. So changing the line to
#!/bin/sh
or installing bash with
apk add --no-cache bash
solved the issue for me.
change entry point as below. It worked for me
ENTRYPOINT ["sh","/run.sh"]
As tuomastik pointed out in the comments, the docs require the first parameter to be the executable:
ENTRYPOINT has two forms:
ENTRYPOINT ["executable", "param1", "param2"]
(exec form, preferred)
ENTRYPOINT command param1 param2
(shell form)
Suppose you face this issue while running your go binary with in alpine container. Export the following variable before building your bin
# CGO has to be disabled for alpine
export CGO_ENABLED=0
Then go build
In my case I had to change line ending from CRLF
to LF
for the run.sh
file and the error was gone.
I just wanted to add: for VSCode users, you can change CRLF line endings to LF by clicking on CRLF in the status bar, then select LF and save the file.
I had the same issue, and this resolved it.
"No such file or directory" is coming from Linux, and I've seen the following causes:
First cause is not actually having the file inside your container. Some people try to run a command from the host without adding it to their image. Some people shadow their command by mounting a volume on top of the command they wanted to run. If you run the same container, but with a shell instead of your normal entrypoint/cmd value, and run an ls /path/to/cmd
you'll see if this exists.
The next cause is running the wrong command. This often appears with json/exec formatting of the command to run that doesn't parse correctly. If you see a command trying to run ["app",
or something similar, the json string wasn't parsed by Docker and Linux is trying to use a shell to parse the command as a string. This can also happen if you misorder the args, e.g. trying to run -it
is a sign you tried to place flags after the image name when they must be placed before the image name.
With shell scripts, this error appears if the first line with the #!
points to a command that doesn't exist inside the container. For some, this is trying to run bash
in an image that only has /bin/sh
. And in your case, this can be from Windows linefeeds in the script. Switching to Linux/Unix linefeeds in your editor will correct that.
With binaries, this error appears if a linked library is missing. I've seen this often when Go commands that are compiled with libc
, but run on alpine with musl
or scratch without any libraries at all. You need to either include all the missing libraries or statically compile your command. To see these library links, use ldd /your/app
on your binary.
It's a CRLF problem. I fixed the problem using this:
git config --global core.eol lf
git config --global core.autocrlf input
find . -type f -print0 | xargs -0 dos2unix
Note a similar error such as:
standard_init_linux.go:211: exec user process caused "no such file or directory"
can happen if the architecture an image was built for does not match the one of your system. For instance, trying to run an image built for arm64
on a x86_64
machine can generate this error.
I had this issue when building an application using CGO, then copying it over to a scratch
image. Libc did not exist there, so I used alpine
as my base image instead.
Replacing CRLF with LF using Notepad++
Rebuild and run the docker image should solve your problem.
This is because the shell script is formatted in windows we need to change to unix format. You can run the dos2unix command on any Linux system.
dos2unix your-file.sh
If you don’t have access to a Linux system, you may use the Git Bash for Windows which comes with a dos2unix.exe
dos2unix.exe your-file.sh
I had the same error message while building a docker image based on ARM
on x86
machine. The issue is solved by installing QEMU and registering the script
#Install the qemu
sudo apt-get install qemu binfmt-support qemu-user-static packages
#This step will execute the registering scripts
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
For the VScode users, at the bottom-right corner of the IDE you can find CRLF/LF, so toggle this to LF and save again your file. Tada!! You will be fine.
The problem:
The problem comes from the .sh file. First we must remember that Windows uses \r\n as the end of the line, while Linux and Mac use \n. Git has a feature called autoclrf that is generally set to “true” on Windows. This automatically converts \n to \r\n upon completion of the download from a Git repository, but Git does not make any kind of notice of this, hence the error is generated. This process is good, at least for the other files, but it is not the case for bash files, as is the case for the entrypoint.sh file.
The Immediate Solution:
Open your favorite code editor and change the line endings for the file that is causing the conflict, in our case: entrypoint.sh. You can do that in Visual Studio Code at the bottom right of the software, click where it says CRLF and change the end of the line of the file to LF.
Read the entire post for permanent solution from the link below:
https://davidcasr.medium.com/docker-standard-init-linux-go-211-exec-user-process-caused-no-such-file-or-directory-en-c0cb42edb295
I was building a Go application, and every one of these answers was wrong for me, so I wanted to share my solution. For me, I had a Dockerfile that had no Windows involvement (coded on a Mac, albeit shared between one on macOS 11 and another on macOS 12. Line endings are the same though).
For me, the solution ended up being that I needed to build my application as a statically linked binary that would run without external dependencies. I was building a Dockerfile for a Go application that was first built in a Go builder image, and then in a scratch image. To allow my binary to run on scratch, I had to add the CGO_ENABLED=0
flag. More info on this reddit page: https://www.reddit.com/r/golang/comments/pi97sp/comment/hbo0fq6/?utm_source=share&utm_medium=web2x&context=3
My code, which ended up working:
############################
# STEP 1 build optimized executable binary
############################
FROM golang:1.16-alpine AS builder
WORKDIR /app
COPY go.mod ./
COPY go.sum ./
RUN go mod download
COPY *.go ./
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o cl-api
############################
# STEP 2 build a small image
############################
FROM scratch
COPY --from=builder /app/cl-api /
EXPOSE 8000
ENTRYPOINT ["/cl-api"]
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With