On 10/07/2014 09:10 PM, Stephen Davies wrote:
> The permissions on the socket are 777 owner/group postgres.
>
> I installed the 9.3 onto the Centos 7 server using the repo at
> postgresql.org.
>
> (http://yum.postgresql.org/9.3/redhat/rhel-$releasever-$basearch)
>
> There is no /var/run/postgresql and find cannot find another socket
> anywhere else.
Sounds similar to this:
Long version:
http://serverfault.com/questions/609947/database-connection-to-postgresql-refused-for-flask-app-under-mod-wsgi-when-start
Short version:
Disable SELinux
>
> Cheers and thanks,
> Stephen
>
> On 08/10/14 14:32, Tom Lane wrote:
>> Stephen Davies <sdavies@sdc.com.au> writes:
>>> I am in the process of migrating a bunch of databases and associated CGI
>>> scripts from 9.1.4 to 9.3 (and from 32-bit to 64-bit).
>>
>>> The database migration has been successful but I have an issue with psql
>>> connections from CGI scripts.
>>
>>> I can connect to the 9.3 server locally with psql from the command
>>> line, with
>>> psql from other boxes on the LAN via TCP, via JDBC from programs and
>>> servlets
>>> but cannot connect locally via CGI.
>>
>>> If I run any of the CGI scripts from the command line they work but when
>>> invoked by Apache, they fail with the usual question as to whether
>>> anything is
>>> listening on socket /tmp/.s.PGSQL.5432.
>>
>> Some Linux variants think it improves security to run daemons like apache
>> in a context where what the daemon sees as /tmp has been mapped somewhere
>> else.
>>
>> If you're running one of these platforms, the Postgres server and libpq
>> distributed by the vendor will have been hacked to cope, typically by
>> agreeing that the socket location is something like /var/run/postgresql/
>> rather than /tmp. I'm guessing your 9.3 installation was self-built
>> and hasn't been configured that way.
>>
>> regards, tom lane
>>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com