How to manage the Logstash service with systemctl in Linux

Managing the Logstash service keeps pipeline inputs, outputs, and queues predictable during configuration changes, package maintenance, and incident response, which reduces blind ingestion gaps and makes it easier to confirm when event flow has actually returned.

On current Debian and RPM package installs, Logstash runs as the systemd unit logstash.service, keeps settings under /etc/logstash, stores runtime data in /var/lib/logstash, and writes its internal logs to /var/log/logstash. The built-in monitoring API also listens on the local host by default and normally binds within the 9600-9700 range, so service checks usually combine systemctl state with a quick log review.

Package installs do not start Logstash automatically, and a restart pauses every active pipeline while inputs reopen, filters recompile, and outputs reconnect. Pipeline syntax errors or settings mistakes can also leave the unit in a failed state, so a clean status and log check after each action is more reliable than assuming the service came back correctly.

Steps to manage the Logstash service with systemctl in Linux:

Check the current Logstash service state.
```
$ sudo systemctl status logstash.service --no-pager --lines=0
● logstash.service - logstash
     Loaded: loaded (/usr/lib/systemd/system/logstash.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-04-07 08:53:45 UTC; 11s ago
   Main PID: 22164 (java)
      Tasks: 95 (limit: 28486)
     Memory: 962.4M
        CPU: 15.104s
```
The Loaded line shows the current boot-start state separately from the vendor preset, so disabled; preset: enabled still means the service will stay stopped after the next reboot.

Some Debian-family hosts show the packaged unit path as /lib/systemd/system/logstash.service instead of /usr/lib/systemd/system/logstash.service because both locations can map to the same merged-usr unit file.
Start the Logstash service.
```
$ sudo systemctl start logstash.service
```
No output means systemd accepted the start request, but a failed pipeline or JVM startup still requires a follow-up status or log check.
Stop the Logstash service.
```
$ sudo systemctl stop logstash.service
```
Stopping Logstash halts every active pipeline until the service starts again, so upstream shippers may buffer, back off, or drop events if they cannot queue locally.
Validate the packaged Logstash configuration before a restart.
```
$ sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash --path.data /tmp/logstash-configtest --config.test_and_exit
Using bundled JDK: /usr/share/logstash/jdk
##### snipped #####
Configuration OK
[2026-04-07T08:03:34,546][INFO ][logstash.runner          ] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash
```
Current Logstash 9.x packages default allow_superuser to false, so run this validation as the logstash service account unless that setting was intentionally changed.

The temporary --path.data path must be writable by the logstash user and keeps the test away from the service data directory in /var/lib/logstash.

Related: How to test a Logstash pipeline configuration
Restart the Logstash service after pipeline, plugin, or settings changes that require a reload.
```
$ sudo systemctl restart logstash.service
```
Restarting the service briefly pauses ingestion while all active pipelines stop and start again.

If config.reload.automatic is enabled in /etc/logstash/logstash.yml, pipeline file changes can be applied without a full service restart, but changes to logstash.yml, JVM options, installed plugins, or service unit settings still require one.

Related: How to enable Logstash pipeline reloads
Reload the systemd manager configuration after changing a Logstash unit override or drop-in.
```
$ sudo systemctl daemon-reload
```
Run this after editing files under /etc/systemd/system/logstash.service.d/, then start or restart logstash.service so the new unit settings take effect.
Enable Logstash to start automatically at boot.
```
$ sudo systemctl enable logstash.service
```
Use sudo systemctl enable --now logstash.service when the service should be enabled and started in one command.
Disable automatic startup for Logstash.
```
$ sudo systemctl disable logstash.service
```
Disabling changes only the next-boot behavior. Use sudo systemctl disable --now logstash.service when the service should be disabled and stopped together.

Review recent systemd journal lines for service lifecycle events and console-captured startup messages.

$ sudo journalctl -u logstash.service --since "10 minutes ago" --no-pager --lines=20
Apr 07 08:53:45 logstash-01 systemd[1]: Started logstash.service - logstash.
Apr 07 08:53:45 logstash-01 logstash[22164]: [2026-04-07T08:53:45,191][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600, :ssl_enabled=>false}
Apr 07 08:53:45 logstash-01 logstash[22164]: [2026-04-07T08:53:45,191][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}

Use sudo journalctl -fu logstash.service to follow new journal lines live during a restart or outage.

Review the packaged Logstash log file for pipeline compilation, JVM, or plugin errors.

$ sudo tail --lines=60 /var/log/logstash/logstash-plain.log
[2026-04-07T08:53:44,879][INFO ][logstash.runner          ] Starting Logstash {"logstash.version"=>"9.3.2"}
[2026-04-07T08:53:45,191][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600, :ssl_enabled=>false}
[2026-04-07T08:53:45,350][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}

Current Elastic docs place packaged Logstash logs under /var/log/logstash, so this file is the primary place to investigate syntax, plugin, JVM, and startup failures after a service action.

Use sudo tail -f /var/log/logstash/logstash-plain.log to watch startup progress until the service is stable.

Confirm the running state and boot-enable state explicitly.
```
$ systemctl is-active logstash.service
active
$ systemctl is-enabled logstash.service
enabled
```
active confirms the JVM is still running under systemd, and enabled confirms the unit is set to start again after the next boot. If inputs still are not receiving events, check the journal or /var/log/logstash/logstash-plain.log for pipeline-specific errors and confirm the monitoring API reports the expected pipelines.

Related: How to check Logstash pipeline metrics