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