In previous versions of Elasticsearch, the default logging
configuration routed standard output to /dev/null and standard error to
the journal. However, there are often critical error messages at
startup that are logged to standard output rather than standard error
and these error messages would be lost to the nether. The default has
changed to now route standard output to the journal and standard error
to inherit this setting (these are the defaults for systemd). These
settings can be modified by editing the elasticsearch.service file.

In Elasticsearch 5.0.0 the -XX:+AlwaysPreTouch flag has been added to the JVM
startup options. This option touches all memory pages used by the JVM heap
during initialization of the HotSpot VM to reduce the chance of having to commit
a memory page during GC time. This will increase the startup time of
Elasticsearch as well as increasing the initial resident memory usage of the
Java process.

The default location for this file is in config/jvm.options if installing
from the tar or zip distributions, and /etc/elasticsearch/jvm.options if installing
from the Debian or RPM packages. You can specify an alternative location by setting
the environment variable ES_JVM_OPTIONS to the path to the file.

Previously when installing the Windows service, the installation script
would configure the thread stack size (this is required for the service
daemon). As a result of moving all JVM configuration to the
jvm.options file, the service installation script no
longer configures the thread stack size. When installing the Windows
service, you must configure thread stack size. For additional details,
see the installation docs.

Previously, the scripts used to start Elasticsearch and run plugin
commands only required a Bourne-compatible shell. Starting in
Elasticsearch 5.0.0, the bash shell is now required and /bin/bash is a
hard-dependency for the RPM and Debian packages.

Previously, Elasticsearch could be configured via environment variables
in two ways: first by using the placeholder syntax
${env.ENV_VAR_NAME} and the second by using the same syntax without
the env prefix: ${ENV_VAR_NAME}. The first method has been removed
from Elasticsearch.

Additionally, it was previously possible to set any setting in
Elasticsearch via JVM system properties. This has been removed from
Elasticsearch.

Previous versions of Elasticsearch would not halt the JVM if out of memory errors or other fatal
errors were encountered during the life of the Elasticsearch instance. Because such errors leave
the JVM in a questionable state, the best course of action is to halt the JVM when this occurs.
Starting in Elasticsearch 5.x, this is now the case. Operators should consider configuring their
Elasticsearch services so that they respawn automatically in the case of such a fatal crash.