standard_init_linux.go: exec 사용자 프로세스로 인해 "exec 형식 오류"가 발생했습니다.
도커가 다음 오류를 발생시키기 시작했습니다.
standard_init_linux.go: exec 사용자 프로세스로 인해 "exec 형식 오류"가 발생했습니다.
CMD 또는 ENTERPOINT를 삭제한 후 파일 변경에 관계없이 CMD 또는 ENTERPOINT를 사용하여 특정 도커 컨테이너를 실행할 때마다 약 1시간 전까지 완벽하게 작동했던 도커 파일을 다음에 나타냅니다.
FROM buildpack-deps:jessie
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends \
tcl \
tk \
&& rm -rf /var/lib/apt/lists/*
ENV GPG_KEY 0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D
ENV PYTHON_VERSION 3.6.0
ENV PYTHON_PIP_VERSION 9.0.1
RUN set -ex \
&& buildDeps=' \
tcl-dev \
tk-dev \
' \
&& apt-get update && apt-get install -y $buildDeps --no-install-recommends && rm -rf /var/lib/apt/lists/* \
\
&& wget -O python.tar.xz "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz" \
&& wget -O python.tar.xz.asc "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz.asc" \
&& export GNUPGHOME="$(mktemp -d)" \
&& gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEY" \
&& gpg --batch --verify python.tar.xz.asc python.tar.xz \
&& rm -r "$GNUPGHOME" python.tar.xz.asc \
&& mkdir -p /usr/src/python \
&& tar -xJC /usr/src/python --strip-components=1 -f python.tar.xz \
&& rm python.tar.xz \
\
&& cd /usr/src/python \
&& ./configure \
--enable-loadable-sqlite-extensions \
--enable-shared \
&& make -j$(nproc) \
&& make install \
&& ldconfig \
\
&& if [ ! -e /usr/local/bin/pip3 ]; then : \
&& wget -O /tmp/get-pip.py 'https://bootstrap.pypa.io/get-pip.py' \
&& python3 /tmp/get-pip.py "pip==$PYTHON_PIP_VERSION" \
&& rm /tmp/get-pip.py \
; fi \
&& pip3 install --no-cache-dir --upgrade --force-reinstall "pip==$PYTHON_PIP_VERSION" \
&& [ "$(pip list |tac|tac| awk -F '[ ()]+' '$1 == "pip" { print $2; exit }')" = "$PYTHON_PIP_VERSION" ] \
\
&& find /usr/local -depth \
\( \
\( -type d -a -name test -o -name tests \) \
-o \
\( -type f -a -name '*.pyc' -o -name '*.pyo' \) \
\) -exec rm -rf '{}' + \
&& apt-get purge -y --auto-remove $buildDeps \
&& rm -rf /usr/src/python ~/.cache
RUN cd /usr/local/bin \
&& { [ -e easy_install ] || ln -s easy_install-* easy_install; } \
&& ln -s idle3 idle \
&& ln -s pydoc3 pydoc \
&& ln -s python3 python \
&& ln -s python3-config python-config
RUN pip install uwsgi
RUN mkdir /config
RUN mkdir /logs
ENV HOME /var/www
WORKDIR /config
ADD conf/requirements.txt /config
RUN pip install -r /config/requirements.txt
ADD conf/wsgi.py /config
ADD conf/wsgi.ini /config
ADD conf/__init__.py /config
ADD start.sh /bin/start.sh
RUN chmod +x /bin/start.sh
EXPOSE 8000
ENTRYPOINT ["start.sh", "uwsgi", "--ini", "wsgi.ini"]
넣는 것을 잊었다
#!/bin/bash
sh 파일의 맨 위에 문제가 해결되었습니다.
이 문제는 x86 빌드 이미지를 arm64/aarch64 머신에서 실행하려고 할 때 발생할 수 있습니다.
대응하는 아키텍처를 사용하여 이미지를 재구축해야 합니다.
이 오류는 ARM 기반 Apple M1 Pro 칩을 탑재한 MacBook Pro에 이미지가 빌드된 경우에도 발생할 수 있습니다. 따라서 기본적으로 Docker 빌드 명령 대상은arm64
.
을 Docker로 합니다.linux/arm64/v8
build 명령어와 버전 태그 모두에 플랫폼을 지정하는 것으로 충분했습니다.
# Build for ARM64 (default)
docker build -t <image-name>:<version>-arm64 .
# Build for ARM64
docker build --platform=linux/arm64 -t <image-name>:<version>-arm64 .
# Build for AMD64
docker build --platform=linux/amd64 -t <image-name>:<version>-amd64 .
환경
Pro,Core (와 2개의 † : Apple M1 Pro, 10개의 칩 (8개의 퍼포먼스 및 2개의 효율)
20. © 20.10.12, 빌드 e91ed57
이 코드 추가
#!/usr/bin/env bash
스크립트 파일의 맨 위에 있습니다.
도커 이미지가 M1 칩에 구축되어 Fargate에 의해 전개되도록 업로드된 경우 Fargate에서 다음 컨테이너 오류가 나타납니다.
standard_init_linux.go:228: exec user process caused: exec format error
이 문제를 해결할 몇 가지 방법이 있습니다.다음 중 하나를 수행할 수 있습니다.
- 다음을 사용하여 도커 이미지 구축:
docker buildx build --platform=linux/amd64 -t image-name:version .
- Dockerfile의 FROM 스테이트먼트를 갱신하는 방법
FROM --platform=linux/amd64 BASE_IMAGE:VERSION
AMD로 변경한 후 ARM 이미지를 빌드하는 중 동일한 오류가 발생하였습니다.이 문제는 수정되었습니다.
이 에러는, 통상, amd64 이외의 호스트(32비트나 ARM 등)에서 이 amd64 이미지를 실행하려고 하고 있는 것을 의미합니다.
buildx를 사용하여 --platform linux/amd64를 지정하여 빌드해 보십시오.
명령어 예시
docker buildx build -t ranjithkumarmv/node-12.13.0-awscli . --platform linux/amd64
이것을 AWS ECS로 취득하는 경우는, Apple M1 Pro 칩으로 이미지를 구축했을 가능성이 있습니다. 파일에서할 수 .FROM --platform=linux/amd64 <image>:<tag>
.
이미지를 사용하고 예를 , 「」 「 」 、 「 」 。FROM <parent_image_you_created>:<tag>
부분은 꼭 <parent_image_you_created>:<tag>
로 구축되었다.FROM --platform=linux/amd64 <image>:<tag>
.
파일이 Windows 회선 엔딩(CRLF)으로 보존되어 있는 경우도 생각할 수 있습니다.Unix Line Ending(LF; UNIX 행 끝)과 함께 저장하면 파일이 검색됩니다.
승인된 답변으로 확장:
알파인(bash 없음) 이미지의 경우:
#!/bin/ash
이 문제를 해결합니다.
할 때 amd64 Linux의 arch64의 armv7l의 armv7l을 합니다.qemu-user-static
패키지가 인스톨 됩니다. 되어 있지 않은 는, 「」를 .sudo apt install qemu-user-static
등 Ubuntu/Debian/Mint 사용 시sudo dnf install qemu-user-static
이 중 어느 것도 내게는 효과가 없었다.왜 아무도 BOM에 대해 언급하지 않는 거죠?
이 오류는 파일 시작 부분에 바이트 순서 표시가 있는 경우 발생합니다.
head -n 1 yourscript | LC_ALL=C od -tc
Notepad++에서는 인코딩 메뉴에서 적절한 옵션을 선택하여 BOM 없이 UTF-8에 텍스트를 저장할 수 있습니다.
부호화> UTF-8
오프라인에서 로드된 이미지를 실행할 때 RHEL 7.3 도커 17.05-ce에서도 같은 문제가 발생했습니다.RHEL/CentOS의 기본 스토리지 드라이버가 디바이스 맵퍼에서 오버레이로 변경되었습니다.드라이버를 디바이스 매니저로 되돌리면 문제가 해결.
dockerd --storage-driver=devicemapper
또는
/etc/docker/daemon.json
{
"storage-driver": "devicemapper"
}
또 하나의 가능성은 #!/bin/bash가 첫 번째 줄에 없다는 것입니다.그 앞에는 정말 아무것도 없을 것이다(빈 줄도 없고 아무것도 없다).
이치노하기 위해서 up을 호출했을 만, "docker-compose up"은 "docker-compose up"으로 되어 . 파일에 '도커 파일'이 있다는 것을 .CMD ["./server.js"]
.
를 위해 으로 교체했습니다.CMD ["npm","start"]
츠키노이 예외로 인해 이곳에 도착한 사람이 있다면 도움이 될 것입니다.
standard_init_linux.go:228: exec user process caused: exec format error
me은 no no no가 입니다.main
패키지화 할 수배.도움이 됐으면 좋겠는데
저는 현재 M1 Mac을 흔들고 있습니다만, 조금 전에도 이 문제가 있었습니다.스택의 일부로 배포한 Fargate 태스크가 M1 Mac 노트북에 배포되었기 때문에 한 달 넘게 실행되지 않았다는 것을 알게 되었습니다.이전 인텔 기반 Mac에서는 도입 스크립트가 정상적으로 동작하고 있었습니다.
CW 로그에서 방금 발견한 오류(다시 말해 태스크가1개월 이상 실패)는 다음과 같습니다.
standard_init_linux.go:228: exec user process caused: exec format error
수정하기 , 「」의 모든 , 「」의docker build
- 레이어를 태스크를에 Fargate를 업데이트하여 Fargate를 했습니다.--platform=linux/amd64
the the the the 뒤에 태그를 추가한 후로는 동작하지 않았습니다.-t
인수, 예를 들어img-test:0.1-amd64
혹시 제가 이 문제를 언급하고 있었기 때문일까요?:latest
태그 지정은 나중에 할게요.
어쨌든, 이것들은 필요한 변화였다.아시겠지만, 제가 정말 한 일은 그 안에--platform
논쟁, 그 외 모든 것은 그대로였다.
ecr_repository="some/app"
docker build -t ${ecr_repository} \
--platform=linux/amd64 \
--build-arg SOME_ARG='value' \
.
기술적으로 필요한지는 모르겠지만, 만약을 위해 모든 정보를 업데이트했습니다.FROM
내 스테이트먼트Dockerfile
s:
FROM --platform=linux/amd64 ubuntu:<version>
제 경우, ECS가 인스톨 한 「배수」를 실시해, 재차 「액티베이션」을 실시했습니다만, 그 후 에러가 사라졌습니다.
컨테이너를 실행하는 IBR1700 라우터를 사용하는 경우 명령어를 사용한 후 라우터 명령줄에서 동일한 오류가 발생할 수 있습니다.container logs test
(여기서 test는 용기의 이름입니다).
이 문제를 해결하려면 다른 플랫폼에서 실행되도록 애플리케이션을 빌드해야 합니다.Linux/arm/v7을 사용합니다.
docker run -it --rm --privileged docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64
docker buildx create --name mybuilder
docker buildx use mybuilder
docker buildx build --platform linux/arm/v7 --no-cache -t <username/repository>:<tag> . --push
이 빌드를 사용하여 저장소에 푸시하면 라우터에서 실행할 수 있습니다.
https://github.com/cradlepoint/container-samples
ECS 클러스터는 arm64 아키텍처였지만 도커 이미지는 amd64 아키텍처였습니다.도커 이미지를 재구축했습니다.https://docs.docker.com/desktop/multi-arch/
나도 비슷한 문제가 있었다.standard_init_linux.go:228: exec user process caused: exec format error
하지만 답변은 도움이 되지 않았습니다.결국 나는 그것이 오래된 도커 버전이라는 것을 알았다.17.09.0-ce
Circle CI에서도 디폴트이기 때문에 최신으로 변경한 직후에 1개의 문제가 해결되었습니다.
언급URL : https://stackoverflow.com/questions/42494853/standard-init-linux-go178-exec-user-process-caused-exec-format-error
'programing' 카테고리의 다른 글
Object.assign이 올바르게 복사되지 않습니다. (0) | 2022.10.15 |
---|---|
v-module을 사용할 때 div 내에서 작동하지 않는 이벤트를 클릭합니다. - vue js (0) | 2022.10.15 |
새로운 java.io을 작성하는 방법메모리에 파일이 있습니까? (0) | 2022.10.15 |
PHP의 "Headers already sent" 오류를 수정하는 방법 (0) | 2022.10.15 |
도커에 GD 설치 (0) | 2022.10.15 |