• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

psadump complains about pg_ctl

J

jdstevens

Guest
I submit

/usr/local/psa/bin/psadump --nostop -f /tmp/

as the root user. An early message in the log file is:

Checking packages installation ... done
Check postgres database existing ... found postgres database(s).
Check Postgres server running ... pg_ctl: cannot be run as root
Please log in (using, e.g., "su") as the (unprivileged) user that will
own the server process.
is not running

The psadump proceeds, but doesn't appear to properly handle anything related to postgresql.

Suggestions?
 
You wouldn't be happening to be running Red Hat Enterprise Linux would you? If so, I'm having the same problem, but trying to run psarestore on a new server.

This is a known issue and I was told by Plesk support that it will be fixed in 7.5.2. That should be coming out this week or the next.

Hope that helps
 
I'm using Fedora Core 2. I created a way to work around the problem. I don't think this creates a security risk, but I can't guarantee that.

mv /usr/bin/pg_ctl /usr/bin/pg_ctl.orig

Create a new /usr/bin/pg_ctl that looks like this:

#!/bin/sh -x
su - postgres -c "/usr/bin/pg_ctl.orig $*"

I put in -x to echo progress of the command. Ownership and permissions of the new pg_ctl should be root:root 755, the same as pg_ctl.orig. If the command is run by root, su succeeds. If it is run by another user, the script will prompt for a password. On my system, postgres has no password so the command will always fail unless invoked by root.
 
Hi,

I had the same problem earlier, here is wat SWSoft support did:

Comment # strings from line 114 to 121 in /usr/bin/pg_ctl.

Now all works fine !

Regards,
Bart
 
Back
Top