Re: authentication failure - Mailing list pgsql-general

From Jayadevan M
Subject Re: authentication failure
Date
Msg-id CAFS1N4g1jmzcdHvOsK4VfzkM0-5YiM4LiDDy0ECJ9YvWrhdt+Q@mail.gmail.com
Whole thread Raw
In response to Re: authentication failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: authentication failure  (Adrian Klaver <adrian.klaver@gmail.com>)
Re: authentication failure  (Sameer Kumar <sameer.kumar@ashnik.com>)
List pgsql-general
There is only one instance -

 ps -eaf | grep bin/postgres | grep -v grep
postgres  3203     1  0  2013 ?        00:02:04 /usr/pgsql-9.3/bin/postgres

The basic checks I did -
Connectivity from other machines work (so server is accessible)
No .pgpass file in the system
Able to login as postgres and application users from the same system (as long as it is not from the chroot environment). So this is not a show-stopper- I am able to work and application is also working fine
Even in the chroot, as I mentioned, once I do a 'su - postgres', I am able to login.

Overall, it is just a minor inconvenience, but I would like to resolve this. The no password supplied message comes back so fast, it is as if it did not even attemp to connect.




On Fri, Jan 3, 2014 at 8:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Adrian Klaver <adrian.klaver@gmail.com> writes:
> On 01/03/2014 04:54 AM, Jayadevan M wrote:
>> Yes. All the basic checks I have done. I upgraded from CENTOs 6.4 to
>> 6.5. Another interesting thing - if I su - postgres and then try, it
>> works. So it has something to do with the chrt user (root) settings.

> It might be helpful to detail what are the 'basic' checks you did? Also
> whenever I see unexplained behavior of this nature on Linux I suspect
> SELinux. Is it enabled?

I'm wondering if there are two Postgres instances on the machine,
and the apparent inconsistency comes from connecting to one or the other.

A different line of thought is that connections from inside and outside
the chroot are getting different treatment in pg_hba.conf.

In any case, debugging this from the client's perspective is almost
impossible, because the server intentionally doesn't give a lot of
detail about why authentication failed.  You need to be looking at
the postmaster log, possibly with log_min_messages cranked up.

                        regards, tom lane

pgsql-general by date:

Previous
From: "john.tiger"
Date:
Subject: returning json data row from json query
Next
From: David Johnston
Date:
Subject: Re: returning json data row from json query