Error can't connect to localhost:5432

I’m using the swarm deployment (with the “manager-swarm” image) and I’m stuck with the following error from that service:

org.postgresql.util.PSQLException: Connection to localhost:5432 refused. Check that the hostname
and port are correct and that the postmaster is accepting TCP/IP connections.

I have tried to specifiy the DB_HOST var: DB_HOST: ${DB_HOST:-postgresql} but that does’nt seems to change any thing. Any ideas?


I’m afraid that swarm deployment is outdated. I’ve did it some time ago as proof of concept but it hasn’t got a traction. Therefore, it would be better that if you try the current standard way of deployment with docker-compose.

Thanks, that seemed to fix everything (I just used the manager instead). I use Traefik as proxy instead of HAproxy, so my concern was that it was something related to that.

And thank you for a reasonably “simple” and lightweight system, without huge log-management solutions and the complexity of K8s.

1 Like

Using a different proxy is no problem. I personally use caddy as it is simpler to use and has better security score than HAproxy.

Hey @michal, i know this might be for another topic. But, I don’t see any port 8883 exposed by the manager container by default. Should this somehow be enabled (mqtt)?

All TLS termination is normally handled by HAProxy and traffic behind that is un-encrypted; so the MQTT broker only binds to 1883 and isn’t exposed because HAProxy has full access to the manager service as they share a docker network.

You’ll have to do some code changes if you want TLS all the way to the manager MQTT broker and get the MQTT broker to handle TLS; or use a proxy that supports plain TCP proxying.

I skipped the Traefik deployment attempt and went to try the HAproxy setup, though not very familiar with HAProxy.

But, I’m not successfull in getting HAProxy up and running (only as localhost). On first attempt the info log said that “My rate limit was hit” ?!. Then I used the “staging” aproach and HAProxy stalled with:

[INFO][2022-02-15 13:38:18] Checking HAProxy configuration: /etc/haproxy/haproxy-init.cfg
Configuration file is valid
[INFO][2022-02-15 13:38:18] HAProxy starting
[info] 045/133818 (44) : [acme] http-01 plugin v0.1.1
Feb 15 13:38:18 localhost haproxy[44]: [acme] http-01 plugin v0.1.1
[INFO][2022-02-15 13:38:18] HAProxy started with /etc/haproxy/haproxy-init.cfg config, pid 47. cert
[INFO][2022-02-15 13:38:18] Executing cron_auto_renewal_init at Tue, 15 Feb 2022 13:38:18 +0000
[INFO][2022-02-15 13:38:18] Initialising certificate for ‘my.domain’…
[INFO][2022-02-15 13:38:18] Adding domain “my.domain”…
An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see Rate Limits - Let's Encrypt
Failed to issue certificate

and never came up. The only env. i have set for the proxy service is LE_EMAIL, DOMAINNAME and LE_EXTRA_ARGS, should’nt that be suficient?

And on a new domain:

[INFO][2022-02-15 16:01:08] Adding domain “my_new.domain.tld”…
Feb 15 16:01:10 localhost haproxy[45]: [15/Feb/2022:16:01:10.989] http http/ 0/-1/-1/-1/0 503 217 - - SC-- 1/1/0/0/0 0/0 “GET / HTTP/1.1”
Feb 15 16:01:14 localhost haproxy[45]: [15/Feb/2022:16:01:14.230] http http/ 0/-1/-1/-1/0 503 217 - - SC-- 1/1/0/0/0 0/0 “GET / HTTP/1.1”
Feb 15 16:01:17 localhost haproxy[45]: [15/Feb/2022:16:01:17.502] http http/ 0/-1/-1/-1/0 503 217 - - SC-- 1/1/0/0/0 0/0 “GET / HTTP/1.1”
Feb 15 16:01:20 localhost haproxy[45]: [15/Feb/2022:16:01:20.760] http http/ 0/-1/-1/-1/0 503 217 - - SC-- 1/1/0/0/0 0/0 “GET / HTTP/1.1”
Some challenges have failed.
Failed to issue certificate

I’m guessing you’ve just replaced your actual domain name in those logs messages?

If you’re requesting my.domain then that clearly wouldn’t work.

Any domain you enter must be valid and must point to the public IP in front of your OpenRemote installation port 80 must be accessible for cert generation.

Yes, no firewall, an actual domain, forwarded by a nameserver, the latest version of proxy.

I’m using an unusual, but valid by letsencrypt, domain with the tld extension “.green”. So, I guess that should not be an issue.

I got the traefik deployment to work with the latest update of the “manager” (where 1883 is exposed).

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.