# Logstash pipeline shutting off/starting order

**URL:** <https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423>\
**Category:** Logstash\
**Created:** [March 12, 2026, 11:45am UTC](https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423 "2026-03-12T11:45:40Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rnx](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@Rnx](https://discuss.elastic.co/u/Rnx)\
**Post date:** [March 12, 2026, 11:45am UTC](https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423/1 "2026-03-12T11:45:40Z")

</div>

How to force logstash to switch off pipelines in given order?

In my setup, I’m often receiving data via http input and distributing those messages among various pipelines based on content, however if I turn the logstash off, pipelines with elasticsearch output are turned off first so data in pipeline with http input just got stuck (and the logstash has to be “kill -9”ed.

DLQ didn’t help, it wont save stuck messages, and only error I get is “Maybe the destination pipeline is down or stopping? Will Retry.”

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [March 12, 2026, 6:35pm UTC](https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423/2 "2026-03-12T18:35:04Z")

</div>

Are you using pipeline-to-pipeline links? If so, I don’t think the ordering is documented, but at least one [bug](https://github.com/elastic/logstash/pull/10872) where shutdown hung due to ordering has occurred and been fixed. I believe that fix is specific to pipeline-to-pipeline and would not apply if you were using (for example) tcp-to-tcp.

Which version are you running and what does your set of inputs and outputs look like?

---

<div class="post-metadata">

**Author:** ![Rnx](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@Rnx](https://discuss.elastic.co/u/Rnx)\
**Post date:** [March 12, 2026, 8:21pm UTC](https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423/3 "2026-03-12T20:21:28Z")

</div>

Yes, it is simple pipe-to-pipe configuration:

```auto
input {
      http {
        port => 8081
        ecs_compatibility => "disabled"
      }
}
filter {
...
}
output {
        pipeline { send_to => "elasticpipeline" }
}

```

In logs, I can clearly see the proper termination of the “elasticpipeline”, however, since there are few more pipes to close, the “httppipeline” is closed (almost) last, so after a while i just get deadlock and message “Maybe the destination pipeline is down…”.

The bug you mentioned may be related to “beats” input maybe? That is quite stable, didn’t find any issues (deadlocks) with that so far.

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [March 12, 2026, 10:09pm UTC](https://discuss.elastic.co/t/logstash-pipeline-shutting-off-starting-order/385423/4 "2026-03-12T22:09:16Z")

</div>

I don’t think there is anything related to different inputs in the way thing works.

When the pipeline output starts, it registers its send\_to value, allowing the pipeline bus to know which outputs write to each input.

When the the shutdown method of the agent is called, it calls [pipeline\_bus.setBlockOnUnlisten](https://github.com/elastic/logstash/blob/34add6ca8e8d8b518267df2f1f63bbba8086f428/logstash-core/lib/logstash/agent.rb#L275), which sets [blockOnUnlisten](https://github.com/elastic/logstash/blob/34add6ca8e8d8b518267df2f1f63bbba8086f428/logstash-core/lib/logstash/agent.rb#L275) true (it defaults to false). When the pipeline input is asked to shutdown, it will [block](https://github.com/elastic/logstash/blob/34add6ca8e8d8b518267df2f1f63bbba8086f428/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBusV2.java#L81) if there are any pipeline outputs that send data to it (the [same is true](https://github.com/elastic/logstash/blob/e890049c1bf8127cd0b46cb3f3bc9a552511ddfe/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBus.java#L204) in the old V1 pipeline bus). I’m not really in a position to dig any deeper in the [PR](https://github.com/elastic/logstash/blob/34add6ca8e8d8b518267df2f1f63bbba8086f428/logstash-core/lib/logstash/plugins/builtin/pipeline/output.rb#L35) that implemented the V2 bus.

So the elasticpipeline input should be in a delay loop waiting for the elasticpipeline output to shutdown.

Does elasticpipeline actually complete its shutdown, or does it just finish shutting down its outputs?

There was a time when pipelines were shutdown in alphabetical order so you could help it by naming them 01\_foo, 02\_bar, etc. I have no idea if that is still true, and don’t know if it would fix anything (it may just shorten the time window for the problem to occur in).