standard_init_linux.go:190 : exec user process caused "no such file or directory" - Docker

Question

Lorsque j'exécute mon image Docker sur Windows 10. J'obtiens cette erreur :

standard_init_linux.go:190: exec user process caused "no such file or directory"

mon fichier docker est :

FROM openjdk:8

EXPOSE 8080

VOLUME /tmp

ADD appagent.tar.gz /opt/app-agent
ADD services.jar app.jar
ADD run.sh /run.sh

# Install compiler and perl stuff
RUN apt-get update
RUN apt-get install -y build-essential
RUN apt-get install -y gcc-multilib
RUN apt-get install -y perl

# Install Percona Toolkit
RUN apt-get install --yes percona-toolkit
RUN ["chmod", "+x", "/run.sh"]
ENTRYPOINT ["/run.sh"]

et le script commence par #!/bin/sh

#!/bin/sh
set -e

JAVA_OPTS="-Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/urandom"

if [ "${APPD_APP_NAME}" != "" ]; then
JAVA_AGENT="-javaagent:/opt/app-agent/javaagent.jar
fi

exec java ${JVM_OPTS} ${JAVA_OPTS} ${JAVA_AGENT} -jar /app.jar

Méthode essayée1 : J'ai essayé de changer #!/bin/sh en #!/bin/bash mais je reçois la même erreur.

J'ai essayé la méthode 2 : ajout de dos2unix dans le fichier docker

RUN apt-get install -y dos2unix
RUN dos2unix /run.sh

Answer 1

Utilisez notepad++, allez à edit -> EOL conversion -> changez de CRLF à LF.

Answer 2

J'ai eu le même problème en utilisant le alpine image.

Mon .sh avait la première ligne suivante :

#!/bin/bash

Alpine ne dispose pas de bash. Donc, en changeant la ligne en

#!/bin/sh

ou en installant bash avec

apk add --no-cache bash

a résolu le problème pour moi.

Answer 3

Changer le point d'entrée comme ci-dessous. Cela a fonctionné pour moi

ENTRYPOINT ["sh","/run.sh"]

Comme l'a souligné tuomastik dans les commentaires , les docs exigent que le premier paramètre soit l'exécutable :

L'ENTRYPOINT se présente sous deux formes :

ENTRYPOINT ["executable", "param1", "param2"] (forme exécutée, préférée)

ENTRYPOINT command param1 param2 (forme de coquille)

Answer 4

Dans mon cas, j'ai dû changer la fin de ligne de CRLF à LF pour le run.sh et l'erreur a disparu.

Answer 5

"No such file or directory" provient de Linux, et j'ai vu les causes suivantes :

La première cause est que le fichier ne se trouve pas dans votre conteneur. Certaines personnes essaient d'exécuter une commande depuis l'hôte sans l'ajouter à leur image. D'autres font de l'ombre à leur commande en montant un volume au-dessus de la commande qu'ils veulent exécuter. Si vous exécutez le même conteneur, mais avec un shell au lieu de la valeur normale du point d'entrée/de la commande, et que vous exécutez une commande de type ls /path/to/cmd vous verrez si cela existe.

La cause suivante est l'exécution d'une mauvaise commande. Cela se produit souvent lorsque le format json/exec de la commande à exécuter n'est pas analysé correctement. Si vous voyez une commande qui tente de s'exécuter ["app", ou quelque chose de similaire, la chaîne json n'a pas été analysée par Docker et Linux essaie d'utiliser un shell pour analyser la commande comme une chaîne. Cela peut également se produire si vous mal ordonnez les args, par exemple en essayant d'exécuter -it est un signe que vous avez essayé de placer des drapeaux après le nom de l'image alors qu'ils doivent être placés avant le nom de l'image.

Avec les scripts shell, cette erreur apparaît si la première ligne avec l'option #! pointe vers une commande qui n'existe pas dans le conteneur. Pour certains, il s'agit d'essayer d'exécuter bash dans une image qui a seulement /bin/sh . Et dans votre cas, cela peut provenir des linefeeds Windows dans le script. Si vous passez à des linéaires Linux/Unix dans votre éditeur, cela sera corrigé.

Avec les binaires, cette erreur apparaît si une bibliothèque liée est manquante. J'ai souvent vu cela lorsque des commandes Go compilées avec la commande libc mais courir sur alpine avec musl ou scratch sans aucune bibliothèque. Vous devez soit inclure toutes les bibliothèques manquantes, soit compiler statiquement votre commande. Pour voir ces liens de bibliothèques, utilisez ldd /your/app sur votre binaire.