proget-postgres test does not survive container disposal/recreation

inedo_1308

Hi,

I know this is experimental Hopefully this helps you guys improving this cool feature.

I was testing proget in a podman/quadlet environment running on a virtualized Rocky9 (RHEL9 clone). First startup with mssql and migration to postgres went well and everything worked so far. However when the container is stopped&destroyed and then recreated, the postgres process does not startup.

I made the following observations:

Initially, the postgres db is created in (/var/proget/packages/database) and it belongs to uid/gid 101/104 which matches postgres/postgres inside the container. Also the special files .preferpgsql and .pgsqlconn are created.
When the new container instance is starting, this changes ownership of the whole hierarchy to root/root which then - obviously - cannot be used by postgres anymore.
Either the postgres process is not startetd at all, or it terminates immediately.
Consequently, proget complains in the log like this:

Cannot connect to database; will retry in 1 second... Full error: Failed to connect to 127.0.0.1:5728

I can remedy the situation manually by running the following (first line enters a shell inside the running container, rest runs inside the container):

podman exec -it systemd-proget /bin/bash
chown -R postgres:postgres /var/proget/packages/database
rm -f /var/proget/packages/database/postmaster.pid
su -g postgres postgres -c ". /var/proget/packages/database/postmaster.opts"

My conclusions:

The existence of /var/proget/packages/database/postmaster.pid suggests an unclean termination of postgres
The change of ownership of the db directory during startup should be fixed. Perhaps it would be wiser, NOT to use a subdir of the packages, but a separate volume.
Is there an attempt to start the postgres process at all?

Cheers
-Fritz

Forgot to mention the image i used:
proget.inedo.com/productimages/inedo/proget-postgres:24.0.37-ci.2

gdivis

Hi Fritz,

We appreciate the feedback on this! ProGet 2025 will indeed have a separate dedicated mount for the database, but we didn't include this in the preview. As to the other issues, yes we do have a supervisor that attempts to start postgres and perform a clean shutdown on container stop... but there are some bugs we are working through, likely made worse by the ownership issues you discovered.

These concerns will absolutely be addressed before launch.

Again, thanks for trying it out and please let us know of any other issues you find or suggestions you may have!

-Greg