David Roberts 2608012422
Add temporary directory cleanup workarounds (#32615)
On some Linux distributions tmpfiles.d cleans files and
directories under /tmp if they haven't been accessed for
10 days.

This can cause problems for ML as ML is currently the only
component that uses the temp directory more than a few
seconds after startup. If you didn't open an ML job for
10 days and then tried to open one then the temp directory
would have been deleted.

This commit prevents the problem occurring in the case of
Elasticsearch being managed by systemd, as systemd private
temp directories are not subject to periodic cleanup (by
default).

Additionally there are now some docs to warn people about
the risk and suggest a manual mitigation for .tar.gz users.
2018-08-07 16:59:56 +01:00

24 lines
1.2 KiB
Plaintext

[[es-tmpdir]]
=== Temp directory
By default, Elasticsearch uses a private temporary directory that the startup
script creates immediately below the system temporary directory.
On some Linux distributions a system utility will clean files and directories
from `/tmp` if they have not been recently accessed. This can lead to the
private temporary directory being removed while Elasticsearch is running if
features that require the temporary directory are not used for a long time.
This causes problems if a feature that requires the temporary directory is
subsequently used.
If you install Elasticsearch using the `.deb` or `.rpm` packages and run it
under `systemd` then the private temporary directory that Elasticsearch uses
is excluded from periodic cleanup.
However, if you intend to run the `.tar.gz` distribution on Linux for an
extended period then you should consider creating a dedicated temporary
directory for Elasticsearch that is not under a path that will have old files
and directories cleaned from it. This directory should have permissions set
so that only the user that Elasticsearch runs as can access it. Then set the
`$ES_TMPDIR` environment variable to point to it before starting Elasticsearch.