mjstealey / irods-provider-postgres Goto Github PK

Add previous 4.2.x versions

• Debian:jessie based
• PostgreSQL 9.6
• 14.04 Trusty iRODS packages

When an --env-file is provided (as in Example 2), the setup_irods.py script eats 100% of the CPU and never completes. This is true even when the --env-file contains the exact same values specified by the ENV directives in the dockerfile. It also occurs when using the environment file provided in Example 2.

The docker container fails when ran from the image. I was following the example: Persistent Data when I encountered the error. Here are the steps I took...

1. I pulled the image.
   ($ sudo docker pull mjstealey/irods-provider-postgres:latest)

2. After that I made the volumes on the host for var_irods, var_pgdata, and etc_irods.
   ($ sudo mkdir var_irods)

3. Then the container fails by exiting in the first second when I run it.
   ($ sudo docker run -d --name provider -h irods-provider -v /var/provider/var_irods:/var/lib/irods -v /var/provider/etc_irods:/etc/irods -v /var/provider/var_pgdata:/var/lib/postgresql/data mjstealey/irods-provider-postgres:latest -i run_irods)

I tried runnning it again with the -ti flag instead of -d and got the following message.

cp: cannot create regular file '/var/lib/postgresql/data/postgresql.tar.gz': Permission denied

Attempting to start a container with pre-existing configuration/database/"vault" fails within 20 seconds of the run command with no obvious cause. Two separate test cases have the same result:

• A container with no volumes mounted, but which has been stopped and restarted.
• A new container which has volumes mounted as in Example 3, where the volumes possess configuration and database files from a previous setup.

In essence, this feature interferes with trying to persist data through a stop-start cycle.

The irods provider is failing to restart after the container has been removed when using named volumes. I have been able to work around this error with bind mounts you originally presented. I wanted to bring this to your attention @mjstealey just in case anyone else is experiencing this when using named volumes. Here is the error code.

2017-11-16 17:13:55.550 UTC [48] FATAL: data directory "/var/lib/postgresql/data" has group or world access
2017-11-16 17:13:55.550 UTC [48] DETAIL: Permissions should be u=rwx (0700).

My OS is Centos 7 Atomic Host.
Here are the commands I ran to produce the error.

1. $ docker pull mjstealey/irods-provider-postgres:latest

2. $ docker run -ti --name provider -h irods-provider -v var_irods:/var/lib/irods:z -v etc_irods:/etc/irods:z -v var_pgdata:/var/lib/postgresql/data:z mjstealey/irods-provider-postgres:latest -i run_irods

3. $ docker stop provider

4. $ docker rm provider

5. $ docker run -ti --name provider -h irods-provider -v var_irods:/var/lib/irods:z -v etc_irods:/etc/irods:z -v var_pgdata:/var/lib/postgresql/data:z mjstealey/irods-provider-postgres:latest -x run_irods

Here is an example of a working command with bind mounts.

$ docker run -ti --name provider -h irods-provider -v /var/lib/docker/var_irods:/var/lib/irods:z -v /var/lib/docker/etc_irods:/etc/irods:z -v /var/lib/docker/var_pgdata:/var/lib/postgresql/data:z mjstealey/irods-provider-postgres:latest -i run_irods

Ref: #7

This permissions issue was cause by SE Linux. It was solved when adding a :z to the end of the volume mount.

($ docker run -ti --name provider -h provider -v /home/browe/var_irods:/var/lib/irods:z -v /home/browe/etc_irods:/etc/irods:z -v /home/browe/var_pgdata:/var/lib/postgresql/data:z mjstealey/irods-provider-postgres:4.2.2 -i run_irods)

Revise builds for 4.1.x versions back to 4.1.8 and include here

• 4.1.11
• 4.1.10
• 4.1.9
• 4.1.8