Обсуждение: [GENERAL] Start/stop postgresql with pg_ctl or service without root access on RHEL
[GENERAL] Start/stop postgresql with pg_ctl or service without root access on RHEL
We plan to use postgresql on RHEL 6.
DBAs won't have root access but they will need to start/stop the databases. They'll be able to do so with pg_ctl
as postgres.
However databases should also start automatically when the server reboots and so we should use services (/etc/init.d/postgresql-9.x
).
When postgres is started with service (as root) and stopped with pg_ctl as postgres, the pid file in $PGDATA
is deleted but not the specific pid and lock files (respectively in /var/run
and /var/lock/subsys
) created by the init.d script.
It leads to an inconsistent state where service postgresql-9.x status
throws"postgresql-9.x dead but pid file exists".
So what is the best practice and solution for this situation?
ask sysadmin to give
sudo /etc/init.d/postgresql-9.x
to the DBAs and never use pg_ctl again?remove the specific pid and lock files from the postgresql-9.x service script?
- any other idea?
Jean-Michel Scheiwiler <jm.scheiwiler@gmail.com> writes: > We plan to use postgresql on RHEL 6. > DBAs won't have root access but they will need to start/stop the databases. > They'll be able to do so with pg_ctl as postgres. > However databases should also start automatically when the server reboots > and so we should use services (/etc/init.d/postgresql-9.x). Don't do that. > When postgres is started with service (as root) and stopped with pg_ctl as > postgres, the pid file in $PGDATA is deleted but not the specific pid and > lock files (respectively in /var/run and /var/lock/subsys) created by the > init.d script. > It leads to an inconsistent state where service postgresql-9.x status > throws"postgresql-9.x > dead but pid file exists". That's one reason why you shouldn't do that. There are others; for instance I don't think you end up with the same selinux context for the daemon if you don't go through "service start". > So what is the best practice and solution for this situation? I'd go with the restricted sudo approach. Customized init scripts are a pain --- either they get overwritten by package upgrades, or they fail to track changes in the script, and either result is bad. regards, tom lane