Can't execute dockerize binary: No such file or directory

[antipin]

After the last update of a dockerize base image my containers that depends on dockerize all failed with bash: /usr/local/bin/dockerize: No such file or directory error. Although dockerize is in its place inside container and /usr/local/bin/ in PATH.

For example, following Dockerfile brings this issue.

FROM jwilder/dockerize AS dockerize
FROM nginx

COPY --from=dockerize /usr/local/bin/dockerize /usr/local/bin/dockerize
COPY ./nginx.conf /etc/nginx/nginx.conf

ENTRYPOINT [ "dockerize", "-template", "/etc/nginx/nginx.conf:/etc/nginx/nginx.conf" ]
CMD nginx

Does anyone meet this issue?

By the way, it would be great to tag images that are available on dockerhub, because for now there is no way to roll back to previous stable version – there is only :latest build.

[antipin]

Although this way of building container works fine:

FROM nginx:1.13.6

RUN apt-get update && apt-get install -y wget
ENV DOCKERIZE_VERSION v0.5.0
RUN wget https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
    && tar -C /usr/local/bin -xzvf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
    && rm dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz

COPY ./nginx.conf /etc/nginx/nginx.conf

ENTRYPOINT [ "dockerize", "-template", "/etc/nginx/nginx.conf:/etc/nginx/nginx.conf" ]
CMD nginx

[mnrozhkov]

I had the same issue. @antipin thanks for the solution! It works for me

[jwilder]

Not sure what changed off-hand. I pushed up 0.4.0 and 0.5.0 tags. I thought docker hub was building the tags automatically, but looks like that isn't working.

[at15]

I think the cause might be alphine does not have glibc, I had similar issue today, after switching to a non alpine image this issues is gone.

In my case I compiled go binary on my local machine (w/ cgo enabled by default), then copied it to a image based from alpine (java:8-alpine). though the error message 'No such file or directory' is quite confusing (found some info on so )

https://superuser.com/questions/1176200/no-such-file-when-it-exists

The shell will report an ambiguous "No such file or directory" for an executable when the shell cannot find a dependency for that executable

btw: might consider update the go version in dockerfile, it's still using 1.8 and 1.10 is already released

[nicolasmure]

I had the same issue with v0.6.1. Usually, the bash: /usr/local/bin/dockerize: No such file or directory message appears on executables when the shebang points to an unavailable executer.
Weird thing is that the dockerize bin is supposed to be self contained.
Not really sure if this helps 🤔

[korbin]

If compiled with CGO_ENABLED=0, the resulting binary is completely statically-linked with no dependency on a dynamically-linked libc.

I pushed a build at korbin/dockerize:latest on Dockerhub with this env var added.

#132

[vlcinsky]

@nicolasmure your observation (missing executable in shebang) helped as it allowed me to fix my case.

@korgin I wonder, if statically linked golang binary is going to ignore shebang or not. Take into consideration, that shebang may contain important information for executing it's code, e.g. when it refers to python, awk or whatever else.

To me the fix of this issue requires fix on the script size, not with dockerize executable.

If we say: If you get "No such file or directory", double check, if all yours scripts have valid shebang referring to existing binaries., we may close this issue.

[jlenos-inflight]

I came across the same problem and solved it by modifying permissions before calling dockerize.

RUN chmod 755 /usr/local/bin/dockerize

[jwilder]

Closing — the root cause was identified in the comments: the binary was compiled with CGO enabled, producing a dynamically-linked binary that requires glibc, which is not available on Alpine (musl-based). This has been fixed — dockerize is now built with CGO_ENABLED=0 producing a fully static binary, and Alpine-specific builds are available. The release pipeline in #278 ensures all binaries are statically linked.