There's no need to talk about unwelcome behaviour or power outages here,
and it caused at least one user some concern. This commit clarifies the
message.
Relates #95166
* Add note about ENV for systemd installs
This ES_TMPDIR env variable is not referenced in the /guide/en/elasticsearch/reference/current/setting-system-settings.html#sysconfig section, and when searching for the error mentioned in this page, it might not become too obvious.
* Restructure
---------
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
The systemd unit file is part of the Elasticsearch package and should
not be edited. Instead, we recommend creating a service override file.
This commit tweaks the docs for setting tmp dir with systemd to use the
override file instead of editing the unit file.
relates #93121
Today we suggest that users set `ES_TMPDIR` using `export`, which only
works if you're running things directly from the shell. Yet most users
encountering `ES_TMPDIR` problems seem to on RHEL and trying to run
things via `systemd`, for whom the `export` suggestion doesn't work.
This commit adds to the docs a suggestion of how to adjust the `systemd`
service file to set the appropriate environment variable.
Relates #80651
In #80617 we upgraded to a version of JNA which would report the message
`Failed to allocate closure` if the temp dir for `libffi` did not permit
executables (rather than crashing with a segfault). This commit extends
the docs to mention this message.
Today if `libffi` cannot allocate pages of memory which are both
writeable and executable then it will attempt to write code to a
temporary file. Elasticsearch configures itself a suitable temporary
directory for use by JNA but by default `libffi` won't find this
directory and will try various other places. In certain configurations,
none of the other places that `libffi` tries are suitable. With older
versions of JNA this would result in a `SIGSEGV`; since #80617 the JVM
will exit with an exception.
With this commit we use the `LIBFFI_TMPDIR` environment variable to
configure `libffi` to use the same directory as JNA for its temporary
files if they are needed.
Closes#18272Closes#73309Closes#74545Closes#77014Closes#77053
Relates #77285
Co-authored-by: Rory Hunter <roryhunter2@gmail.com>
If the underlying mount point for the JNA temporary directory is mounted
noexec on Linux, then the JVM will not be able to map the native code in
as executable. This will prevent JNA from executing and will prevent
Elasticsearch from being able to execute some functions that rely on
native code (e.g., memory locking, and installing system call
filters). We do not want to get into the business of catching exceptions
and parsing messages towards this because these exception messages can
change on us. We also do not want to jump through a lot of hoops to
check the underlying mount point for noexec. Instead, we will rely on
documentation to address this problem. This commit adds to the important
system configuration section of the docs that the JNA temporary
directory is not on a mount point with the noexec mount option.
