python - imagenes - standard_init_linux.go: 178: el proceso del usuario exec causó "error de formato exec"
imagenes docker (4)
Extendiéndose a la respuesta aceptada:
Para una imagen alpina (sin bash):
#!/bin/ash
en la parte superior del archivo sh, resuelve el problema.
Docker comenzó a lanzar este error:
standard_init_linux.go: 178: el proceso del usuario exec causó "error de formato exec"
Cada vez que ejecuto un contenedor de ventana acoplable específico con CMD o ENTRYPOINT, sin tener en cuenta ningún cambio en el archivo, se eliminará CMD o ENTRYPOINT. Aquí está el archivo docker con el que he estado trabajando, que funcionó perfectamente hasta hace una hora:
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"]
He enfrentado el mismo problema en RHEL 7.3, ventana acoplable 17.05-ce al ejecutar una imagen cargada sin conexión. Apareció que el controlador de almacenamiento predeterminado de RHEL / CentOS cambió de device-mapper de device-mapper a superposición. Revertir el controlador a devicemapper solucionó el problema.
dockerd --storage-driver=devicemapper
o
/etc/docker/daemon.json
{
"storage-driver": "devicemapper"
}
Otra posible razón para esto podría ser si el archivo se guarda con los finales de línea de Windows (CRLF). Guárdelo con los finales de línea de Unix (LF) y se encontrará el archivo.
Se me olvidó poner
#!/bin/bash
en la parte superior del archivo sh, problema resuelto.