Back to Help
Troubleshooting Self-Hosted ActiveCollab

ElasticSearch

Image

ActiveCollab uses ElasticSearch to power its search feature. ElasticSearch is an optional system requirement, but without it, ActiveCollab's search will always return empty results.

Checking ElasticSearch Status 

ElasticSearch is a web service that communicates using HTTP. This means that you can use your web browser to check its status. Just insert hostname and correct port number in the address bar of your browser.

When everything is OK, you will get a JSON response similar to this:


Two important bits are outlined on the screenshot:

  • ElasticSearch host. You will need to copy and paste this value into ActiveCollab when connecting the two systems,
  • ElasticSearch version. That info is needed for a compatibility check that is explained later in this troubleshooting guide.

If ElasticSearch is not running, or it is broken, you will not get that type of response. Instead, you will get a standard browser error that will declare that the service is unavailable. Example, from Google Chrome:


In that case, you need to check if you entered the host and ports correctly, and that ElasticSearch is actually running.

Version Compatibility

Different versions of ActiveCollab work with different versions of ElasticSearch. To verify that everything's OK, you need two bits of information:

  • ElasticSearch version. You can get it from ElasticSearch status response using your browser,
  • ActiveCollab version. It is available at the top of the System Settings page.

Once you have these two numbers, you can check the compatibility table on the System Requirements page to see if they match.

Error when Saving Settings 

There is a possibility that the system will error when you try to save ElasticSearch settings even though Test Connection reported that everything is OK.

The reason for this is that Test Connection just tests if it can connect to the ElasticSearch server and that there is a supported version of ElasticSearch responding. Save Settings goes beyond that and tries to create an index where search data will be stored.

This operation can fail for various reasons. To learn why index creation failed, you'll need to debug information, and you can get that by switching to Debug mode. When save settings fails, you will get more info in the browser console, as well as in /logs directory.

Cron Jobs Fail Because Index is Read-Only 

There are cases when the index is successfully created, and search data is rebuilt, but you get errors in cron job output looking something like this:

Exception Elasticsearch\Common\Exceptions\Forbidden403Exception:

  1. {
  2. "error": {
  3. "root_cause": [
  4. {
  5. "type": "cluster_block_exception",
  6. "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
  7. }
  8. ],
  9. "type": "cluster_block_exception",
  10. "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
  11. },
  12. "status": 403
  13. }

This means that the index is read-only, and that it does not accept operations that modify the data (indexing of new documents, or deletion of documents when items are deleted in ActiveCollab). To resolve this, you will need to take off the read-only flag from the index.

First, we'll need the index name. You can get it from the index status command that the ActiveCollab command-line tool provides. Navigate to the directory where ActiveCollab is installed on your server and run:

  1. php tasks/activecollab-cli.php search:index

That will print info about the index, including the name.

Now that you have the index name, modify this command to include the address of your ElasticSearch host, replace the index name with the correct one, and run it:

  1. curl -H 'Content-Type: application/json' -X PUT -d '{"index": {"blocks": {"read_only_allow_delete": "false"}}}' http://localhost:9200/INDEX-NAME/_settings

ElasticSearch should acknowledge the change.

Can’t find your answer?

Image