standard_init_linux.go: 190: proces użytkownika exec spowodował „brak takiego pliku lub katalogu” - Docker

Kiedy uruchamiam obraz Dockera w systemie Windows 10. Otrzymuję ten błąd:

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

mój plik Dockera to:

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"]

a skrypt zaczyna się od #! / 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

Wypróbowana metoda 1: próbowano zmienić #! / Bin / sh na #! / Bin / bash, ale otrzymałem ten sam błąd.

Wypróbowana metoda2: dodano dos2unix w pliku Dockera

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

Użyj notatnika ++, przejdź do edycji -> konwersja EOL -> zmień z CRLF na LF.

zmień punkt wejścia jak poniżej. U mnie to zadziałało

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

Jak tuomastik wskazał w komentarzach , dokumenty wymagają, aby pierwszy parametr był plikiem wykonywalnym:

ENTRYPOINT ma dwie formy:

ENTRYPOINT ["executable", "param1", "param2"] (formularz exec, preferowany)

ENTRYPOINT command param1 param2 (forma muszli)

Miałem ten sam problem podczas korzystania z alpineobrazu.

Mój .shplik miał następującą pierwszą linię:

#!/bin/bash

Alpine nie ma bash. Więc zmieniam linię na

#!/bin/sh

lub instalując bash z

apk add --no-cache bash

rozwiązał problem za mnie.

Załóżmy, że napotykasz ten problem podczas uruchamiania pliku binarnego go w kontenerze alpejskim. Wyeksportuj następującą zmienną przed utworzeniem pojemnika

# CGO has to be disabled for alpine
export CGO_ENABLED=0

Następnie go build

w moim przypadku musiałem zmienić końcówkę wiersza z CRLFna LFdla run.shpliku i błąd zniknął.

Mam nadzieję, że to pomoże,
Kirsten

To problem z CRLF. Naprawiłem problem, używając tego:

git config --global core.eol lf

git config --global core.autocrlf input

find . -type f -print0 | xargs -0 dos2unix

„Brak takiego pliku lub katalogu” pochodzi z Linuksa i widziałem następujące przyczyny:

Pierwszą przyczyną jest brak pliku w kontenerze. Niektórzy próbują uruchomić polecenie z hosta bez dodawania go do swojego obrazu. Niektórzy ludzie śledzą swoje polecenie, umieszczając wolumin nad poleceniem, które chcieli uruchomić. Jeśli uruchomisz ten sam kontener, ale z powłoką zamiast normalnej wartości punktu wejścia / cmd, i uruchomisz ls /path/to/cmd, zobaczysz, czy to istnieje.

Następną przyczyną jest uruchomienie niewłaściwego polecenia. Często pojawia się to w przypadku formatowania json / exec polecenia do uruchomienia, które nie analizuje poprawnie. Jeśli zobaczysz polecenie próbujące uruchomić ["app",lub coś podobnego, ciąg json nie został przeanalizowany przez Docker, a Linux próbuje użyć powłoki do przeanalizowania polecenia jako ciągu. Może się to również zdarzyć, jeśli źle uporządkujesz argumenty, np. Próba uruchomienia -itjest znakiem, że próbowałeś umieścić flagi po nazwie obrazu, kiedy muszą być umieszczone przed nazwą obrazu.

W przypadku skryptów powłoki ten błąd pojawia się, jeśli pierwsza linia z #!punktami wskazuje polecenie, które nie istnieje w kontenerze. Dla niektórych jest to próba uruchomienia bashobrazu, który ma tylko /bin/sh. W twoim przypadku może to pochodzić z wyprowadzeń wiersza systemu Windows w skrypcie. Przełączenie się na rozwijanie linii w systemie Linux / Unix w edytorze to poprawi.

W przypadku plików binarnych ten błąd pojawia się, jeśli brakuje biblioteki połączonej. Widziałem to często, gdy polecenia Go są kompilowane libc, ale działają na alpine with musllub scratch bez żadnych bibliotek. Musisz uwzględnić wszystkie brakujące biblioteki lub statycznie skompilować polecenie. Aby zobaczyć te linki do bibliotek, użyj ldd /your/appw swoim pliku binarnym.

Nie mogę komentować ze względu na mojego przedstawiciela, ale chciałem tylko dodać: dla użytkowników VSCode możesz zmienić zakończenia linii CRLF na LF, klikając CRLF na pasku stanu, a następnie wybierz LF i zapisz plik.

Miałem ten sam problem i to go rozwiązało.

Zastąpienie CRLF LF za pomocą Notepad ++

1. Funkcja Znajdź / zamień Notepad ++ całkiem dobrze radzi sobie z tym wymaganiem. Po prostu otwórz okno dialogowe Zamień (CTRL + H), wybierz Rozszerzony tryb wyszukiwania (ALT + X), wyszukaj „\ r \ n” i zamień na „\ n”:
2. Hit Zamień wszystko (ALT + A)

Przebuduj i uruchom obraz Dockera powinno rozwiązać problem.

Zwróć uwagę na podobny błąd, taki jak:

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

może się zdarzyć, jeśli architektura, dla której zbudowano obraz, nie jest zgodna z architekturą systemu. Na przykład, próbuje uruchomić obraz zbudowany na arm64na x86_64maszynie może generować ten błąd.

Dodaj to do swojego Dockerfile

RUN cat /run.sh | tr -d '\r' > /run.sh

Rozwiązuję ten problem, ustawiam ustawienia w vscode.

1. Plik
   1. Preferencje
      1. Ustawienia
         1. Edytor tekstu
            1. Akta
            2. Eol - ustaw na \ n

pozdrowienia

Znalazłem szczególny przypadek skrajny, w którym używałem tini init w kontenerze alpine , ale ponieważ nie używałem statycznie połączonej wersji, a Alpine używa domyślnie zainstalowanej biblioteki musl libc zamiast biblioteki GNU LibC, powodowała awarię z tym samym Komunikat o błędzie.

Gdybym to zrozumiał i poświęcił czas na poprawne przeczytanie dokumentacji, znalazłbym Tini Static , który po przejściu na rozwiązanie rozwiązał mój problem.