docker stop && docker rm doesn't really get rid of my container

I have some weird behaviour when working with the postgres image.

I’ve created a script which is mounted into /docker-entrypoint-initdb.d and using single-user mode to initialise the database.

  • docker-compose does not launch
  • ENV[“VARIABLE”].encoding return #<Encoding:ASCII-8BIT> on production when being assigned a unicode string
  • `docker run ubuntu:14.04 /bin/echo` produces SELinux error on Fedora 20
  • Docker-compose mounts are going to work with TCP host?
  • How to build and run a java instance in Docker
  • All images and containers disappeared after host kernel downgrade
  • However, when I update the script, run

    docker stop postgres_db
    docker rm postgres_db

    and than start a new container, the database is the old one. It doesn’t change.

    I’m using vagrant box-cutter/ubuntu1404-docker and when I run

    vagrant destroy -f
    vagrant up

    and than recreate the new docker container, the changes are applied.

    Why doesn’t it work when I just remove the old container and start a new one? Where does docker keep it’s cache which I could purge to really get a new image?


    The exact docker file I’m using is a small extension to the original one. It just installs the orafce plugin link, content:

    FROM postgres:9.4
    RUN apt-get update && \
        apt-get install -y postgresql-9.4-orafce && \
        rm -rf /var/lib/apt/lists/*

    the command I use to start a new container is:

    docker run --name="postgres_db" \
               --restart="always" \
               -e POSTGRES_PASSWORD=PostgresPassword \
               -p 5432:5432 \
               -v /data:/var/lib/postgresql/data \
               -v /vagrant/container_data/init_scripts:/docker-entrypoint-initdb.d \
               -v /vagrant/container_data/tmp:/tmp \
               -d grmanit/postgres

    the init_scripts folder contains one script which creates a new database and a new user.


    When I change the script in my init_scripts folder, for instance modify the database name, and than stop+remove the old container and start a new one, it doesn’t have any effect.

    When I change the password of postgres, which is set as an environment variable in the docker run command (in this example it’s PostgresPassword) and again stop+remove the old container and than start a new one with the new environment variable, it again doesn’t have any effect. I still need to use the old password to connect to the db and the new one wouldn’t work.

    But when I destroy the VM and start it up again, I have the configurations which I had defined before. However changing them again needs me to destroy and restart the VM which takes much longer than just destroying a docker container and starting up a new one.

  • Docker timeout while fetching image on Debian host
  • Running Disco in a Docker container
  • Run postgresql docker image with persistent data returns permission error
  • Docker image error: “/bin/sh: 1: [python,: not found”
  • How to transmit a single image layer for reconstructing the image later on?
  • Can't access OpenShift console on http://ip:8443
  • One Solution collect form web for “docker stop && docker rm doesn't really get rid of my container”

    You get a new container, but -v /data:/var/lib/postgresql/data mounts the /data directory of the host into the container, making changes to the database persistent between containers. If you omit that, the database will be isolated in the container and will disappear as soon as you delete the container.

    See Managing data in containers (Docker documentation) for details.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.