runc · Docker
Le message
standard_init_linux.go: exec user process caused: no such file or directory
Ce que cela veut dire
Le conteneur a voulu lancer son point d'entrée et le noyau a répondu « no such file » — et le piège, c'est que le fichier est bel et bien là. Les fins de ligne du script sont en CRLF : la première ligne se lit donc #!/bin/sh\r et le noyau cherche un interpréteur littéralement nommé sh\r ; un clone sous Windows ou l'autocrlf de git activé produit exactement cela. dos2unix entrypoint.sh convertit ce fichier (ou sed -i 's/\r$//' entrypoint.sh à défaut), et une ligne *.sh text eol=lf dans .gitattributes empêche le retour. Nommer dans le #! un interpréteur absent de l'image — bash dans une image alpine — donne le même texte.
Le correctif
dos2unix entrypoint.sh- Émis par
- runc
- Docker
- 12
Les erreurs de Docker ne deviennent lisibles qu'une fois rangées par couche — le client qui n'atteint pas le démon, le registre qui refuse, un RUN qui échoue au build, un conteneur qui meurt dès son démarrage sont quatre problèmes distincts — et pour les couches build et exécution, la ligne n'est pas la raison : la raison est dans la sortie de la commande qui tournait à l'intérieur, tandis que le coût de chaque correctif varie aussi selon la couche.
Lire un message d’erreur
- Lisez à partir de la première ligne. Plus on descend, plus il s’agit des entrailles de l’outil ; la cause est généralement en haut.
- S’il y a un fichier et un numéro de ligne, commencez là — pas la première image de la pile, mais la ligne la plus haute qui nomme un fichier de vous.
- Cherchez le message tel quel, mais retirez d’abord vos chemins et vos noms de variables : c’est cela qui empêche la correspondance.
- La même situation se formule autrement selon la version de l’outil. Si les résultats sonnent faux, ajoutez le numéro de version.
- Avant de coller un correctif, vérifiez ce qu’il jette. Certains sont irréversibles.
Questions fréquentes
Q. Que veut dire « standard_init_linux.go: exec user process caused: no such file or directory » ?
Le conteneur a voulu lancer son point d'entrée et le noyau a répondu « no such file » — et le piège, c'est que le fichier est bel et bien là. Les fins de ligne du script sont en CRLF : la première ligne se lit donc #!/bin/sh\r et le noyau cherche un interpréteur littéralement nommé sh\r ; un clone sous Windows ou l'autocrlf de git activé produit exactement cela. dos2unix entrypoint.sh convertit ce fichier (ou sed -i 's/\r$//' entrypoint.sh à défaut), et une ligne *.sh text eol=lf dans .gitattributes empêche le retour. Nommer dans le #! un interpréteur absent de l'image — bash dans une image alpine — donne le même texte.
Q. Comment le corriger ?
dos2unix entrypoint.sh — avant de le lancer, vérifiez plus haut ce que cette commande jette.
Q. Quel outil émet cela ?
runc. Cela relève de Docker, et le message compte 10 mots.