Unable to access after installation - HTTP

I have a similar situation as: https://meta.discourse.org/t/unable-to-access-after-installation/50977

However, even if I change port I am not able to acces the welcome page (I have never been able).

Testing with python -m BaseHTTPServer 80 I access without issues.

This is the docker run after the launcher rebuild:

  • /usr/bin/docker run -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e DISCOURSE_HOSTNAME=XXX -e DOCKER_USE_HOSTNAME=true -e DISCOURSE_DEVELOPER_EMAILS=XXX -e DISCOURSE_SMTP_ADDRESS=XXX -e DISCOURSE_SMTP_PORT=XXX -e DISCOURSE_SMTP_USER_NAME=XXX -e DISCOURSE_SMTP_PASSWORD= -e HTTP_PROXY=XXX -e http_proxy=XXX -e HTTPS_PROXY=XXX -e https_proxy=XXX -e DISCOURSE_ENABLE_CORS=true -e ‘DISCOURSE_CORS_ORIGIN=*’ -h XXX -e DOCKER_HOST_IP= --name app -t -p 8080:8080 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:57:80:24:85:c7 local_discourse/app /sbin/boot
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                          NAMES
47ec966d1982        local_discourse/app   "/sbin/boot"        27 minutes ago      Up 27 minutes>443/tcp,>8080/tcp   app

netstat -na | grep 8080
tcp6 0 0 :::8080 :::* LISTEN

iptables -S
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A DOCKER -d ! -i docker0 -o docker0 -p tcp -m tcp --dport 443 -j ACCEPT

I do not have SSL. Any suggestions?


First of all, why do you start the container by your own docker command? The launcher script will do it after a successful rebuild/bootstrap. Many people do it in that way without issue.

And what’s the point of mention python -m BaseHTTPServer 80 works OK? Your docker command mapped external port to 8080, which has nothing to do with whether 80 is accessible. You firewall may still blocking 8080.


I have copy and paste the last line of the > ./launcher rebuild app command is logging for your convenience, I haven’t start docker manually.

There I have pasted data when I have tried with 8080 but both 80 and 8080 case do not work.

Python on port 80 works fine.

No firewall issues seem to be in place.


Oh got your point about the docker command.

What hosing provider are you using? Do they have any external firewall in front of your server?

The netstate -na command you logged indicates that 8080 port is only listened on ipv6 address not ipv4. Is there any setting you’ve done regarding this?

Try curl and curl http://<your server IP>:8080 on your Discourse server to see whether you can access the 8080 port. If yes, that means your Discourse is up but some firewall between your client and server blocked it. If no, that means your Discourse is not listening on ipv4 address.

1 Like

It is working on but not from the eth0 interface (I have put back port 80):

curl: (56) Recv failure: Connection reset by peer

curl http:// <<>eth0 ip> :80
curl: (7) Failed connect to <<>eth0 ip>:80; Connection refused

If useful I see this log many many times by doing > ./launcher logs app :

nginx: [emerg] host not found in upstream “avatars.discourse.org” in /etc/nginx/conf.d/discourse.conf:215

Moreover, I have done a ssh tunnel (80->80) towards my local machine and connecting to my localhost:80 the connection is enstablished (TCP: SYN, ACK) but no welcome page (no page at all), the connection does not reach http level…

I exclude firewall issues since I have 2 proof:

  1. dummy python server listening on port 80 is accessible from outside
  2. ssh tunnel showed also at discourse is not accessible

What more could I do? :frowning:


This is very suspicious. Why you have a upstream pointed to avatars.discourse.org? You may need to upload the content of your app.yml file(with sensitive information removed) so we can check whether there is any incorrect configuration.

This is my app.yml:

  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"

