2
votes

Comment réparer "le processus utilisateur exécutable n'a causé aucun fichier ou répertoire de ce type"

J'essaye d'utiliser tini dans mon Dockerfile mais j'obtiens une erreur.

J'ai utilisé l'exemple de code du fichier readme tini .

# ... code which builds /app/foo

# Add Tini
ENV TINI_VERSION v0.18.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--"]

# Run the program when the container starts
CMD ["/app/foo"]

Je m'attends à ce que mon programme s'exécute sans avoir PID=1 mais à la place j'obtiens: standard_init_linux.go:207: exec user process caused "no such file or directory"

ÉDITER:

/app/foo est créé au début du Dockerfile. Il n'y a aucun problème avec /app/foo . Pour preuve de cela, si je commente la ligne ENTRYPOINT (ou si je supprime tout le code lié à tini ), my /app/foo fonctionne bien, sauf pour le fait qu'il a PID=1

docker

9 commentaires

Mauvaise architecture; la chose qui est téléchargée est en fait un fichier tar ou une page HTML; manque des bibliothèques partagées (surtout si vous êtes en cours d' exécution sur une scratch d' image sans libc); ...

Où avez-vous créé / app / foo?

@BMitch, / app / foo est créé au début du Dockerfile. J'ai édité la question pour clarifier.

@JoelFan dans ce cas, le processus qui rend / app / foo n'est pas correct. Je ne peux pas vraiment déboguer un commentaire.

Publier les résultats de docker exec <container-name> sh -c 'ls /app

Peut-être qu'au lieu de nous dire à quoi ressemble le Dockerfile, montrez-nous simplement le Dockerfile réel. Notez également qu'au lieu d'utiliser tini vous pouvez simplement utiliser l'option --init pour docker run .

@larsks, c'est la partie pertinente du Dockerfile. Apparemment --init ne fonctionne pas avec docker-compose , ce que j'utilise

Bien sûr, ce n'est pas quelque chose que vous passeriez à la ligne de commande docker-compose ; c'est un attribut sur les services.

Je l'ai fait fonctionner avec "init: true" (et en supprimant tout le code tini et ENTRYPOINT ) dans une certaine mesure .... Mon processus n'a plus PID = 0 ... Cependant, la transmission du signal ne fonctionne pas ... quand j'appuie sur Ctrl-C, mon processus ne reçoit pas le signal ... je vais créer une nouvelle question pour cela

3 Réponses :

3
votes

Comme David le mentionne, vous devez vérifier ce qui est téléchargé. Si vous l'exécutez manuellement dans une image Alpine, vous verrez le problème exact:

ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static /tini

Notez la partie liée dynamiquement et le fait qu'elle recherche la libc. L'erreur dans un scénario alpin vous indique que la libc n'existe pas. Vous verriez également cela avec une image à gratter.

Vous voudrez soit obtenir une version de tini qui est complètement compilée statiquement, soit passer à un système avec la libc installée. Pour le premier, avec tini, c'est aussi simple que de télécharger une URL différente:

$ docker run -it --rm alpine /bin/sh
/ # apk add file
...
/ # apk add curl
...
/ # curl -sSL https://github.com/krallin/tini/releases/download/v0.18.0/tini >tini
/ # chmod 755 tini
/ # file tini
tini: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=38c262787814dc459678c8f24710bbde944b7e56, stripped
/ # ldd tini
        /lib64/ld-linux-x86-64.so.2 (0x7f1beab2a000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f1beab2a000)
Error relocating tini: __fprintf_chk: symbol not found
/ # ./tini
/bin/sh: ./tini: not found
/ # ls -al /lib64/ld-linux-x86-64.so.2
ls: /lib64/ld-linux-x86-64.so.2: No such file or directory

0 commentaires

3
votes

Une autre cause du problème répertorié ci-dessus peut être qu'un script est appelé qui utilise un shell non disponible. Par exemple, lorsque la première ligne du script est

#!/bin/sh

Ensuite, cela nécessite bash sur le système. Changer bash en sh(ell) par défaut pour le système peut être une solution. Alors, remplacez par

#!/bin/bash

0 commentaires

1
votes

Autre cause: une ligne incorrecte se termine dans le fichier. Linux attend des LF , et si votre hôte est Windows, le script que vous souhaitez exécuter aura des CRLF .

0 commentaires