standard_init_linux.go:190: exec 用户进程导致 "no such file or directory" - Docker

Question

当我运行我的 docker 图片在 windows 10 上时。我收到这个错误：

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

试过方法一： 尝试将 #!/bin/sh 更改为 #!/bin/bash 但出现同样的错误。

试过方法二：在 docker 文件

中添加了 dos2unix

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

Answer 1

在我的例子中，我不得不将 run.sh 文件的行结尾从 CRLF 更改为 LF，错误消失了。

Answer 2

如下更改入口点。它对我有用

ENTRYPOINT ["sh","/run.sh"]

正如 tuomastik 指出的那样, the docs 要求第一个参数是可执行文件：

ENTRYPOINT has two forms:

ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)

ENTRYPOINT command param1 param2 (shell form)

Answer 3

使用记事本++，进入编辑 -> EOL 转换 -> 从 CRLF 更改为 LF。

更新：对于 VScode 用户：您可以通过点击状态栏右下角的 CRLF 将 CRLF 更改为 LF

Answer 4

使用 Notepad++ 将 CRLF 替换为 LF

Notepad++ 的 Find/Replace 功能很好地处理了这个要求很好。只需调出替换对话框 (CTRL+H)，select 扩展搜索模式 (ALT+X)，搜索“\r\n”并替换为 “\n”：
点击全部替换 (ALT+A)

重建运行 docker 图像应该可以解决您的问题。

Answer 5

这是一个 CRLF 问题。我用这个解决了这个问题：

git config --global core.eol lf

git config --global core.autocrlf input

find . -type f -print0 | xargs -0 dos2unix

Answer 6

将此添加到您的 Dockerfile

RUN cat /run.sh | tr -d '\r' > /run.sh

Answer 7

我在使用 alpine 图片时遇到了同样的问题。

我的 .sh 文件的第一行如下：

#!/bin/bash

Alpine 没有bash。所以将行更改为

#!/bin/sh

或使用

安装bash

apk add --no-cache bash

为我解决了这个问题。

Answer 8

"No such file or directory" 来自 Linux，我发现有以下原因：

第一个原因是您的容器中实际上没有文件。有些人尝试运行来自主机的命令而不将其添加到他们的图像中。有些人通过在他们想要的命令之上安装一个卷来隐藏他们的命令运行。如果您运行同一个容器，但使用 shell 而不是正常的 entrypoint/cmd 值，并且运行和 ls /path/to/cmd 您会看到它是否存在。

