PMG 5.x to 6.x in-place upgrade pitfalls?


Renowned Member
Feb 10, 2010
So, here we have a testsystem that we do also use for some regular mails (how should we test it otherwise :)).

it was created as PMG 5.x, then in-place-upgraded to 6.0, afterwards to 6.1.
(following of course)

today we saw a quite strange event: after its regular "sig hup" at 7:00AM the only thing reported by the pmgpolicy in mail.log is the database maintenance and its hourly "sig hup".

after a reboot the process reported something new: pmgpolicy[345]: ERROR: unable to load database
and afterwards: "pmgpolicy[348]: Can't call method "ping" on an undefined value at /usr/bin/pmgpolicy line 514." (which is strange in itself as there should be errorhandling to report a database-connection error)

so what happened - we do not exactly know when but the postgresql upgrade to v11 somehow was reverted by PMG as "/etc/pmg/templates/" still points the data_directory = '/var/lib/postgresql/9.6/main' -> obviously the wrong path and postgresql also complains about this during reboot.

now the big question would be - can we change the template somehow?

for the moment the /etc/postgresql/postgresql.conf is manually updated to reflect the new path to "/var/lib/postgresql/11/main"

after starting postresql this way things seem to go back to normal, except for this after the next regular "sig hup":
pmgpolicy[337]: ERROR: Can't call method "close" on unblessed reference at /usr/bin/pmgpolicy line 399.

so maybe the in-place "upgrade postgres database" could be more elaborated as we believed "pg_dropcluster --stop 11 main" and "pg_upgradecluster -v 11 9.6 main" would be the way to go, but it seems this is not everything that needs to be done.

thx for the quick reply.
fact is - we never changed any templates - so I guess changing the template during the inplace upgrade should be mentioned.
we did follow the upgrade-guide to the best of our knowledge, somehow the pg_dropcluster and pg_upgradecluster worked fine, but todays reboot brought 9.6 back in the template and therefore in postgresql.conf I guess.
If you have files in /etc/pmg/templates/ - these take precedence over the ones shipped in the packages in '/var/lib/pmg/templates' (and they need to get copied to /etc/pmg/templates by the admin of the PMG - it does not happen automatically)

just compare (using diff or vimdiff) '/etc/pmg/templates/' with '/var/lib/pmg/templates/' and adapt your '/etc/pmg/templates/' to the new paths.
(If you don't have anything which needs to be overriden in the postgresql.conf, it might be better to simply delete /etc/pmg/templates/
thanks for your clarification, I swear we never copied anything to /etc/pmg/templates/ yet there are a lot of files dated March 25th 2019 :)
will try removal of those files during the nighshift.
  • Like
Reactions: Stoiko Ivanov
No need to be sorry! - Happened to me quite often as well :)

Good luck with the upgrade - and let us know how it went!


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!