2

When creating a generic container is there a better way than running an endless ping or tail to keep the container from exiting?

FROM ubuntu

RUN apt-get update && \
    apt-get install -y \
    python-pip

VOLUME /flask

EXPOSE 8080:8080

CMD ["tail", "-f", "/dev/null"]

All other attempts at keeping a process running exit with code 0, after running docker-compose up

brgalloway
  • 31
  • 2
  • 4
  • Can you clarify the purpose of keeping a container running that has no useful process? – Jason Martin Jun 03 '17 at 03:34
  • 2
    @JasonMartin this is all for building custom images from a Dockerfile and containers from docker-compose based on that image. Say that you are building a container that doesn't have a useful process yet, but needs to be in a running state in order to test commands against, to further flesh out the container. If the Dockerfile doesn't have a proper CMD or Entrypoint when docker compose is called it will exit; making it difficult to then log in to the container and execute commands or code. I just felt it was a little bit of a hack to hold it open with tail or ping. – brgalloway Jun 03 '17 at 07:15
  • Sleep 9999999999 is probably reasonable as well. The container is already in a sort of nonstandard state since its being held open for testing, so the sleep or tail is no worse. – Jason Martin Jun 03 '17 at 22:32

1 Answers1

1

This is expected behavior for "docker-compose up". From the docs (here)

The docker-compose up command aggregates the output of each container. When the command exits, all containers are stopped. Running docker-compose up -d starts the containers in the background and leaves them running.

dmcgrandle
  • 121
  • 6
  • 4
    No matter if it's in the foreground or background `docker-compose -d ` will not hold a container open once the process has exited. The -d option will push the process to the background and give you access back to the command prompt; yes that part is correct. – brgalloway Jun 03 '17 at 07:23
  • Ah, got it. Thanks for clarifying. Containers exiting when the process is complete is expected behavior. ;) (Yes, I know you are trying to get around that default behavior) :) – dmcgrandle Jun 04 '17 at 05:43