Discourse installation failure

Hoping to learn more about how to troubleshoot the way that ApisCP handles this, so I can find a solution.

I added a new domain (made sure to enable postgres, cron/scheduling to account) and went to install Discourse as the first action. Some processes ran in the background for a bit, and the document root for the site is filled with files, but it ultimately failed and returned this error via email:

  • ERROR: Job failed - fatal error: fatal(): `discourse_install’: crash or other nasty error detected

Visiting the domain in browser returns “Forbidden” (just trying to load static content in the public directory for the Discourse install I gather).

I deleted the account, created a new one, and tested again. Result was the same. Fresh CentOS 7 install. It’s Hetzner’s CentOS 7 image if relevant, it might not be completely equivalent to an ISO install.

Bootstrapper will patch in whatever services it needs to make a platform whole. I’m able to install Discourse fine from command-line and from UI (2 GB, Katapult). Installing 2.4.0beta9 from Web > Web Apps works OK too. How much memory on the server? What does dmesg report? You may be hitting OOM conditions during asset compilation.

Does env DEBUG=1 cpcmd -d domain.com discourse:install domain.com give you any further feedback?

1 Like

64G, 8G assigned to account’s “package” (if you will).

Doesn’t appear to be anything relevant, as far as I can tell. Appreciate the thoughts :slight_smile:

Edit: Testing that last thing real quick

Interestingly pretty quiet:

[root@panel log]# env DEBUG=1 cpcmd -d {url removed} discourse:install {url removed}
[root@panel log]#

It did re-create the “html-discourse” directory and fill it with files, very quickly actually. It appears afterward to be taking no further actions (system appears as idle as can be), and 403 Forbidden is back on the domain.

tail -n 50 /usr/local/apnscp/storage/logs/start.log - check the backend log for any indication of what may have caused an abrupt termination (via DEBUGGING.md).

Discord’s the fastest way to tease out what’s going on. If you drop an test.html page under public/, does /test.html come up OK on the domain? If so, is a .htaccess present in there? You’ll see something similar to,

# Enable caching
UnsetEnv no-cache
DirectoryIndex disabled
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ http://localhost:40011/$1 [P,L,QSA]

Tis a bit vague, but above that is just a repeat of the same from the previous attempt, and then logs of me adding/removing domains:

No .htaccess in the public directory, but a test.html does work so it appears to be loading the static directory fine:

https://{url removed}/test.html

Will hop on Discord as well.

Perfect. That’ll allow me to figure out what’s going on with your case :+1:

Fixed in edge scheduled for inclusion in .24. Two issues:

2.4.0 beta requires Redis 4.0 per Sidekiq 6 dependencies. That will most likely wait for CentOS 8 compatibility rather than deploying via SCL to avoid conflict with Redis 3 used in other areas of the platform including panel, job queues, and rspamd. Installer will pick the best stable version now instead of betas from the list.

Second, CCPA mandate required MaxMind to put their GeoIP list behind a portal beginning of this year. Announcement was made December 18th and enforced on short notice two weeks later. I’ve backported discourse_ip_info.rb from master. Any install/update will apply this code prior to updating the database.

A GeoLite2 key is required at install time now or may be added for existing applications in config/discourse.conf as the key maxmind_license_key.