Packaging changes

Previously someone could configure the $ES_USER and $ES_GROUP variables to change which user and group Elasticsearch was run as. This is no longer possible, the DEB and RPM packages now exclusively use the user and group elasticsearch. If a custom user or group is needed then a provisioning system should use the tarball distribution instead of the provided RPM and DEB packages.

Previous versions of Elasticsearch enabled setting path.conf as a setting. This was rather convoluted as it meant that you could start Elasticsearch with a config file that specified via path.conf that Elasticsearch should use another config file. Instead, to configure a custom config directory, use the ES_PATH_CONF environment variable.

Previous versions of Elasticsearch enabled using the CONF_DIR environment variable to specify a custom configuration directory for some configuration files and some scripts (it was used inconsistently). Starting in Elasticsearch 6.0.0, the usage of this environment variable has been superceded by ES_PATH_CONF, and this new environment variable is consistently used for all configuration files and scripts.

Previous versions of Elasticsearch enabled setting default.path.data and default.path.logs to set the default data path and default logs path if they were not otherwise set in the configuration file. These settings have been removed and now data paths and log paths can be configured via settings only. Related, this means that the environment variables DATA_DIR and LOG_DIR no longer have any effect as these were used to set default.path.data and default.path.logs in the packaging scripts.

Additionally, this means that if you were using the package distributions (i.e., you have installed Elasticsearch from the RPM or the DEB distributions), you had not previously explicitly configured path.data or path.logs, and you carry over your elasticsearch.yml file from 5.x, then you will need to add settings for path.data and path.logs. To use the defaults that you were implicitly using previously, you should add these lines to your elasticsearch.yml:

path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

(If you already had explicit values for either of these settings, you should of course preserve those). If you do not do this, Elasticsearch will refuse to start.

We previously attempted to ensure that Elasticsearch could be started on 32-bit JVM (although a bootstrap check prevented using a 32-bit JVM in production). We are no longer maintaining this attempt.

Related to the previous change that 32-bit is no longer supported, the default jvm.options file that ships with Elasticsearch no longer includes the -server flag. Previously, the installation of the Windows service would filter the -server flag because it is not compatible with the service. Since the default jvm.options file no longer includes -server, the filtering of this flag was removed from the installation of the Windows service. This means that if you have a jvm.options file that includes this flag you will need to remove it.

The environment variable ES_JVM_OPTIONS that enabled a custom location for the jvm.options file has been removed in favor of using the environment variable ES_PATH_CONF. This environment variable is already used in the packaging to support relocating the configuration files so this change merely aligns the other configuration files with the location of the jvm.options file.

The environment variable ES_INCLUDE could previously be used to establish the environment used to start Elasticsearch (and various supporting scripts). This legacy feature could be useful when there were several environment variables useful for configuring JVM options; this functionality had previously been replaced by Setting JVM options. Therefore, ES_INCLUDE has been removed.

Previous versions of Elasticsearch did not configure the JVM heap dump path. As such, the JVM would default to the working directory for the JVM. For the RPM and Debian package distributions this was a problem because the default would be /usr/share/elasticsearch, a path not writable by the elasticsearch user meaning that out of the box heap dumps would not be produced. It is a tragedy to not have this diagnostic information by default. Starting in Elasticsearch 6.0.0, the RPM and Debian packages configure the heap dump path to be /var/lib/elasticsearch. If this location is not suitable for receiving heap dumps (e.g., due to disk space concerns), you should adjust this path to a more suitable location.