-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Built-in data, intermediate container and permision problems #319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
My guess is that the graph driver is too slow (since that is where the database files are stored in your image). From https://stackoverflow.com/a/32193782:
If it is the graph driver, then it might be that it is getting the "create new file" for |
Thanks for sharing your thoughts @yosifkit. This can explain the behaviour I'm seeing, although I'm not sure how to permanently fix it. Not an expert neither in docker nor in postgres, just a user of the magic of both :–) The buggy container that I have runs in the k8s environment and it looks like I was able to find a workaround. It was in setting livenessProbe:
exec:
command:
- /bin/sh
- -c
- psql -U postgres -c 'SELECT version()' || false
initialDelaySeconds: 20
periodSeconds: 20 When the container gets stuck, Hope this helps at least one person in a similar situation. Also hope to to see some suggestions on healtcheck e.g. as being discussed in #282. A permanent solution to the |
This one's a bit old (so I wouldn't be surprised if you found a different solution in the meantime), but I'd recommend still using a Since this is a bit of an esoteric use case (and the issues appear to be more use-related than image-related), I'm going to close. 👍 |
I was getting similar errors to this in docker-compose:
I tried an experiment:
After this, the file started to get refreshed every 30 seconds without any more errors. |
I'm trying to build a lightweight docker container that starts as quickly as possible with all the data built-in. The goal is to form a scalable kubernetes service that provides access to some immutable data.
Looks like the solution is to use a multi-stage build that was introduced by Docker recently. The data dump is being read from a backup inside an intermediate container and then all the
PGDATA
directories are moved to the actual container. The resulting image does not havedocker-entrypoint-initdb.d
, which makes it two times smaller and also speeds up the start, because all the required folders are already in place.Here is my Dockerfile:
I'm adding
--help
toRUN docker-entrypoint.sh --help
in the first stage just to trick the script – it otherwise does not start at all or launches a foreground process, which never exits.PGDATA
can't be a equal to its default value (/var/lib/postgresql/data
), because that's aVOLUME
and so things don't copy between the build stages.The resulting lightweight image does start and does serve the data, but fails after some time. The symptoms are similar to what's described here: https://forums.docker.com/t/beta-9-postgres-stat-files-corrupted-when-data-stored-on-host-mapped-volume/10819
I tried fixing things by
chown -R postgres:postgres /pgdata
andchomd -R 777 /pgdata
after everything else, but this did not help. The logs are still full of messages like theseWhat could this odd behaviour caused by?
The text was updated successfully, but these errors were encountered: