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

Many thanks, Alana!

I can confirm, that the proget:24.0.37-ci.2 container image works like a charm

Thanks for the quick fix!

• Fritz

Just tried migration of an old legacy Debian feed to a normal Debian feed. No errors were reported during the migration and in proget's web-UI, everything looks fine. However the feed is unusable with apt on any distro.

When running apt-get update (or apt update), it complains about the Packages file not being parsable like this:

Reading package lists... Error!
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/proget.graudatastorage.intern_debian_XTC-deb_dists_jammy_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

If I look at the file mentioned above, It turns out, apt is correct in that there are multiple errors:

• Each package record MUST begin with the Package: field. Proget puts this field in between the other fields.
• Between the Size: field and the Filename: field, Proget puts an empty line which does not belong there. Empty line are reserved as record separators.

I also noticed some inconvenience with the Migration itself:

When migrating, proget uses the name of the legacy feed as Distro for the new feed. So if I want one of the usual Distro names (e.g. like bookworm), then I have to rename the old feed accordingly before starting the Migration. This might impact availability. It would be easier, if the Distro name could be entered manually when starting the migration.

Proget version: 2024.36 (Build 5) running in a docker container
Cheers
-Fritz