Restarting container when internet is down causes discourse to fail


#1

It seems that if you have an intranet discourse site, even though it might have internet access, will no longer work if two factors come into play:

  1. Your internet access is down (for whatever reason)
  2. You decide to restart your discourse container during the same period.

Steps to reproduce.

  1. Make a local Discourse install and configure it so that is properly setup
  2. Unplug your network from the internet
  3. Restart your Discourse container ./launcher stop app then ./launcher start app
  4. Try to access the local Discourse site

After further checking.

The problem is caused by the nginx service not being able to find the host avatars.discourse.org found at line 220 of the discourse.conf file if the server has no internet access when trying to start. Once the internet connection is re-established nginx will start up. For that period of time your Discourse site will remain unusable. A workaround is to set line 220 of discourse.conf to:

proxy_pass https://localhost/;


Discourse in a closed intranet
(Jeff Atwood) #2

Hmm, maybe, but if you are setting up on intranet with no Internet access you should turn off the external web hosted avatars anyway in site settings.


#3

I agree but that change will only be applied once your site is functional or can start :laughing:

Hopefully this will help someone having the same issue. From all my tests since, Discourse is running fine. So glad I didn’t have to resort to phpBB.


(Sam Saffron) #4

The issue causing this is documented here:

I would like to change it so letter avatars are all served via the rails app which can be a lot smarter about dealing with a problem DNS entry an so on.

Just blanket failing to load NGINX cause avatars.discourse.org is not something we can allow.


Install discourse with internet access only via proxy
(Jeff Atwood) #5

Wouldn’t that cause a ton of extra load?


(Sam Saffron) #6

We heavily cache stuff in nginx would only hit the app once per avatar


(Matt Campbell) #7

I’ve opened two PRs to fix this:

  1. in discourse_docker
  2. in discourse

The second depends on the first.


(Jeff Atwood) #8

Thanks for that… what do you think @sam?