Dockerfile run entrypoint before shell entrypoint

I’m wanting to do some last minute setup on run before passing arguments to the shell entrypoint, to accomplish this I have the following in mind.

ENTRYPOINT ./run_binary ${args}; /bin/sh -c
CMD ./run_binary

However, by doing this, it doesn’t seem that any CMD arguments make it to the shell entrypoint. Is there a way around this? I’m just wanting to run a setup step on a binary before handing back control to the shell entrypoint (and then to the USER via CMD).

  • Kubernetes - Readiness Probe execution after container started
  • What are the differences between dockerfile and stackbrew users on docker hub
  • Docker Compose how to extend service with build to use an image instead
  • Docker container not removing
  • Docker as a Proxy server for a web service
  • bash script command “trap” doesn't work in docker container
  • Docker-compose environment variables
  • Issue while indexing data in solr in docker cluster setup
  • docker build is very slow even with simple commands
  • Unable To Disconnect Docker Container From Network
  • Mount a host file as a data volume in docker
  • How to test dockerignore file?
  • 2 Solutions collect form web for “Dockerfile run entrypoint before shell entrypoint”

    You could use an intermediate build image that triggers an ONBUILD statement from your original Dockerfile, see:

    The ONBUILD instruction adds to the image a trigger instruction to be
    executed at a later time, when the image is used as the base for
    another build. The trigger will be executed in the context of the
    downstream build, as if it had been inserted immediately after the
    FROM instruction in the downstream Dockerfile.

    This is useful if you are building an image which will be used as a
    base to build other images, for example an application build
    environment or a daemon which may be customized with user-specific

    Regarding CMD and ENTRYPOINT, see:

    1. Dockerfile should specify at least one of CMD or ENTRYPOINT
    2. ENTRYPOINT should be defined when using the container as an
    3. CMD should be used as a way of defining default arguments for an
      ENTRYPOINT command or for executing an ad-hoc command in a
    4. CMD will be overridden when running the container with alternative

    CMD becomes a list of arguments to send to ENTRYPOINT when both are specified, see the manual, so that’s not the way to go

    but you could use a .sh script as ENTRYPOINT, that first executes your binary command and then forwards the received arguments to a shell

    I haven’t tried it but something along the lines of

    /bin/sh -c "$@"
    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.