# SIGTERM on master nodes

**URL:** <https://discuss.elastic.co/t/sigterm-on-master-nodes/228904>\
**Category:** Elasticsearch\
**Created:** [April 20, 2020, 4:40pm UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904 "2020-04-20T16:40:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tetiana](https://avatars.discourse-cdn.com/v4/letter/t/838e76/32.png) [@tetiana](https://discuss.elastic.co/u/tetiana)\
**Post date:** [April 20, 2020, 4:40pm UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904/1 "2020-04-20T16:40:36Z")

</div>

Hello, during the ES upgrade from version 7.2.1 to 7.3.2, I got:

```auto
{
  "root_cause" : [ {
    "type" : "master_not_discovered_exception",
    "reason" : null
  } ],
  "type" : "master_not_discovered_exception",
  "reason" : null
}

```

for each master reelection (3 master nodes)

From the logs, I see that the master election was started after the active master stopped by both left master nodes in about the same time.

Is it expected behavior that `SIGTERM` to an active master do not waits for a new master to be re-elected before the Elasticsearch process exits ? What is the recommended way to handle that?

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [April 21, 2020, 6:27am UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904/2 "2020-04-21T06:27:18Z")

</div>

`SIGTERM` means that the process was requested to be stopped by something. Elasticsearch cannot do that by itself.

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [April 21, 2020, 6:29am UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904/3 "2020-04-21T06:29:18Z")

</div>

In a cluster it is the master leaving that triggers election. This can not be initiated before the current master leaves.

---

<div class="post-metadata">

**Author:** ![tetiana](https://avatars.discourse-cdn.com/v4/letter/t/838e76/32.png) [@tetiana](https://discuss.elastic.co/u/tetiana)\
**Post date:** [April 21, 2020, 7:20am UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904/4 "2020-04-21T07:20:56Z")

</div>

Thank you for your replies.

Somehow during the upgrade, one of reelections took 2m33s. What could be recommended way to handle that behaviour? Add one more master node (so to get 4 in total, seems it should be handled correctly: [https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-voting.html#\_even\_numbers\_of\_master\_eligible\_nodes](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-voting.html#_even_numbers_of_master_eligible_nodes))? any other ideas?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 19, 2020, 7:21am UTC](https://discuss.elastic.co/t/sigterm-on-master-nodes/228904/5 "2020-05-19T07:21:02Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.