docker begon deze fout te geven:
standard_init_linux.go:178: exec gebruikersproces veroorzaakte “exec format error”
wanneer ik een specifieke docker-container uitvoer met CMD of ENTRYPOINT, zonder rekening te houden met eventuele wijzigingen in het bestand, behalve het verwijderen van CMD of ENTRYPOINT. hier is het docker-bestand waarmee ik heb gewerkt en dat tot ongeveer een uur geleden perfect werkte:
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"]
Antwoord 1, Autoriteit 100%
Ik ben vergeten
#!/bin/bash
Aan de bovenkant van het SH-bestand, probleemoploskeld.
Antwoord 2, Autoriteit 21%
Dit kan gebeuren als u probeert een X86-afbeelding op een ARM64 / Aarch64-machine uit te voeren.
U moet het beeld opnieuw opbouwen met behulp van de bijbehorende architectuur
Antwoord 3, Autoriteit 16%
Voeg deze code toe
#!/usr/bin/env bash
Aan de bovenkant van uw scriptbestand.
Antwoord 4, Autoriteit 2%
Een andere mogelijke reden hiervoor kan zijn als het bestand wordt opgeslagen met Windows Line-eindes (CRLF). Sla het op met UNIX-lijnuiteinden (LF) en het bestand wordt gevonden.
Antwoord 5, Autoriteit 2%
Uitbreiden naar het geaccepteerde antwoord:
Voor een alpine (zonder bash) Afbeelding:
#!/bin/ash
Aan de bovenkant van het SH-bestand, lost het probleem op.
Antwoord 6, Autoriteit 2%
Hebt dezelfde fout, ik bouwde armbeeld na het vervangen van AMD. PROBLEEM VAST
Die fout betekent meestal dat u dit AMD64-afbeelding probeert uit te voeren op een niet-AMD64-host (zoals 32-bits of arm).
Probeer te bouwen met behulp van buildx en opgeeft – platvom linux / amd64
Voorbeeldopdracht
docker buildx build -t ranjithkumarmv/node-12.13.0-awscli . --platform linux/amd64
Antwoord 7
Ik heb hetzelfde probleem in Rhel 7.3, Docker 17.05-CE geconfronteerd bij het uitvoeren van offline geladen afbeelding. Het verscheen de standaard opslagstuurprogramma van Rhel / Cento’s gewijzigd van apparaat-mapper om te overlay. Rapporteer de bestuurder naar Devicemapper het probleem opgelost.
dockerd --storage-driver=devicemapper
of
/etc/docker/daemon.json
{
"storage-driver": "devicemapper"
}
Antwoord 8
Nog een mogelijkheid is dat #!/bin/bash niet in de allereerste regel staat. Er mag echt niets voor staan (geen lege regels, niets).
Antwoord 9
Geen direct antwoord op de gestelde vraag. Hoewel ik de fout kreeg tijdens het aanroepen van “docker-compose up” om mijn nodejs-toepassing te openen. Ik realiseerde me dat ik in mijn “Dockerfile” CMD ["./server.js"]had.
Om het op te lossen heb ik het vervangen door CMD ["npm","start"]en dat loste het probleem op. Ik hoop dat als iemand hier terechtkomt voor deze uitzondering dit nuttig kan zijn.
Antwoord 10
In mijn geval heb ik mijn ECS-instantie “leeggemaakt” en weer “geactiveerd” en daarna verdween de fout.
Antwoord 11
Als u een IBR1700-router gebruikt die containers uitvoert, kunt u een soortgelijke fout krijgen in de opdrachtregel van de router na het gebruik van de opdracht container logs test(waarbij test de naam van de container is).
Om dit op te lossen, moet je de applicatie zo bouwen dat deze op een ander platform draait. Het gebruikt 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
Door met deze build naar de repository te pushen, kan deze op de router worden uitgevoerd.