Thread: connection timeout hint
When one tries to connect to a server and port which is protected by a firewall, ones get messages like this:
Unix:
psql: error: connection to server at "192.168.0.26", port 5432 failed: Connection timed out
Is the server running on that host and accepting TCP/IP connections?
Is the server running on that host and accepting TCP/IP connections?
Windows:
psql: error: connection to server at "192.168.0.26", port 5432 failed: Connection timed out (0x0000274C/10060)
Is the server running on that host and accepting TCP/IP connections?
Is the server running on that host and accepting TCP/IP connections?
But the hint given is unhelpful, and even positively misleading. If the port is blocked by a firewall, it doesn't imply the database server is not listening (if one could just get to it), and it doesn't matter if the database server is listening. If for some reason it weren't listening as well as being blocked, making it listen wouldn't help as long it remains blocked at the firewall.
Is there some portable way to detect this cause of the connection problem (connection timeout) and issue a more suitable hint explicitly mentioning firewalls and routers, or perhaps just no hint at all?
As far as I know, only a firewall causes this problem, at least on a persistent basis. Maybe you could see it sporadically on a vastly overloaded server or a server caught in the process of rebooting. It would be better to give a hint that is correct the vast majority of the time than one that is wrong the vast majority of the time.
There are a lot of questions about this on, for example, stackoverflow. I think people might be better able to figure it out for themselves if the hint were not actively leading them astray.
Cheers,
Jeff
Jeff Janes <jeff.janes@gmail.com> writes:
> When one tries to connect to a server and port which is protected by a
> firewall, ones get messages like this:
> Unix:
> psql: error: connection to server at "192.168.0.26", port 5432 failed:
> Connection timed out
> Is the server running on that host and accepting TCP/IP connections?
> Windows:
> psql: error: connection to server at "192.168.0.26", port 5432 failed:
> Connection timed out (0x0000274C/10060)
> Is the server running on that host and accepting TCP/IP connections?
> But the hint given is unhelpful, and even positively misleading.
Well, maybe. I think you're right that it would be useful to give
different hints for ETIMEDOUT and ECONNREFUSED, but sadly it seems
not uncommon for systems to just drop connection requests that
there's no listening process for.
Can we break down the possible cases any further?
* Target host doesn't exist or is down: could give ETIMEDOUT,
EHOSTDOWN, or EHOSTUNREACH.
* Host is up, but PG server is not running or not listening on that
socket: ideally ECONNREFUSED, but could be ETIMEDOUT if the local
firewall blocks it.
* Server is running, but firewall blocks reaching it: almost
certainly ETIMEDOUT.
Are there more cases?
The current hint is already reasonably on-point for EHOSTDOWN,
EHOSTUNREACH, ECONNREFUSED. I agree it's too specific for
ETIMEDOUT, but what exactly would be a better message in view
of the multitude of possible causes?
> Is there some portable way to detect this cause of the connection problem
> (connection timeout)
No, I don't think so. We have the kernel errno to work with
and little more.
regards, tom lane