How to manage the Elasticsearch service with systemctl in Linux

Managing the Elasticsearch service keeps node availability predictable during maintenance, cluster changes, and startup recovery. Fast service control makes it easier to stop a node cleanly, bring it back after configuration work, and confirm that indexing and search capacity have actually returned.

On self-managed Linux hosts installed from the official Debian or RPM packages, Elasticsearch runs as the systemd unit elasticsearch.service. Routine lifecycle actions happen through systemctl, while package installs write application logs to /var/log/elasticsearch/elasticsearch.log by default instead of the systemd journal unless the unit is adjusted to remove --quiet from its ExecStart line.

Stopping or restarting a node can interrupt local requests and trigger shard relocation elsewhere in the cluster, so service actions are best followed by a status and log check. The first package start also performs security auto-configuration and can take longer than a routine restart, while older systemd releases before version 238 can time out long startups after 900s even when Elasticsearch is still initializing. When unit limits or environment variables need changes, add them through /etc/systemd/system/elasticsearch.service.d and reload units before restarting the service.

Steps to manage the Elasticsearch service with systemctl in Linux:

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

1 unit files listed.
```
If the command reports 0 unit files listed, the package is not installed on this host or the unit file is not named elasticsearch.service.

Check the current Elasticsearch service state.

$ sudo systemctl status elasticsearch --no-pager
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-02 06:58:14 UTC; 18s ago
   Main PID: 3241 (java)
      Tasks: 96 (limit: 15345)
     Memory: 1.7G (peak: 1.8G)
        CPU: 22.941s
     CGroup: /system.slice/elasticsearch.service
             └─3241 /usr/share/elasticsearch/jdk/bin/java ##### snipped #####

systemctl status is best for unit state and recent systemd events. Package installs write detailed startup logs to /var/log/elasticsearch/elasticsearch.log by default.

Start the Elasticsearch service.
```
$ sudo systemctl start elasticsearch.service
```
The first package start performs security auto-configuration, creates TLS material, and can take longer than a routine restart. When started under systemd, the initial elastic password is not printed to the terminal.

Related: How to reset built-in user passwords in Elasticsearch
Stop the Elasticsearch service.
```
$ sudo systemctl stop elasticsearch.service
```
Stopping the service makes the node unavailable for indexing and queries and can trigger shard relocation in the cluster.
Restart the Elasticsearch service after configuration changes.
```
$ sudo systemctl restart elasticsearch.service
```
Use a restart when node settings, JVM options, or package-managed environment values change. If the unit stays activating for a long time, inspect the package log file before retrying.
Reload the systemd manager configuration after changing an Elasticsearch unit override.
```
$ sudo systemctl daemon-reload
```
Run this after editing files under /etc/systemd/system/elasticsearch.service.d or replacing the vendor unit file, then start or restart the service so the new settings take effect.

Enable Elasticsearch to start automatically at boot.

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

Drop --now when only the boot behavior should change and the running service should be left alone.

Disable automatic startup for Elasticsearch.

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

Drop --now when the node should stay online until the next reboot.

Review recent Elasticsearch package logs.

$ sudo tail --lines=80 /var/log/elasticsearch/elasticsearch.log
[2026-04-02T06:58:14,318][INFO ][o.e.n.Node               ] [node-01] version[9.3.2], pid[3241], build[deb/85a5f0195d9c7d]
[2026-04-02T06:58:27,944][INFO ][o.e.t.TransportService   ] [node-01] publish_address {10.0.0.21:9300}, bound_addresses {0.0.0.0:9300}
[2026-04-02T06:58:31,407][INFO ][o.e.h.AbstractHttpServerTransport] [node-01] publish_address {10.0.0.21:9200}, bound_addresses {0.0.0.0:9200}
[2026-04-02T06:58:31,611][INFO ][o.e.n.Node               ] [node-01] started

The official package docs write start and stop feedback here by default, so this file is the first place to look when a service action returns no terminal output.

Follow the package log live during startup or restart.

$ sudo tail --follow /var/log/elasticsearch/elasticsearch.log
[2026-04-02T07:05:20,114][INFO ][o.e.n.Node               ] [node-01] stopping ...
[2026-04-02T07:05:33,948][INFO ][o.e.n.Node               ] [node-01] started

Press Ctrl+C to stop following the log stream.

Check the systemd journal only when journal logging has been enabled for the unit.
```
$ sudo journalctl --unit elasticsearch --since "10 minutes ago" --no-pager
Apr 02 07:05:14 node-01 systemd[1]: Stopping Elasticsearch...
Apr 02 07:05:20 node-01 systemd[1]: Started Elasticsearch.
```
Official package installs do not send Elasticsearch application logs to the journal until --quiet is removed from the unit's ExecStart command.
Verify both the current running state and the boot-enable state.
```
$ systemctl is-active elasticsearch.service
active
$ systemctl is-enabled elasticsearch.service
enabled
```
active and enabled confirm the unit state, but cluster allocation and shard recovery should still be checked after a node restart or stop/start cycle.

Related: How to monitor Elasticsearch cluster health