Stop Logstash safely

Stop Logstash through its service manager when one manages the process. For a directly launched process, send SIGTERM; in a foreground terminal, press Ctrl+C once. These request a controlled shutdown so Logstash can finish in-flight work.

# A systemd-managed service
sudo systemctl stop logstash

# A manually started process; replace 12345 with its verified PID
kill -TERM 12345

Check the PID before signaling a process. Ctrl+C normally sends SIGINT, not SIGTERM, but Logstash handles it as a shutdown request too.

Allow time for in-flight events

Shutdown coordinates the plugins and waits for events already being processed. Slow filters and an output waiting for an unavailable Elasticsearch cluster can delay completion. Examine Logstash's shutdown and stall-detection messages to identify the busy plugin.

Also check the supervisor's stop timeout. A service manager or container platform may force-kill the process when its grace period expires, even though Logstash itself is still trying to finish.

Understand persistent queue behavior

A normal shutdown does not necessarily empty a persistent queue. By default, Logstash completes in-flight events and leaves unread queued events for the next start. To drain the whole queue during shutdown, configure this before restarting Logstash:

queue.drain: true
pipeline.unsafe_shutdown: false

Draining can take a long time and depends on downstream recovery. Persistent queues reduce some loss risks, but durability still depends on checkpointing, storage, and the input's acknowledgment behavior. Reprocessing after a crash can also produce duplicates.

Avoid forcing termination as a routine stop procedure

kill -9 sends SIGKILL and prevents cleanup. A second Ctrl+C can force termination, as the shutdown warning explains. Either can lose work that exists only in memory. Do not assume every forced stop corrupts queue or sincedb files, but do not treat it as equivalent to a clean stop.

pipeline.unsafe_shutdown: true permits forced termination when shutdown stalls; it is a data-loss tradeoff, not a general performance setting.

Confirm completion with the service manager's status, the absence of the verified process, and shutdown logs. A single log line or a grep that matches itself is insufficient evidence.

References: shutting down Logstash and persistent queues.