## Uncomment these two lines if you wish to add Lets Encrypt (https)
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

  - "80:80"   # http
  - "443:443" # https

  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ## will be set automatically by bootstrap based on detected RAM, or you can override
  db_shared_buffers: "768MB"

  ## can improve sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

  LANG: en_US.UTF-8

 ## How many concurrent web requests are supported? Depends on memory and CPU cores.
  ## will be set automatically by bootstrap based on detected CPUs, or you can override

  ## TODO: The domain name this Discourse instance will respond to

  ## Uncomment if you want the container to be started with the same
  ## hostname (-h option) as specified above (default "$hostname-$config")

  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example 'user1@example.com,user2@example.com'

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

  ## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate

  ## The CDN address for this Discourse instance (configured to pull)
  ## see https://meta.discourse.org/t/14857 for details
  #DISCOURSE_CDN_URL: //discourse-cdn.example.com

  HTTP_PROXY: "http://XXX/"
  http_proxy: "http://XXX/"
  HTTPS_PROXY: "https://XXX/"
  https_proxy: "https://XXX/"


## The Docker container is stateless; all data is stored in /shared
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

    - exec:
        cd: $home/plugins
          - git clone https://github.com/discourse/docker_manager.git

## Any custom commands to run after building
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
  - exec: echo "End of custom commands"

I don’t see any incorrect settings in your app.yml. If you are following the official docker installation guide, you should have no problem. Could you describe any divergence from the official guide you did during installation?

You may also upload the /etc/nginx/conf.d/discourse.conf file in your discourse container so we can see where the mysterious nginx error came from.


this is part of the > /etc/nginx/conf.d/discourse.conf on which into the logs I see:

nginx: [emerg] host not found in upstream “avatars.discourse.org” in /etc/nginx/conf.d/discourse.conf:215

location /letter_avatar_proxy/ {
# Don’t send any client headers to the avatars service
proxy_method GET;
proxy_pass_request_headers off;
proxy_pass_request_body off;

  # Don't let cookies interrupt caching, and don't pass them to the
  # client
  proxy_ignore_headers "Set-Cookie";
  proxy_hide_header "Set-Cookie";
  proxy_cache one;
  proxy_cache_key $uri;
  proxy_cache_valid 200 7d;
  proxy_cache_valid 404 1m;
  proxy_set_header Connection "";
  proxy_pass https://avatars.discourse.org/;

Regards installation, I have followed the guide strictly.
The divergence I have done: edit app.yml putting an empty password for SMTP server.

This line indicates that your nginx is not able to resolve the upstream host avatars.discourse.org in the proxy_pass directive.

You may try ping avatars.discourse.org in your container and the host to see whether they can resolve the host name and reach it.

Is it actually a problem?

I mean, in case the host > avatars.discourse.org is not resolvable is it a blocking issue?

Why don’t you give it a try?

As far as I remember, nginx just won’t start if it encounter an emerg level problem. I believe that’s why you cannot access your Discourse - your nginx is just not running, it keeps starting but never can success. So you see a lot of those logs and your site is not accessible.

Even if you don’t believe so and try to find and solve the issue elsewhere, you still need to fix this problem eventually, so why not solve it now?

I see ^^
I was guessing it was a warning not so important.

root@XXX# ping avatars.discourse.org
ping: avatars.discourse.org: Name or service not known
root@XXX# ./launcher enter app
which: no docker.io in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/XXX/bin)
root@discuss:/var/www/discourse# ping avatars.discourse.org
ping: unknown host

Neither from the host machine and into the container is resolved.

I will investigate further this, thank you.


I have found out that http://discourse is resolved instead avatars.discourse.org fails.

Replace avatars.discourse.org with http://discourse, I can see the welcome page. :slight_smile:

Any idea why that could happen?

Since I see the welcome page… it is actually mandatory to make such hostname resolvable? If no, how can I make it permanent so in case of a ./launcher rebuild app I would have a correct configuration?


If you can’t resolve avatars.org you definitely have a problematic DNS setup for your server and that should be fixed. You may put /etc/resolv.conf file content here.

Ok, thank you.

How can I make such modification permanent in a way that in case of a rebuild of the container (app)?

What modification? Change the upstream avatars.discourse.org to disourse? You shouldn’t do so. Seeing the welcome page up doesn’t mean it is running correctly. I’m not sure but the location for avatars.discourse.org seems are for avatar functions, changing that may cause problems related to that.

No, I mean if I put it at /etc/resolv.conf than it would be erased in case of a rebuild…

Thus, is it possible to do some change through the app.yml?

I meant put the /etc/resolv.conf file content here so people can help check whether your DNS configuration is not correct…