I have a Node server hosted on an EC2 instance that is trying to connect to Postgres running on the same instance. When I start the server I get an ECONNREFUSED error to the db:
Unable to connect to the database: SequelizeConnectionRefusedError: connect ECONNREFUSED x.x.x.x:5432
I am using the Sequelize ORM package from NPM:
import Sequelize from 'sequelize';
const db = new Sequelize('postgres://postgres#52.9.136.53/unloadx' {dialect: 'postgres'});
Postgres is running on the instance, and I have port 5432 open in my inbound security rule. I can confirm that postgres is running with ps aux | grep postgres which shows multiple postgres related processes, and netstat -anp --tcp confirms that postgres appears to be listening on the port:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 ::1:5432 :::* LISTEN -
But when I scan the port with nmap x.x.x.x -p 5432 it shows that the port status is closed. Per nmap, this means that the port is accessible but has no application listening on it able to respond to packets.
Appreciate any help in getting the connection to work.
One problem is that you are using the public IP address. That means your database connection is basically going out to the internet and back. This will prevent the Security Group rule from working, and introduce security and latency issues.
If you were trying to connect from another server in the VPC you would want to connect using the private IP. However, since it's on the same instance you can delete the Security Group rule and just use localhost or 127.0.0.1.
What makes you think that netstat is showing that postgres is listening on the port? If it were, you'd see something in the PID/Program column.
Also, if your postgres server is running on the same box as your node app, you should not need to open up the port to the internet via your AWS security rules, and probably shouldn't unless you need to access it from elsewhere. Then you can change your connection string to hit localhost or 127.0.0.1
Finally, verify that you've setup your postgres server correctly via the docs
Related
Background
First time working with Azure. I'm deploying a database server (ClickHouse) onto a VM hosted in Azure, and have it started up fine. The VM is running Ubuntu. The database server's default ports are localhost port 9000 for TCP (used by the command line client) and 8123 for HTTP (used by application clients).
Issue
The db server should be listening on the server's default http port (8123). However, when I try to connect, it just hangs. Based on the below steps, I don't think the network request is making it to the server.
Steps I've tried
Started the containerized version on my local machine and used the exact same curl command to run a simple SELECT 1 query against it (http://localhost:8123). This succeeds and proves to me that the request is not malformed.
Verified that the server is responsive via the local client on the VM (while SSH'ed in)
Added my IP address and the port in the VNET's "inbound port rules". I've been able to access my public IP via SSH after adding a similar rule for that.
my ip is valid irl
$ telnet my.public.ip.address 8123 <- obviously with the actual ip in there. this hangs as well
While SSH'ed in, I've run $ ss -atn | grep 8123 and see:
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 4096 127.0.0.1:8123 0.0.0.0:*
LISTEN 0 4096 [::1]:8123 [::]:*
I'm not an expert at the network component of this. I think this means the server is listening to 8123 on localhost as well as all other addresses. I take that latter part to mean that it should be exposed publicly. I also believe LISTEN means it is ready to accept connections, but no connections are currently open.
Any ideas?
LISTEN 0 4096 127.0.0.1:8123
0.0.0.0:*
expected:
LISTEN 0 4096 *:8123 *:*
Your Clickhouse listens localhost only
solution:
cat /etc/clickhouse-server/config.d/port.xml
<?xml version="1.0"?>
<yandex>
<listen_host>::</listen_host>
</yandex>
and restart CH.
I have a postgres database currently working on my PC. I am deploying a flask app which uses said database onto a linux server, and need to remotely connect to my database from the linux machine. The command I am using on the linux machine to do this is
psql -h 12.345.678.901 -p 5432 -U postgres
where 12.345.678.901 is my local PC ip address. When I do this, I get the error
psql: error: connection to server at "12.345.678.901", port 5432 failed: Connection timed out
Is the server running on that host and accepting TCP/IP connections?
I would like to emphasize that the connection is not being 'refused', it is just timing out (unlike many of the questions related to this topic). I'm not sure if this helps identify the underlying issue or not. I understand that this is an extremely common issue, but no solutions have worked for me. Among these solutions are updating the pg_hba.conf, postgresql.conf, firewall configuration, and many others. I have done this. My pg_hba.conf file looks like this
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
host all all 0.0.0.0/0 trust
# IPv6 local connections:
host all all ::1/128 scram-sha-256
host all all ::0/0 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
host all all 0.0.0.0/0 md5
and my postgresql.conf looks like this
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
These files are located in C:\Program Files\PostgreSQL\14\data. I have manually checked that these changes are saved and implemented with the psql shell. I also restarted postgres after all changes to these files.
Other fixes I have implemented:
Set firewall rules on local PC to open port 5432 to inbound and outbound TCP/IP connections with Windows Defender Firewall
Set remote linux PC firewall to allow connections through port 5432 with the lines
'sudo ufw allow 5432/tcp' &
'sudo ufw allow postgres/tcp'
Tried both local PC IPv4 address and default gateway address (I am not sure which one to use to be honest)
Set a rule for my physical router to allow connections to port 5432
I cannot figure this out to save my life. Any help would be greatly so utterly appreciated.
To anyone else struggling with this question, after many weeks of digging I finally found the solution. The ip address you must use in the postgres configuration files is the ip address of your ROUTER. I tried every single ip address on my computer and none worked. Only when I got on my internet providers app and found my router ip is when I was finally able to connect. The biggest tell of this was that when I would ssh into my remote server, it would say 'connection from {router ip address}'. Hope this helps.
I have searched for how to close psql port for a while, but most of the answers are talking about closing psql command line using \q, which is not what I am looking for.
My problem is, the postgresql on my laptop are running and listening on port 5432, but I would like to use port 5432 for some other use. Usually I run netstat -plnt to find the process to kill, but in this case the process that is listening on port 5432 does not have a process id...
Any idea on how I can release the port 5432?
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN -
psql is a client that connects to postgres server. closing connection with \q just finishes session. When it happens, backend for that session stops, so by closing connection you only release pid on server. And server keeps on listening on port 5432.
If you want to stop listening on port 5432, you can either stop postgres server with pg_ctl stop or even assign different port to it in postgres.conf, so you can run both programs in parallel
update
If you installed from packages (Ubuntu/Debian/Fedora/RHEL/CentOS/etc) you should use the system services manager to stop postgresql. e.g. in RHEL 7 or Fedora, sudo systemctl stop postgresql-9.6 (or whatever your version is) rather than pg_ctl (quoting Craig Ringer)
Configuration: Server: Ubuntu server 16.04 LTS using webmin
Terminal: Windows 7 Using PgAmin III
I was unable to establish the connection between my terminal and my server through pgAdmin III on port 5432.
On my server I added:
in file postgresql.conf I edited
in #Connection Settings
listen_addresses = '*'
in file pg_hba.conf I added
in #IPv4 local connections
host all all 172.x.x.x/32 md5 //this is IP Terminal (Hidden x)
I checked the port, this is 5432 default and user is postgres
When I try to establish the connection on PgAdmin III:
Host: //My Server IP (Ping console successful)
Port: 5432
username: postgres
password: //My password
Show me the following message:
Server doesn't listen
The server doesn't accept connections: the connection library reports
could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "Mi SERVER IP Hidden" and accepting TCP/IP connections on port 5432?
If you encounter this message, please check if the server you're trying to contact is actually running PostgreSQL on the given port. Test if you have network connectivity from your client to the server host using ping or equivalent tools. Is your network / VPN / SSH tunnel / firewall configured correctly?
For security reasons, PostgreSQL does not listen on all available IP addresses on the server machine initially. In order to access the server over the network, you need to enable listening on the address first.
For PostgreSQL servers starting with version 8.0, this is controlled using the "listen_addresses" parameter in the postgresql.conf file. Here, you can enter a list of IP addresses the server should listen on, or simply use '*' to listen on all available IP addresses. For earlier servers (Version 7.3 or 7.4), you'll need to set the "tcpip_socket" parameter to 'true'.
You can use the postgresql.conf editor that is built into pgAdmin III to edit the postgresql.conf configuration file. After changing this file, you need to restart the server process to make the setting effective.
If you double-checked your configuration but still get this error message, it's still unlikely that you encounter a fatal PostgreSQL misbehaviour. You probably have some low level network connectivity problems (e.g. firewall configuration). Please check this thoroughly before reporting a bug to the PostgreSQL community.
I have an Ubuntu 14.04 Linux server with MongoDB 3.2.4 running at Digital Ocean as a droplet (one-click Apps).
Pinging the server works (droplet is distroyed after posting this):
ping 198.199.125.101
I created database test and user:
db.createUser({"user": "test", "pwd": "test", "roles": ["dbOwner"]})
In mongod.conf I changed bindIp: 0.0.0.0 and restarted mongoDB
I disabled the firewall and reboot the server. Just for test, just to prove iptables is not the issue (don't do this on a regular server):
sudo ufw disable
The problem is I can't get remote access to the mongo Database
mongo 198.199.125.101:27021/test -u "test" -p "test"
Error message (connection refused):
MongoDB shell version: 3.2.0
connecting to: 198.199.125.101:27021/test
2016-05-11T22:05:35.876+0200 W NETWORK [thread1] Failed to connect to 198.199.125.101:27021, reason: errno:61 Connection refused
2016-05-11T22:05:35.879+0200 E QUERY [thread1] Error: couldn't connect to server 198.199.125.101:27021, connection attempt failed :
connect#src/mongo/shell/mongo.js:226:14
#(connect):1:6
exception: connect failed
First run netstat on the mongo machine to verify that the port 27021 is open. netstat -anp should do it.
Then do "telnet 127.0.0.1 27021" to make sure it is open.
Once you are sure the port is open, then use telnet 198.199.125.101 27021 to verify you can connect to the mongo machine on port 27021. If you can, then it has something to do with your app. If not then something is blocking the connection. Some firewall or something. Are you on aws?
As per netstat, can you try mongo 198.199.125.101:27017/test -u "test" -p "test"