Thread: BUG #12072: init script creates pid file with wrong owner

The following bug has been logged on the website:

Bug reference:      12072
Logged by:          Henrik Storner
Email address:      henrik-postgres@hswn.dk
PostgreSQL version: 9.3.5
Operating system:   CentOS 6.6
Description:

The /etc/init.d/postgresql-9.3 file created a PID file, but fails to make it
owned by user 'postgres'.

This means that using the "pg_ctl" command to restart Postgres fails,
because user postgres cannot update the pid file (if you set
external_pid_file in postgresql.conf so it can find the pid file).

The init script should do a "chown postgres:postgres $pidfile" so the pid
file is owned by the postgres user. This allows pg_ctl commands to work.

The init script will first do "su - postgres" before starting the server,
so there is no way that the owner of the PID file (default location is
$DATADIR/postmaster.pid) is not postgres. Please recheck.

On Wed, Nov 26, 2014 at 7:49 PM, <henrik-postgres@hswn.dk> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      12072
> Logged by:          Henrik Storner
> Email address:      henrik-postgres@hswn.dk
> PostgreSQL version: 9.3.5
> Operating system:   CentOS 6.6
> Description:
>
> The /etc/init.d/postgresql-9.3 file created a PID file, but fails to make
> it
> owned by user 'postgres'.
>
> This means that using the "pg_ctl" command to restart Postgres fails,
> because user postgres cannot update the pid file (if you set
> external_pid_file in postgresql.conf so it can find the pid file).
>
> The init script should do a "chown postgres:postgres $pidfile" so the pid
> file is owned by the postgres user. This allows pg_ctl commands to work.
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>



--
Sandeep Thakkar

On 11/26/2014 6:19 AM, henrik-postgres@hswn.dk wrote:
> The /etc/init.d/postgresql-9.3 file created a PID file, but fails to make it
> owned by user 'postgres'.

it should have.   mine does.


[root@new ~]# ls -la /var/lib/pgsql/9.3/data/postmaster.pid
-rw------- 1 postgres postgres 72 Oct 29 09:54
/var/lib/pgsql/9.3/data/postmaster.pid

[root@new ~]# cat /etc/redhat-release
CentOS release 6.6 (Final)

[root@new ~]# rpm -qa postgres\*
postgresql93-devel-9.3.5-1PGDG.rhel6.x86_64
postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64
postgresql93-server-9.3.5-1PGDG.rhel6.x86_64
postgresql93-contrib-9.3.5-1PGDG.rhel6.x86_64
postgresql93-9.3.5-1PGDG.rhel6.x86_64



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

The init script will first do "su - postgres" before starting the server, so there is no way that the owner of the PID file (default location is $DATADIR/postmaster.pid) is not postgres. Please recheck.

On Wed, Nov 26, 2014 at 7:49 PM, <henrik-postgres@hswn.dk> wrote:

The following bug has been logged on the website:

Bug reference:      12072
Logged by:          Henrik Storner
Email address:      henrik-postgres@hswn.dk
PostgreSQL version: 9.3.5
Operating system:   CentOS 6.6
Description:

The /etc/init.d/postgresql-9.3 file created a PID file, but fails to make it
owned by user 'postgres'.

This means that using the "pg_ctl" command to restart Postgres fails,
because user postgres cannot update the pid file (if you set
external_pid_file in postgresql.conf so it can find the pid file).

The init script should do a "chown postgres:postgres $pidfile" so the pid
file is owned by the postgres user. This allows pg_ctl commands to work.



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

--

Sandeep Thakkar

Henrik Størner <henrik@hswn.dk> writes:
> The problem is with the init script installed from the rpm package. From
> line 161 it performs the server start by doing

>         echo -n "$PSQL_START"
>         $SU -l postgres -c "$PGENGINE/postmaster -p '$PGPORT' -D
> '$PGDATA' ${PGOPTS} &" >> "$PGLOG" 2>&1 < /dev/null
>         sleep 2
>         pid=`head -n 1 "$PGDATA/postmaster.pid" 2>/dev/null`
>         if [ "x$pid" != x ]
>         then
>                 success "$PSQL_START"
>                 touch "$lockfile"
> *                echo $pid > "$pidfile"*
>                 echo
>         else
>                 failure "$PSQL_START"
>                 echo
>                 script_result=1
>         fi

> Note the
>    echo $pid > "$pidfile"

> This creates a pid-file owned by root.

Why is the init script creating such a file at all?  Surely it should be
depending on the one created by the postmaster.  However, if there is a
reason to create a separate pidfile, I don't see the problem particularly:
the postmaster will neither create nor remove it, so it hardly matters
what the ownership is.
        regards, tom lane

Tom Lane wrote:
> Henrik Størner <henrik@hswn.dk> writes:
>> The problem is with the init script installed from the rpm package. From
>> line 161 it performs the server start by doing
> Why is the init script creating such a file at all? Surely it should
> be depending on the one created by the postmaster. However, if there
> is a reason to create a separate pidfile, I don't see the problem
> particularly: the postmaster will neither create nor remove it, so it
> hardly matters what the ownership is. regards, tom lane
The problem lies in the interaction between a DBA using the pg_ctl
commands, and a system start/stop script which is executed when the
system boots or shuts down.

Consider this scenario:

1) The system boots, Postgres starts up automatically via the init.d
script. Two pid-files now exist - one created by the init.d script in
/var/run, and another in the PGDATA directory. They are identical.

2) DBA tweaks some configuration requiring a restart. Since the DBA
doesn't have root access, he logs into the "postgres" account and runs
"pg_ctl restart". This updates the pid-file in the PGDATA directory, but
not the one in /var/run because a) the postgres user does not have write
access to the file, and b) by default pg_ctl doesn't know about the pid
file in /var/run. So the two pid-files are no longer in sync, only the
PGDATA pid file is valid.

3) The server is shut down or rebooted. During shutdown the init.d
script looks at the pid-file in /var/run, and finds that the pid listed
no longer exists. Therefore it assumes that Postgres isn't running and
doesn't try to shut it down gracefully. It gets a 'kill -TERM' at a late
point in the shutdown proces, which is not optimal.


I suppose the /var/run pid-file is created by the RPM initscript because
the Linux Filesystem Hierarchy Standard dictates that system services
keep a pid-file in /var/run - not buried somewhere deep inside a service
specific directory.

Fixing the permission setting on the /var/run pidfile is only part of
the solution, for it to work completely you must also change
postgres.conf so the extra_pid_file setting (iirc) is set to the
/var/run pidfile. This makes sure that the 'postmaster' process updates
both pid-files - but it still requires that both pid-files are writable
by the "postgres" user.


Regards,
Henrik

Hi,

On Wed, 2014-11-26 at 14:19 +0000, henrik-postgres@hswn.dk wrote:
>
> The /etc/init.d/postgresql-9.3 file created a PID file, but fails to
> make it owned by user 'postgres'.
>
> This means that using the "pg_ctl" command to restart Postgres fails,
> because user postgres cannot update the pid file (if you set
> external_pid_file in postgresql.conf so it can find the pid file).

I don't think that we designed the *init script* (kicked by init
subsystem) to be compatible with pg_ctl command (called by postgres
user). If you have an environment that requires a non-root user to
restart postgres, you can hack the init script and add a chown line
there.

That pid file is used by RHCS (IIRC), so I am not inclined to touch it.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR