How to manage the Elasticsearch service with systemctl in Linux

Managing the Elasticsearch service with systemctl lets an operator stop, start, restart, enable, and inspect a package-managed node during maintenance or startup recovery. Service control is most useful when a self-managed node needs a clean restart after configuration work or a quick status check before returning search traffic to it.

On Linux hosts installed from the official Debian or RPM packages, Elasticsearch runs as the systemd unit elasticsearch.service. The service commands themselves usually print little or no feedback, so the package log under /var/log/elasticsearch/ and a follow-up systemctl status check provide the practical proof that the node actually started.

Stopping or restarting the service removes that node from local indexing and search traffic while it shuts down and rejoins. In a cluster, follow service actions with a cluster health check because shard relocation, allocation delays, or startup timeouts can leave the process active before the cluster is ready for normal work.

Steps to manage the Elasticsearch service with systemctl in Linux:

Confirm that the Elasticsearch unit file exists.
```
$ systemctl list-unit-files elasticsearch.service
UNIT FILE             STATE   PRESET
elasticsearch.service enabled enabled

1 unit files listed.
```
A result of 0 unit files listed means the package is not installed on that host or the service has a nonstandard unit name.
Check whether the service is running.
```
$ systemctl is-active elasticsearch.service
active
```
Use inactive or failed as the signal to inspect status and logs before assuming the node is available.
Start the Elasticsearch service.
```
$ sudo systemctl start elasticsearch.service
```
Official packages do not print a successful start message at the terminal. The first start can take longer because security auto-configuration creates TLS material, and the initial elastic password is not printed when systemd starts the service.
Related: How to reset built-in user passwords in Elasticsearch

Check the service status after the start.

$ sudo systemctl status elasticsearch.service --no-pager
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-06-18 08:42:19 UTC; 28s ago
       Docs: https://www.elastic.co
   Main PID: 3241 (java)
      Tasks: 96 (limit: 15345)
     Memory: 1.8G
        CPU: 24.372s
     CGroup: /system.slice/elasticsearch.service
             └─3241 /usr/share/elasticsearch/jdk/bin/java ##### snipped #####

Active: active (running) confirms the systemd unit state. Application startup details still belong in the Elasticsearch package log.

Enable Elasticsearch at boot.

$ sudo systemctl enable elasticsearch.service
Created symlink /etc/systemd/system/multi-user.target.wants/elasticsearch.service -> /usr/lib/systemd/system/elasticsearch.service.

Use sudo systemctl enable --now elasticsearch.service only when the service should be started immediately as well as enabled at boot.

Confirm the boot-enable state.

$ systemctl is-enabled elasticsearch.service
enabled

Reload systemd after changing a unit override.
```
$ sudo systemctl daemon-reload
```
Run this after editing files under /etc/systemd/system/elasticsearch.service.d/ or after replacing a vendor unit file. Package-managed environment variables live in /etc/default/elasticsearch on Debian packages and /etc/sysconfig/elasticsearch on RPM packages.
Restart Elasticsearch after configuration or unit changes.
```
$ sudo systemctl restart elasticsearch.service
```
Elasticsearch sets TimeoutStartSec=900s by default. systemd version 238 or newer can extend the startup timeout while the process initializes; older versions can terminate a slow startup after the configured timeout.
Stop the Elasticsearch service.
```
$ sudo systemctl stop elasticsearch.service
```
Stopping the service makes that node unavailable for local indexing and search requests and can trigger shard movement elsewhere in the cluster.

Confirm that the service stopped.

$ systemctl is-active elasticsearch.service
inactive

Disable automatic startup when the node should stay offline after reboot.

$ sudo systemctl disable elasticsearch.service
Removed /etc/systemd/system/multi-user.target.wants/elasticsearch.service.

Review the package log when a service action has no terminal output.

$ sudo cat /var/log/elasticsearch/elasticsearch.log
[2026-06-18T08:42:12,104][INFO ][o.e.n.Node               ] [es-node-01] starting ...
[2026-06-18T08:42:27,944][INFO ][o.e.t.TransportService   ] [es-node-01] publish_address {10.0.0.21:9300}, bound_addresses {0.0.0.0:9300}
[2026-06-18T08:42:31,407][INFO ][o.e.h.AbstractHttpServerTransport] [es-node-01] publish_address {10.0.0.21:9200}, bound_addresses {0.0.0.0:9200}
[2026-06-18T08:42:31,611][INFO ][o.e.n.Node               ] [es-node-01] started
##### snipped #####

Official package installs write Elasticsearch application logs here by default. Removing --quiet from the unit's ExecStart line enables application logs in the systemd journal.

Check recent systemd unit events when the service does not start cleanly.
```
$ sudo journalctl --unit elasticsearch.service --since "10 minutes ago" --no-pager
Jun 18 08:42:10 es-node-01 systemd[1]: Starting Elasticsearch...
Jun 18 08:42:31 es-node-01 systemd[1]: Started Elasticsearch.
```
The journal is most useful for systemd start, stop, timeout, and exit-code messages. Use the package log for Elasticsearch node startup messages unless journal logging has been enabled for the service.

Verify cluster health after the service returns to active.

$ curl --silent --show-error --cacert /etc/elasticsearch/certs/http_ca.crt --user elastic:$ELASTIC_PASSWORD https://localhost:9200/_cluster/health?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "active_primary_shards" : 42,
  "active_shards" : 84,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0
}

A single-node cluster can report yellow when replicas are configured but no second node exists. Treat red or nonzero unassigned primary shards as a cluster problem before returning the node to normal traffic.
Related: How to monitor Elasticsearch cluster health