Обсуждение: psql: could not connect to server: No route to host

Hi all;

I've setup PostgreSQL to talk across servers thousand of times... not
sure what I'm doing wrong, maybe I'm just over-tired.


I have 2 scientific linux VM's running in vmware workstation

server 1 - 192.168.1.125
server 2 - 192.168.1.127

I've disabled selinux on both servers

Ive instaled PostgreSQL 9.1.3 on both servers

I have listen_addresses on server 1 set to '*'

postgres=# show listen_addresses ;
  listen_addresses
------------------
  *
(1 row)


I've added this to the pg_hba.conf file of server 1:
host     all             all             192.168.1.0/24        trust


I can scp files between the servers

Then from server 2 I run this:

$ psql -h 192.168.1.125
psql: could not connect to server: No route to host
         Is the server running on host "192.168.1.125" and accepting
         TCP/IP connections on port 5432?


am i loosing my mind?


thanks in advance

Kevin Kempter <cs_dba@consistentstate.com> writes:
> I can scp files between the servers

Really?

> $ psql -h 192.168.1.125
> psql: could not connect to server: No route to host

Because that is not a Postgres problem, that is a network connectivity
problem.  I'd bet that there's something wrong with the VM
configuration, such that the VM host isn't connecting 192.168.1.* in one
VM to 192.168.1.* in the other.

            regards, tom lane

netstat -nat

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:3350          0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN    

# - Connection Settings -

#listen_addresses = '*'                 # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost', '*' = all
                                        # (change requires restart)
port = 5432                             # (change requires restart)
max_connections = 100                   # (change requires restart)

# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
host    all         all         192.168.0.0/16        trust

On 04/25/2012 10:50 PM, Tom Lane wrote:
> Kevin Kempter<cs_dba@consistentstate.com>  writes:
>> I can scp files between the servers
> Really?
>
>> $ psql -h 192.168.1.125
>> psql: could not connect to server: No route to host
> Because that is not a Postgres problem, that is a network connectivity
> problem.  I'd bet that there's something wrong with the VM
> configuration, such that the VM host isn't connecting 192.168.1.* in one
> VM to 192.168.1.* in the other.
>
>             regards, tom lane

Scientific Linux turns on the firewall by default. It lets me scp via
username & passwd but wouldn't allow the port 5432 tcp connection till I
disabled it.  I like Scientific because it seems that they are a large
team and as a project seem to have better long term viability than other
RH based projects but a couple of their defaults drive me nuts. Like
this one, and the default install of yum-autoupdate

Am 26.04.2012 17:36, schrieb Kevin Kempter:
> Scientific Linux turns on the firewall by default. It lets me scp via
> username & passwd but wouldn't allow the port 5432 tcp connection till I
> disabled it.  I like Scientific because it seems that they are a large
> team and as a project seem to have better long term viability than other
> RH based projects but a couple of their defaults drive me nuts. Like
> this one, and the default install of yum-autoupdate

At least for the driving nuts thing I'm 110% on your page ;)

cheers,
Frank

I'm assuming this is a reply that has the quoted two deep stuff in it
from the OP to you, Ricardo.

On Thu, Apr 26, 2012 at 5:49 AM, Ricardo Benatti <rbenatti@gmail.com> wrote:
>
>
> the port is listening in VM ?
>
>> netstat -nat
>>
>> Active Internet connections (servers and established)
>> Proto Recv-Q Send-Q Local Address           Foreign Address         State
>> tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
>> tcp        0      0 127.0.0.1:3350          0.0.0.0:*               LISTEN
>> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
>> tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN
>> tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN

This doesn't show the port listening on an external interface, only the internal

> released access [ postgresql.conf ] for connections tcp ??
>
>> # - Connection Settings -
>>
>> #listen_addresses = '*'                 # what IP address(es) to listen on;

That line is still commented out.

Uncomment listen_addresses and restart the server and try again.