runc · Docker
Die Meldung
standard_init_linux.go: exec user process caused: no such file or directory
Was es bedeutet
Der Container wollte seinen Entrypoint starten, und der Kernel antwortete „no such file“ — die Falle ist, dass die Datei offensichtlich vorhanden ist. Die Zeilenenden des Skripts sind CRLF, die erste Zeile liest sich also als #!/bin/sh\r, und der Kernel sucht einen Interpreter, der wörtlich sh\r heißt; ein Klon unter Windows oder ein aktives autocrlf in git erzeugt genau das. dos2unix entrypoint.sh wandelt diese eine Datei um (ohne dos2unix: sed -i 's/\r$//' entrypoint.sh), und eine Zeile *.sh text eol=lf in .gitattributes verhindert die Wiederkehr. Ein Interpreter im #!, den das Image nicht hat — bash in einem alpine-Image — ergibt denselben Wortlaut.
Die Lösung
dos2unix entrypoint.sh- Ausgegeben von
- runc
- Docker
- 12
Docker-Fehler werden erst lesbar, wenn man sie einer Schicht zuordnet — der Client erreicht den Daemon nicht, die Registry verweigert, ein RUN scheitert im Build, ein Container stirbt sofort beim Start: das sind vier verschiedene Probleme — und in der Build- und Laufzeitschicht ist die Zeile selbst nicht der Grund: der Grund steht in der Ausgabe des Befehls, der darin lief, und auch der Preis jeder Behebung unterscheidet sich je Schicht.
Eine Fehlermeldung lesen
- Von der ersten Zeile abwärts lesen. Weiter unten geht es um das Innere des Werkzeugs; die Ursache steht meist oben.
- Gibt es Datei und Zeilennummer, dort anfangen — nicht der oberste Stack-Frame, sondern die oberste Zeile, die eine eigene Datei nennt.
- Die Meldung wörtlich suchen, vorher aber eigene Pfade und Variablennamen entfernen; genau die verhindern den Treffer.
- Dieselbe Lage wird je Werkzeugversion anders formuliert. Passen die Treffer nicht, die Versionsnummer mit in die Suche.
- Vor dem Einfügen einer Lösung prüfen, was sie verwirft. Manches davon lässt sich nicht zurückholen.
Häufige Fragen
Q. Was bedeutet „standard_init_linux.go: exec user process caused: no such file or directory“?
Der Container wollte seinen Entrypoint starten, und der Kernel antwortete „no such file“ — die Falle ist, dass die Datei offensichtlich vorhanden ist. Die Zeilenenden des Skripts sind CRLF, die erste Zeile liest sich also als #!/bin/sh\r, und der Kernel sucht einen Interpreter, der wörtlich sh\r heißt; ein Klon unter Windows oder ein aktives autocrlf in git erzeugt genau das. dos2unix entrypoint.sh wandelt diese eine Datei um (ohne dos2unix: sed -i 's/\r$//' entrypoint.sh), und eine Zeile *.sh text eol=lf in .gitattributes verhindert die Wiederkehr. Ein Interpreter im #!, den das Image nicht hat — bash in einem alpine-Image — ergibt denselben Wortlaut.
Q. Wie behebe ich das?
dos2unix entrypoint.sh — vor dem Ausführen oben prüfen, was dieser Befehl verwirft.
Q. Welches Werkzeug gibt das aus?
runc. Es gehört zu Docker, und die Meldung hat 10 Wörter.