Job for elasticsearch.service failed because the control process exited with error code

Check vm.max_map_count first. Elasticsearch refuses to start if it is below 262144, and that bootstrap check fails more often than every configuration mistake combined. One command tells you, and one more fixes it.

sysctl vm.max_map_count

# fix for now, and persist it across reboots
sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-elasticsearch.conf

The log line is max virtual memory areas vm.max_map_count [65530] is too low. Setting it without the file works until the next reboot, which is why this failure often returns weeks later on a host nobody touched.

Read the cluster log, not the journal

Elasticsearch writes almost nothing useful to the journal. The real output goes to a log named after your cluster:

sudo ls /var/log/elasticsearch/
sudo tail -60 /var/log/elasticsearch/elasticsearch.log

Bootstrap check failures appear here as a numbered list, and Elasticsearch prints every one it found rather than stopping at the first. Read the whole list before changing anything.

The other causes, in order

1. The heap does not fit. A jvm.options file asking for more heap than the machine has makes the JVM fail to initialise, usually with Error occurred during initialization of VM or a flat refusal to allocate. Elasticsearch defaults to roughly half of RAM; a hand-set -Xms4g on a 2GB VPS will never start. Set -Xms and -Xmx to the same value, and keep it under half of physical memory:

   sudo grep -E '^-Xm' /etc/elasticsearch/jvm.options
   free -h

   Use the JVM heap calculator to size it against the actual memory available.

2. A tab in elasticsearch.yml. The file is YAML and forbids tabs for indentation. The parse error names a line that often looks correct on screen. Find them with grep -Pn '\t' /etc/elasticsearch/elasticsearch.yml.
3. Directory ownership. Elasticsearch runs as the elasticsearch user and needs its data, log and config directories:

   sudo chown -R elasticsearch:elasticsearch /var/lib/elasticsearch /var/log/elasticsearch
   sudo chmod 2750 /var/log/elasticsearch

4. Other bootstrap checks. Once a node binds a non-loopback address, Elasticsearch switches from development to production mode and enforces every check rather than warning. The common ones besides max_map_count are the file descriptor limit (needs 65535) and memory locking. This is why a node that worked on localhost fails the moment you set network.host.
5. Port 9200 or 9300 already bound. Usually a previous node that did not shut down: sudo ss -tlnp | grep -E ':(9200|9300) '.
6. A Java version mismatch. Only relevant if ES_JAVA_HOME points at a system JDK. Recent packages bundle their own JDK and ignore it, so unset the variable rather than trying to match versions.

Reading the exit code

status=1/FAILURE means the node started and a bootstrap check or configuration parse rejected it, so read the cluster log. status=78/CONFIG appears on some builds for configuration errors specifically. status=137 is SIGKILL and for Elasticsearch almost always the OOM killer, which brings you back to the heap sizing in cause 1. The full table is in the nginx version of this error.

How to stop it happening again

Two things prevent nearly every recurrence. Persist vm.max_map_count in /etc/sysctl.d/ rather than setting it live, so a reboot does not undo it. And size the heap from actual memory rather than copying a value from another host, since the same jvm.options file moved to a smaller machine fails immediately.

sysctl vm.max_map_count && sudo systemctl restart elasticsearch

Related

• JVM heap size calculator: work out correct Xms and Xmx values from your container or host memory.
• Job for nginx.service failed: the same systemd error, plus the full exit-code table.
• Job for mongod.service failed: another service whose YAML config rejects tab characters.