Postgres: Is there a way to add a script which will run always on container start

[harrybvp]

Currently scripts present inside docker-entrypoint-initdb.d/* will run only once (during initialization).

I have a script which does health checkup and I would like that script to be executed always i.e. whenever container starts.

One way could be to modify docker-entrypoint.sh but i was wondering if it's possible w/o modifying entrypoint script.

[yosifkit]

It is not something we had considered. Is it something that could be accomplished with HEALTHCHECK in your Dockerfile or in your docker run?

[harrybvp]

@yosifkit Thanks for response!
I have a requirement to do more than a health checkup (some business logic) on each container start.
I think it would be great to have that support in docker-entrypoint.sh

However for now , I created an Dockerfile with based image as postgres and added a RUN command to modify docker-entrypoint.sh using sed (inserting my logic somewhere in that entry point script).

[saikatguha]

I have another scenario which requires running a command each time the container is started. My build system outputs a generated script that adds database roles (if not exists) for currently enabled services. The new roles.sql file in the docker-entrypoint-initdb.d/ triggers a rebuild of the image. That triggers docker-compose to recreate the postgres container. The data directory comes from a persistent volume, however, and due its presence the new init scripts are not run even though they are written to handle existing data.

It would be useful to have the entrypoint trigger scripts for different events. e.g., docker-entrypoint-initdb.d/ for a brand spanking new containers like today, and scripts in docker-entrypoint-on-every-start.d/ every time a container is started.

[tianon]

It's a mongo example, but it should be applicable to postgres as well: https://github.com/docker-library/mongo/issues/249#issuecomment-381786889 (basically, start a process in the background that waits for the database to be up and ready before starting the database itself, then make sure it exits cleanly after the desired business logic is performed).

Closing, since we have no intention of explicitly supporting this in the image itself.