1

I'm trying to start PostgreSQL 11 as postgres user on a Debian 8.6 base system:

FROM xxx.amazonaws.com/groen/debian-jessie

ENV DEBIAN_FRONTEND noninteractive

ADD powerUp             /etc/my_runalways/startup-postgresql
RUN chmod -R 700        /etc/my_runalways/startup-postgresql
RUN sed -i '/updates/d' /etc/apt/sources.list

RUN apt-get update
RUN apt-get -y -q install wget
RUN apt-get --force-yes -y -q install postgresql-11 postgresql-client-11

USER postgres

RUN    /etc/init.d/postgresql start

but I'm experiencing a seemingly unrelated permission error originating in a config.json file:

Step 10/17 : RUN apt-get -y -q install postgresql-11 postgresql-client-11
 ---> Using cache
 ---> 676bf87b8145
Step 11/17 : USER postgres
 ---> Using cache
 ---> e54a93b7ba49
Step 12/17 : RUN    /etc/init.d/postgresql start
 ---> Running in 50d6fa1c1825
OCI runtime create failed: container_linux.go:345: starting container process caused "chdir to cwd (\"/root\") set in config.json failed: permission denied": unknown

I'm a bit bewildered by this message as this file exists on the host whereas this error happens inside the container (more correctly when building the image).

Working with a slimmed down version of the build, and logging in the resulting container, I try to emulate the error by manually executing the commands. This gives no errors however:

postgres@10f5e189ca95:~$ groups
postgres ssl-cert
postgres@10f5e189ca95:~$ ls -lrta /etc/init.d/postgresql
-rwxr-xr-x 1 root root 1490 Feb 21  2016 /etc/init.d/postgresql
postgres@10f5e189ca95:~$ /etc/init.d/postgresql start
[ ok ] Starting PostgreSQL 11 database server: main.
postgres@10f5e189ca95:~$ /etc/init.d/postgresql status
11/main (port 5432): online
postgres@10f5e189ca95:~$
Raf
  • 842
  • 1
  • 9
  • 25

1 Answers1

3

You have one practical problem and one lurking conceptual problem.

The practical problem is what your error message says. The current WORKDIR, which you've probably inherited from your base image, is /root, which is typically mode 0700 (that is, not accessible by anyone other than the root user). Your Dockerfile specifies USER postgres and then tries to RUN anything. Docker first tries to chdir(2) to the current WORKDIR, but it can't, because it doesn't have permission.

The easy workaround to this is to set the WORKDIR to anything else when you change users

USER postgres
WORKDIR /

Once you get past that you will hit one more thing. Each RUN command internally starts a new container, does its work, and exits, and any processes left running in that container are lost. Unless there's some side effects beyond starting the process, lines like RUN /etc/init.d/... start are no-ops.

Broadly you should assume that commands like /etc/init.d scripts, service, systemctl, and the like just don't work in Docker. (The other obvious place they "don't work" is as an image's CMD: the container will exit immediately.) Just run the daemon as the container's main process.

USER postgres
WORKDIR /var/lib/postgresql
CMD ["postgres"]

Consider just using the standard postgres image, if that's an option for you, which also covers some tricky corner cases around database initialization.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • the `WORKDIR` change did it. Actually I posted not all of the `Dockerfile` and I'm running Postgres as a supervised system service. In the Dockerfile I want to add some DB users, hence I need to start/stop the database when building the image – Raf Jul 03 '19 at 12:17
  • The standard database images have a facility to do that, generally by putting scripts into an `/docker-entrypoint-initdb.d` directory (either in a custom image or bind-mounting them at startup time). “Supervised system service” isn’t usually a Docker thing. – David Maze Jul 03 '19 at 12:50