programing

standard_init_linux.go: exec 사용자 프로세스로 인해 "exec 형식 오류"가 발생했습니다.

itsource 2022. 10. 15. 11:57
반응형

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 errorme은 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내 스테이트먼트Dockerfiles:

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-ceCircle CI에서도 디폴트이기 때문에 최신으로 변경한 직후에 1개의 문제가 해결되었습니다.

언급URL : https://stackoverflow.com/questions/42494853/standard-init-linux-go178-exec-user-process-caused-exec-format-error

반응형