当前位置：首页 > news >正文

Docker Compose v2 启动报错 standard_init_linux.go:228 怎么办？

news 2026/5/5 16:45:49

Docker Compose v2 启动报错 standard_init_linux.go:228 怎么办？

根据 2025 年 5 月 30 日的实际案例分析，该错误在 JDK 从 1.8 升级到 21 版本的容器化部署中出现频率显著增加，主要原因是机器架构与 Docker 镜像架构不匹配导致。

原因分析

standard_init_linux.go:228 错误主要分为两类：一是exec user process caused: no such file or directory，二是exec user process caused: exec format error。根据 2024 年 1 月 18 日的技术分析，第一种错误通常由以下原因造成：镜像中不存在指定的可执行文件或目录、文件或目录的路径不正确、文件或目录的权限设置不正确。第二种错误则表明 Docker 试图执行容器内的某个可执行文件时遇到了格式问题，通常是因为可执行文件的格式与容器操作系统不兼容。

根据 2021 年 12 月 17 日博客园的记录，Windows 系统的默认代码格式是 dos，而 Linux 系统的默认代码格式是 unix，如果使用 dos 格式进行代码编写，在编译为 docker 镜像之后，Docker 的启动脚本 (例如 entry-point.sh) 文本内容的每一行都会被自动添加上一个^W 标识，造成解析错误。

解决方案

方案一：检查并修复脚本文件格式

根据截至 2026 年 4 月 6 日的技术资料，使用 vi 打开文件，查看文件的格式：:set ff，输出时fileformat=dos则说明是 Windows 格式脚本。将文件改成 Linux 格式：:set ff=unix。或者在 Dockerfile 中添加以下命令进行批量转换：

RUN dos2unix *.sh
RUN dos2unix *.yml
CMD "dos2unix *.properties"

此方案适用于在 Windows 环境下编写脚本后构建镜像的场景，2024 年 6 月 12 日的搜索结果显示这是最常见的解决方法。

方案二：检查镜像架构匹配性

根据 2025 年 5 月 30 日的 JDK 升级案例，首先查看 Docker 镜像的架构：docker inspect --format='{{.Architecture}}' docker.io/openjdk:21，结果显示 openjdk:21 适用的机器架构为 arm64。然后查看机器的架构，如果是部署在 k8s 容器里，执行kubectl get nodes -o wide，可以看到架构为 x86_64，也即 amd64。

解决方案是指定架构拉取镜像：docker pull --platform linux/amd64 openjdk:21-ea-34-jdk。然后在 Dockerfile 中使用匹配的镜像：FROM xxx-harbor-registry.cn-hangzhou.cr.aliyuncs.com/xx_tool/openjdk:21-ea-34-jdk。

方案三：检查文件权限和路径

根据 2024 年 1 月 5 日的资料，确保可执行文件或目录的权限设置正确。可以使用以下命令在镜像中检查文件或目录的权限：docker run -it --rm myimage:latest ls -l /usr/local/bin/my_executable。如果权限设置不正确，使用以下命令更改：docker run -it --rm -v /path/to/my_executable:/tmp/my_executable myimage:latest chmod +x /tmp/my_executable。

同时检查文件是否正确复制到镜像里：RUN ls -al /opt/zxapp，如果文件都在，则基本可以确定是 windows 编码与 unix 不一致问题导致的。