当我在windows 10上运行docker映像时。我得到这个错误:

standard_init_linux.go:190: exec user process caused "no such file or directory"

我的docker文件是:

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"]

脚本以#!开头/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

尝试method1: 试着改变#!/bin/sh到#!/bin/bash但是得到同样的错误。

尝试method2: docker文件中新增dos2unix

RUN apt-get install -y dos2unix
RUN dos2unix /run.sh

当前回答

我发现了一个特殊的边缘情况,我在一个alpine容器中使用tini init,但由于我没有使用静态链接的版本,并且alpine使用musl libc而不是默认安装的GNU libc库,它崩溃了,并出现了完全相同的错误消息。

如果我明白这一点,并花时间阅读文档,我就会找到Tini Static,它在更改后解决了我的问题。

其他回答

我在x86机器上基于ARM构建docker映像时遇到了同样的错误消息。这个问题可以通过安装QEMU和注册脚本来解决

#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 

如果试图在从头开始的容器中运行动态链接的可执行文件,也会出现此错误。可执行文件将不能链接到共享库,并将报告一个(不是很有信息量)。"没有这样的文件或目录"错误。

让我们构建一个动态可执行测试:

cat <<EOF | g++ -x c++ - -o test
#include <iostream>
int main() {
    std::cerr << "Hello!" << std::endl;
    return 0;
}
EOF

这确实是一个动态可执行文件。运行ldd测试将报告如下内容(依赖于libc等):

linux-vdso.so.1 (0x00007ffd699fc000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff570f7a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff570c76000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff570a5f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5706c0000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff5714fe000)

现在,让我们用以前的可执行文件从头构建一个映像。Dockerfile将是:

FROM scratch
COPY test /
CMD [ "/test" ]

构建映像。然后,运行一个来自image的动态容器:

docker build . -t local/test
docker run --rm local/test

容器失败的退出码1,我得到:

standard_init_linux.go:219: exec user process caused: no such file or directory

这个问题是通过使用静态链接(在之前的gcc/g++ linker命令中使用-static flag)来解决的,它会生成一个独立的可执行文件。

请注意类似的错误,例如:

standard_init_linux.go:211: exec user process caused "no such file or directory"

如果为其构建映像的体系结构与您的系统不匹配,就会发生这种情况。例如,试图在x86_64机器上运行为arm64构建的映像会生成此错误。

我正在构建一个Go应用程序,这些答案对我来说都是错误的,所以我想分享我的解决方案。对我来说,我有一个没有Windows参与的Dockerfile(在Mac上编码,尽管在macOS 11和macOS 12上共享一个Dockerfile)。行尾是一样的)。

对我来说,最终的解决方案是,我需要将我的应用程序构建为一个静态链接的二进制文件,它可以在没有外部依赖的情况下运行。我正在为一个Go应用程序构建Dockerfile,它首先在一个Go构建器映像中构建,然后在一个草稿映像中构建。为了允许我的二进制文件从头开始运行,我必须添加CGO_ENABLED=0标志。更多信息请访问reddit页面:https://www.reddit.com/r/golang/comments/pi97sp/comment/hbo0fq6/?utm_source=share&utm_medium=web2x&context=3

我的代码,它最终工作:

############################
# 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"]

存在的问题:

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.

立即解决方案:

打开您最喜欢的代码编辑器并更改导致冲突的文件的行结束符,在我们的示例中是:entrypoint.sh。你可以在软件右下角的Visual Studio Code中做到这一点,单击CRLF,并将文件行的末尾更改为LF。

从下面的链接阅读整篇文章,找到永久的解决方案:

https://davidcasr.medium.com/docker-standard-init-linux-go-211-exec-user-process-caused-no-such-file-or-directory-en-c0cb42edb295