<p>Disclaimer: This is very much an anti-pattern since it looks like you are trying to create something similar to a VM, or at the very least a pet that you modify in place rather than making all your changes via code and redeploying a new container for each change.</p>

<p>That disclaimer aside, you just need a command that will hang indefinitely. The most common one I've seen in a <code>tail -f /dev/null</code>, e.g.:</p>

<pre><code>FROM ubuntu:18.04

RUN apt update \
 &amp;&amp; apt install -y \
      cmake \
      curl \
      git \
      jq \
      libasound2-dev \
      libglu1-mesa-dev \
      libgtk2.0-dev \
      libjack-jackd2-dev \
      libx11-dev \
      libxcursor-dev \
      libxinerama-dev \
      libxi-dev \
      libxrandr-dev \
      zlib1g-dev

CMD [ "tail", "-f", "/dev/null" ]
</code></pre>

<p>I've also rearranged the Dockerfile to merge the update and install commands, this is a best practice for Dockerfile's since it avoids having a stale <code>apt update</code> command used from the cache when you change the <code>apt install</code> command months later. Also, putting each package on a separate line is better for version control to see what changed if you add a single new package.</p>

<p>When using this, you would <code>docker run -d --name your_container your_image</code> to run it in the background, and then <code>docker exec -it your_container /bin/bash</code> to open a shell.</p>

CC BY-SA 4.0
2019-04-08T13:57:39.783Z
Thanks. My use case is I want to have a container with all the libraries I need to compile some code I'm working on. So the source code is external to the container and connected via volume. When you say this is an antipattern, are you saying I shouldn't use Docker for this?
interstar
CC BY-SA 4.0
2019-04-08T14:01:07.037Z
@interstar I'm saying you would typically run the build with your code as the `docker build` process and include the resulting binary in a release image, usually with a multi-stage build. What I'm steering you away from is having a persistent mutable environment that would take time to recreate if a `docker rm` was run on your container.
BMitch
CC BY-SA 4.0
2019-04-08T16:12:31.360Z
No. Sure. I'm not trying to make a mutable container. Once I try to compile my code inside, and discover what other dependencies are missing then I'll be adding them in the Dockerfile
interstar
CC BY-SA 4.0
2019-04-08T13:55:27.557Z
2019-04-08T13:55:27.557Z
BMitch
<p>I'm testing a Docker container for development. And at the moment I just want to provision it with some libraries. After which I want to connect to it and test that I have all the libraries I need.</p>

<p>At the moment, my Dockerfile is just</p>

<pre><code>FROM ubuntu:18.04

RUN apt update
RUN apt install -y git curl cmake libx11-dev libglu1-mesa-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev zlib1g-dev libasound2-dev libgtk2.0-dev libjack-jackd2-dev jq
</code></pre>

<p>But once it finishes building it terminates.</p>

<p>What CMD should I put at the end to keep it alive so I can shell in from another terminal?</p>

<docker><containers>
How do I create a Docker container which just waits to be shelled into?
interstar
# How do I create a Docker container which just waits to be shelled into?

(Asked by: username_0 on 2019-04-08)

I'm testing a Docker container for development. And at the moment I just want to provision it with some libraries. After which I want to connect to it and test that I have all the libraries I need.
At the moment, my Dockerfile is just
FROM ubuntu:18.04

RUN apt update
RUN apt install -y git curl cmake libx11-dev libglu1-mesa-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev zlib1g-dev libasound2-dev libgtk2.0-dev libjack-jackd2-dev jq

But once it finishes building it terminates.
What CMD should I put at the end to keep it alive so I can shell in from another terminal?

**Tags:** docker, containers


---

## 1 answers

### Answer by username_1 on 2019-04-08. Score: 1 | Accepted answer

Disclaimer: This is very much an anti-pattern since it looks like you are trying to create something similar to a VM, or at the very least a pet that you modify in place rather than making all your changes via code and redeploying a new container for each change.
That disclaimer aside, you just need a command that will hang indefinitely. The most common one I've seen in a tail -f /dev/null, e.g.:
FROM ubuntu:18.04

RUN apt update \
 && apt install -y \
      cmake \
      curl \
      git \
      jq \
      libasound2-dev \
      libglu1-mesa-dev \
      libgtk2.0-dev \
      libjack-jackd2-dev \
      libx11-dev \
      libxcursor-dev \
      libxinerama-dev \
      libxi-dev \
      libxrandr-dev \
      zlib1g-dev

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

I've also rearranged the Dockerfile to merge the update and install commands, this is a best practice for Dockerfile's since it avoids having a stale apt update command used from the cache when you change the apt install command months later. Also, putting each package on a separate line is better for version control to see what changed if you add a single new package.
When using this, you would docker run -d --name your_container your_image to run it in the background, and then docker exec -it your_container /bin/bash to open a shell.

> **Comments:**
> **username_0**: Thanks. My use case is I want to have a container with all the libraries I need to compile some code I'm working on. So the source code is external to the container and connected via volume. When you say this is an antipattern, are you saying I shouldn't use Docker for this?  
> **username_1**: @username_0 I'm saying you would typically run the build with your code as the `docker build` process and include the resulting binary in a release image, usually with a multi-stage build. What I'm steering you away from is having a persistent mutable environment that would take time to recreate if a `docker rm` was run on your container.  
> **username_0**: No. Sure. I'm not trying to make a mutable container. Once I try to compile my code inside, and discover what other dependencies are missing then I'll be adding them in the Dockerfile  

---

