Fix PID file location?

FOlks,

The problem seems to be that pg_ctl expects the PID file to be in $PGDATA,
but the file actually gets written by the postmaster to the actual data
directory. You can work around this by setting "external_pid_file", but
this then prevents you from using external_pid_file for another purpose.

More about this: due to the PID file not being in the right place, pg_ctl stop
never reports success:

waiting for postmaster to shut
down............................................................... failed
pg_ctl: postmaster does not shut down

This appears to be because the duplicate PID in the conf directory is not
removed on shutdown.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is the
right place to move it.

I have tested it and it seems to work. I would like to backpatch this to
8.0.X because it is currently broken without it. This patch does
require that the postgres unix user have write permission in the
configuration directory to create the pid file on startup.

---------------------------------------------------------------------------

Josh Berkus wrote:

Hey, folks,

I've noticed a problem with alternate PGDATA locations. Here's how to
reproduce:

On 8.0.2 on RHAS4:

1) Initdb a directory (on my system, /pgdata/pgdata)
2) Move the .conf files to an alternate location ( /etc/pgsql/)
3) Set $PGDATA to the alternate location ( /etc/pgsql )
4) Edit postgresql.conf to support this file arrangement
data_directory = '/pgdata/pgdata'
5) pg_ctl start PostgreSQL
6) pg_ctl stop PostgreSQL
7) Get an error: "No PID file found".

The problem seems to be that pg_ctl expects the PID file to be in $PGDATA, but
the file actually gets written by the postmaster to the actual data
directory. You can work around this by setting "external_pid_file", but this
then prevents you from using external_pid_file for another purpose.

Seems like it should be a relatively easy fix, although I'm not sure whether
the postmaster should write the PID to $PGDATA, or whether pg_ctl should be
made to look in the right place. Probably the latter.

---------------------------------------------------------------------------

More about this: due to the PID file not being in the right place, pg_ctl stop
never reports success:

waiting for postmaster to shut
down............................................................... failed
pg_ctl: postmaster does not shut down

This appears to be because the duplicate PID in the conf directory is not
removed on shutdown.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian said:

I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is
the right place to move it.

this seems wrong ... wouldn't it be better to teach pg_ctl at least enough
about the config file to enable it to find the data dir?

cheers

andrew

Bruce Momjian wrote:

I have generated the following patch that moves postmaster.pid into
the configuration directory. pg_ctl only knows about the
configuration directory because it can't read postgresql.conf, so it
seems that is the right place to move it.

Files that are not actually configuration files, to be edited by users,
do not belong in the configuration directory.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,

Files that are not actually configuration files, to be edited by users,
do not belong in the configuration directory.

Do you have an alternate suggestion then? Current behavior is broken.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is the
right place to move it.

Unfortunately, that is *absolutely* unsafe. If we do that it will break
the safety property that the lock file is meant to enforce in the first
place, namely only one postmaster running in a given data directory.
It's not too hard to imagine people getting burnt by that, either:
initdb, create new config files in another directory, forget to remove
the original postgresql.conf in the data directory, and you have every
ingredient needed for disaster. Just start two postmasters with both
direct and indirect -D arguments, and kaboom.

This patch does
require that the postgres unix user have write permission in the
configuration directory to create the pid file on startup.

That assumption is unacceptable, too. One of the prime reasons for
having config files somewhere else is that the somewhere else can be
read-only, thus reducing your exposure in case of a security breach.
(Otherwise, we could possibly fix this by generating a second
postmaster.pid in the config directory.)

I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf, or revert the
separate-config-file-location patch.

regards, tom lane

On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote:

I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf,

I don't think this is extremely hard, isn't it?

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"El realista sabe lo que quiere; el idealista quiere lo que sabe" (An�nimo)

Alvaro Herrera <alvherre@surnet.cl> writes:

On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote:

I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf,

I don't think this is extremely hard, isn't it?

One small problem is that I think the current definition allows the data
directory to be specified relative to the original postmaster working
directory. Of course, that's not different from "-D ." on the
postmaster command line, so possibly the answer is "if you want to use
pg_ctl, don't do that".

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@surnet.cl> writes:

On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote:

I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf,

I don't think this is extremely hard, isn't it?

One small problem is that I think the current definition allows the data
directory to be specified relative to the original postmaster working
directory. Of course, that's not different from "-D ." on the
postmaster command line, so possibly the answer is "if you want to use
pg_ctl, don't do that".

I don't see any way to accurately find the data directory location.
Reading postgresql.conf is one way, but what if they set data_directory
on the command line using postmaster -o? Is reading postgresql.conf
from pg_ctl without a parser really accurate? Shame we can't attach and
do "SHOW data_directory" on a backend.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is reading postgresql.conf
from pg_ctl without a parser really accurate?

The brute-force solution is to duplicate guc-file.l.

That seems pretty ugly but in the long run it might be the most
maintainable solution. We eventually gave up trying to have a
cut-rate SQL lexer in psql, and duplicated parser/scan.l.
Might be best to just go for that solution up front in this case.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is reading postgresql.conf
from pg_ctl without a parser really accurate?

The brute-force solution is to duplicate guc-file.l.

That seems pretty ugly but in the long run it might be the most
maintainable solution. We eventually gave up trying to have a
cut-rate SQL lexer in psql, and duplicated parser/scan.l.
Might be best to just go for that solution up front in this case.

Added to TODO:

* Allow pg_ctl to work properly with configuration files located outside
the PGDATA directory

pg_ctl can not read the pid file because it isn't located in the
config directory but in the PGDATA directory. The solution is to
allow pg_ctl to read and understand postgresql.conf to find the
data_directory value.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073