下一个原因是运行错误的命令。这通常出现在 json/exec 命令格式为运行时，无法正确解析。如果您看到一个命令试图运行 ["app", 或类似的东西，则 json 字符串未被 Docker 解析并且 Linux 正在尝试使用 shell 将命令解析为字符串。如果您对 args 排序不当，也会发生这种情况，例如trying to 运行 -it 是你试图在图像名称之后放置标志的标志，而它们必须放在图像名称之前。

对于 shell 脚本，如果带有 #! 的第一行指向容器内不存在的命令，则会出现此错误。对于某些人来说，这是试图在只有 /bin/sh 的图像中运行 bash。在您的情况下，这可以来自脚本中的 Windows 换行符。在您的编辑器中切换到 Linux/Unix 换行符将更正该问题。

对于二进制文件，如果缺少链接库，则会出现此错误。当使用 libc 编译的 Go 命令时，我经常看到这种情况，但是运行在 alpine 上使用 musl 或根本没有任何库的 scratch。您需要包含所有缺少的库或静态编译您的命令。要查看这些库链接，请在您的二进制文件上使用 ldd /your/app。

Answer 9

我只想补充：对于 VSCode 用户，您可以通过单击 CRLF[=19= 将 CRLF 行尾更改为 LF ]，然后 select LF 并保存文件。

我遇到了同样的问题，这解决了它。

Answer 10

我解决了这个问题，在 vscode 中设置我的设置。

文件
1. 首选项
  1. 设置
    1. 文本编辑器
      1. 文件
      2. Eol - 设置为\n

此致

Answer 11

假设您在运行在 alpine 容器中使用 go 二进制文件时遇到此问题。在构建 bin

之前导出以下变量

# CGO has to be disabled for alpine
export CGO_ENABLED=0

然后go build

Answer 12

注意类似的错误，例如：

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

如果构建映像所针对的体系结构与您的系统体系结构不匹配，则可能会发生这种情况。例如，尝试在 x86_64 机器上运行为 arm64 构建的映像会产生此错误。

Answer 13

我发现了一个特殊的极端情况，我使用的是默认安装的 tini init in an alpine container, but since I was not using the statically linked version, and Alpine uses musl libc rather than GNU LibC library，它崩溃并显示完全相同的错误消息。

如果我理解这一点并花时间正确阅读文档，我会发现 Tini Static，在更改为后解决了我的问题。

Answer 14

这是因为 shell 脚本是格式化的 windows 我们需要更改为 unix 格式。您可以在任何 Linux 系统上运行 dos2unix 命令。

dos2unix your-file.sh

如果您无法访问 Linux 系统，您可以使用 Git Bash for Windows，它带有 dos2unix.exe

dos2unix.exe your-file.sh

Answer 15

这里有多个正确答案。我没有看到它的 VIM 版本，所以就在这里。在 VIM 中打开文件，检查底部状态行 for example，执行 set ff=dos（对于 CRLF）或 set ff=unix（对于 LF）。

Answer 16

我在 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

Answer 17

我在使用 CGO 构建应用程序时遇到了这个问题，然后将其复制到 scratch 图像。 Libc 在那里不存在，所以我使用 alpine 作为我的基础图像。

Answer 18

我解决了类似的问题

我的配置： -> Docker 桌面 WSL 2 后端 - Windows -> 需要 CGO_ENABLED=1，因为我使用 Lib 编译了一个 Kafka Producer 汇合-kafka-go.v1/kafka

我的 docker 图像已经构建成功，但是当我使用 docker-compose-up 启动图像时，出现了同样的问题：

xxxxx:~/cp-all-in-one/cp-all-in-one-community# docker-compose up
Recreating ms-c3alert ... done
Attaching to ms-c3alert
ms-c3alert | standard_init_linux.go:211: exec user process caused "no such file or directory"
ms-c3alert exited with code 1

之后，测试线程和另一个页面中的所有选项...我发现Fix在go build语句中添加了-ldflags='-w -extldflags "-static" '

RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -ldflags='-w -extldflags "-static"' -a -installsuffix cgo -o c3alert .

Answer 19

对于 VScode 用户，在 IDE 的 右下角 您可以找到CRLF/LF，因此切换为 LF 并再次保存您的文件。多田！！你会没事的。

Answer 20

我的 .sh 文件末尾多了一行。我删除了它并解决了问题。

Answer 21

您可以在 Mac 上使用 BBEdit 解决此问题，因为 Notepad++ 不可用。

在window的底部很明显。除了字符集选项

Answer 22

git config core.autocrlf false  
git rm --cached -r .   
git reset --hard

https://www.codegrepper.com/code-examples/shell/How+to+change+all+files%27+default+eol+to+LF+in+windows

Answer 23

问题：

问题来自 .sh 文件。首先我们必须记住 Windows 使用 \r\n 作为行尾，而 Linux 和 Mac 使用 \n。 Git 有一个称为 autoclrf 的功能，通常在 Windows 上设置为“true”。从 Git 存储库下载完成后，这会自动将 \n 转换为 \r\n，但是 Git 没有对此做出任何通知，因此会生成错误。这个过程是好的，至少对其他文件来说是这样，但是bash文件就不是这样了，entrypoint.sh文件就是这样。

直接解决方案：

打开您最喜欢的代码编辑器并更改导致冲突的文件的行尾，在我们的例子中：entrypoint.sh。您可以在软件右下角的 Visual Studio 代码中执行此操作，单击显示 CRLF 的位置并将文件行的末尾更改为 LF.

从下面的 link 中阅读完整的 post 永久解决方案：

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

Answer 24

如果尝试在从头开始的容器中运行动态 linked 可执行文件，也会出现此错误。可执行文件将无法 link 到共享 (so) 库，并且会报告一个（信息量不大的）“没有这样的文件或目录”错误。

让我们构建一个动态可执行文件test:

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

这确实是一个动态可执行文件。运行 ldd test 会报告类似（对 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" ]

构建图像。然后，运行来自图像的动态容器：

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

问题通过使用静态 linking 解决（在之前的 gcc/g++ linker 命令中使用 -static 标志），它产生一个独立可执行文件。

Answer 25

我正在构建一个 Go 应用程序，这些答案中的每一个对我来说都是错误的，所以我想分享我的解决方案。对我来说，我有一个没有 Windows 参与的 Dockerfile（在 Mac 上编码，尽管在 macOS 11 上的一个和 macOS 12 上的另一个之间共享。行结尾是相同的）。

对我来说，最终的解决方案是我需要将我的应用程序构建为静态链接的二进制文件，这样运行没有外部依赖项。我正在为 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"]

Answer 26

我在使用以下内容构建时遇到了类似的问题

FROM golang:1.18.0-alpine3.15 AS builder

WORKDIR /go/src/blah
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

WORKDIR /go/src/blah

FROM centos AS runtime   ## NOTICE THE DISTRO CHANGE HERE
COPY --from=builder /go/bin/blah /bin/blah

CMD ["blah"]

这是我的解决方法（与上面概述的相同，但是添加了供人们检查的内容）

FROM golang:1.18.0-alpine3.15 AS builder

WORKDIR /go/src/blah
COPY . .

RUN go get -d -v ./...
RUN export CGO_ENABLED=0 && go install -v ./...    <== added during install/build

WORKDIR /go/src/blah

FROM centos AS runtime
COPY --from=builder /go/bin/blah /bin/blah

CMD ["blah"]

干杯。

standard_init_linux.go:190: exec 用户进程导致 "no such file or directory" - Docker

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

docker

dockerfile

docker-for-windows