CODEWITHSUNDEEP
linuxdockeralpine-linux
Twiggeh
Twiggeh

Reputation: 1160

File not found in Alpine Container, despite existing

Screenshot of the existing file and that alpine says that the file could not be found

I have an Alpine container that I copy a binary to (in this case it is spar). The entry point is dumb-init /usr/bin/spar but it results in a No such file or directory. When I run sh inside of the container, /usr/bin/spar exists. Trying to run it in

  1. dumb-init ...
  2. /usr/bin/spar / spar from /
  3. ./spar / spar from usr/bin/

All result in the same error. I tried changing the permissions with chmod 777 /usr/bin/spar giving everyone full access, still no luck.

Am I missing something that is specific to alpine? In another SO issue someone mentioned that switching from Alpine to Ubuntu solved their issue, but no further info was provided.

Here is the dockerfile that creates the image(s)

ARG intermediate=quay.io/wire/alpine-intermediate
ARG deps=quay.io/wire/alpine-deps

#--- Intermediate stage ---
FROM ${intermediate} as intermediate

#--- Minified stage ---
FROM ${deps}

ARG executable
ENV CACHEDEXECUTABLE ${executable}

COPY --from=intermediate /dist/${executable} /usr/bin/${executable}

# TODO: only if executable=brig, also copy templates. Docker image conditionals seem hacky:
# https://stackoverflow.com/questions/31528384/conditional-copy-add-in-dockerfile
# For now, adds ~2 MB of additional files into every container
COPY --from=intermediate /dist/templates/ /usr/share/wire/templates/

# ARGs are not available at runtime, create symlink at build time
# more info: https://stackoverflow.com/questions/40902445/using-variable-interpolation-in-string-in-docker
RUN ln -s /usr/bin/${executable} /usr/bin/service
ENTRYPOINT /usr/bin/dumb-init /usr/bin/${CACHEDEXECUTABLE}

Upvotes: 2

Views: 3338

Answers (1)

BMitch
BMitch

Reputation: 265218

If spar is a binary, that binary exists in the container, and you call it directly or it's in the containers path, then the two likely reasons for a file not found are:

  1. Dynamically linked libraries that don't exist inside the container. E.g. of you run ldd spar it will show you those links, and there's a good chance you'll see libc despite trying to run on Alpine where it uses musl.

  2. The binary is for another platform/architecture, and you have binfmt_misc setup, but without the --fix-binary option so it's looking for the interpreter path in the container filesystem rather than the host. This will be visible by the lack of an F flag in the /proc file for that platform.

Upvotes: 3

Related Questions