Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZK0Nb-0003y7-QG for pgsql-pkg-yum@arkaria.postgresql.org; Tue, 28 Jul 2015 08:36:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZK0Nb-0003lx-CN for pgsql-pkg-yum@arkaria.postgresql.org; Tue, 28 Jul 2015 08:36:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZK0Na-0003lr-PR for pgsql-pkg-yum@postgresql.org; Tue, 28 Jul 2015 08:36:55 +0000 Received: from mail-ig0-x229.google.com ([2607:f8b0:4001:c05::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZK0NW-0006zc-72 for pgsql-pkg-yum@postgresql.org; Tue, 28 Jul 2015 08:36:54 +0000 Received: by iggf3 with SMTP id f3so111447152igg.1 for ; Tue, 28 Jul 2015 01:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lisasoft.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=pHKQZhVfMdrEgzlCXJ3yS3xWxQznZN1jE3qB1B6p2nc=; b=QkPSjl40m2MdN3Su+wSF7Ouef2LLRRJE1UJfVsMA+0j/eoZR1SL2peN+dgEpZ1E+Py wJd+uU+tXHq2sKvcUc/5EAFy/u3KZhgynpjY8xBDrLBz2Et1dHn79Y7FOmIc/UBYBUiM gPgzgN+vsxf/oTyv3w99AfLMi3QpXmObbtiZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pHKQZhVfMdrEgzlCXJ3yS3xWxQznZN1jE3qB1B6p2nc=; b=PFYdaZiciGAYZak8FpzBiKtSNUxUPXscMewdJNIOLUvpEceQQdchv0ZkCf20JTGeAc OnT+Je7Ntqwde7SJkKZI7cUQAECPFj5QP60i74ijyiteSu/W/uAJgezCFJRjZsskBxwR 5E3wB0xLfRAL6dvILtGH4y/wY0oNYYl8tsxjOH81SJvOuvb2W538GQjDYqgfQ++rckQo VrJ/U3niPeyMGzgA6pMf7wBFRFSLvqYtm+7u20ySnDoeFYIniIuWoZptwPwaOD9+xpDC b2IzOK5XmVJ43YVWBIri1rwcNvU1aZVvZGzuOUxSYyEXhfT48ZetTfiDWX+mWzp/gi1v XYVA== X-Gm-Message-State: ALoCoQmkbRZxK2SjX8WKefQPJIpttZEYgBNUMadzIK/p6EEZda3Arn0g0/w02PWNdsoW+UL087XLZ3i8loWpzn+41o58RfdnAycCM3DVeFRmiFIJkph4y7+KqQbcFJqG5gaKPbDy1rbS MIME-Version: 1.0 X-Received: by 10.50.36.101 with SMTP id p5mr4411881igj.58.1438072604808; Tue, 28 Jul 2015 01:36:44 -0700 (PDT) Received: by 10.107.14.15 with HTTP; Tue, 28 Jul 2015 01:36:44 -0700 (PDT) Date: Tue, 28 Jul 2015 18:36:44 +1000 Message-ID: Subject: services and pg_ctl From: James Sewell To: pgsql-pkg-yum@postgresql.org Content-Type: multipart/alternative; boundary=089e013a0282c58af7051beb5e43 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-pkg-yum Precedence: bulk Sender: pgsql-pkg-yum-owner@postgresql.org --089e013a0282c58af7051beb5e43 Content-Type: text/plain; charset=UTF-8 Hello, It seems that in some (recent? all?) versions of the PGDG Redhat/CentOS RPMs pg_ctl and service (init.d) don't play well together. As an example: -bash-4.1$ id uid=26(postgres) gid=26(postgres) groups=26(postgres),500(efm) -bash-4.1$ -bash-4.1$ psql psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? -bash-4.1$ -bash-4.1$ pg_ctl start server starting -bash-4.1$ exit logout [root@centos6-soe /]# [root@centos6-soe /]# service postgresql-9.4 status postgresql-9.4 is stopped It seems like this is because of pg_ctl and the init.d script using different lockfiles / pidfiles. This can be fixed by doing the following: 1. Making a directory for locks and pid files (in /var/lock/subsys and /var/run) and setting it to be owned by postgres 2. Setting unix_socket_directories in postgresql.conf to use the lock directory by default. 3. Setting external_pid_file in postgresql.conf to use the /var/run directory by default 4. Setting the init.d script to write the lockfile in the same way pg_ctl does Is this something that could change in the future (or is there a reason this is a bad idea)? I'm happy to provide diffs to get to a working state if that helps. Cheers, James Sewell, PostgreSQL Team Lead / Solutions Architect ______________________________________ Level 2, 50 Queen St, Melbourne VIC 3000 *P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099 -- ------------------------------ The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. --089e013a0282c58af7051beb5e43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

It seems that in some (recent? a= ll?) versions of the PGDG Redhat/CentOS RPMs pg_ctl and service (init.d) do= n't play well together.

As an example:

-bash-4.1$ id
uid=3D26(postgres) gid=3D26(postgres) groups=3D26(postgr= es),500(efm)
psql: could not connect to server: No such file or directory<= /div>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Is the server running locally and accepting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 con= nections on Unix domain socket "/tmp/.s.PGSQL.5432"?
=
-bash-4.1$
=
-bash-4.1$ pg_ctl start=
server sta= rting
-bash= -4.1$ exit
= logout
[roo= t@centos6-soe /]#
[root@centos6-soe /]# service postgresql-9.4 status
postgresql-9.4 is stopped

It seems like this is because = of pg_ctl and the init.d script using different lockfiles / pidfiles. This = can be fixed by doing the following:
  1. Making a directory for loc= ks and pid files (in /var/lock/subsys and /var/run) and setting it to be ow= ned by postgres
  2. Setting unix_socket_directories in postgresql.conf = to use the lock directory by default.
  3. Setting=C2=A0external_pid_fil= e in postgresql.conf to use the /var/run directory by default
  4. Setti= ng the init.d script to write the lockfile in the same way pg_ctl does
    5. =
Is this something that could change in the future (or is there a = reason this is a bad idea)? I'm happy to provide diffs to get to a work= ing state if that helps.

Cheers,

James Sewell,
PostgreSQL Team Lead / Solutions Architect
______________________________________
=C2=A0
3D""
Level 2, 50 Queen St, Melbourne VIC 3000

P=C2=A0(+61) 3 8370 8000=C2=A0 W www.lisasoft.com=C2=A0 F=C2=A0(+61) 3 837= 0 8099
=C2=A0

The contents of this email are confidentia= l and may be subject to legal or professional privilege and copyright. No r= epresentation is made that this email is free of viruses or other defects. = If you have received this communication in error, you may not copy or distr= ibute any part of it or otherwise disclose its contents to anyone. Please a= dvise the sender of your incorrect receipt of this correspondence.

--089e013a0282c58af7051beb5e43--