爲什麼mesos-slave被要求殺死一個任務？

我正在運行一個mesos集羣，其中三個主站和從站當前位於同一臺機器上。爲什麼mesos-slave被要求殺死一個任務？

我的問題是，有一段時間我看到一個進程突然停止在馬拉松和Chronos。在檢查我看到的日誌之後，每次mesos-slave都要求框架去完成這些任務。我試過谷歌它，在這裏找到它，但我還沒有找到相關的答案。

我該如何記錄或瞭解爲什麼mesos-slave要求註冊框架中的一個殺死任務？

登錄相關線路如下：

Jan 25 02:48:58 hostname mesos-slave[9817]: I0125 02:48:58.143537 9843 slave.cpp:1372] Asked to kill task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:48:59 hostname mesos-slave[9817]: I0125 02:48:59.108821 9834 slave.cpp:2215] Handling status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 from executor(1)@192.168.49.1:42710 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:04.976814 9823 status_update_manager.cpp:317] Received status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.108389 9823 status_update_manager.hpp:346] Checkpointing UPDATE for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.280825 9848 slave.cpp:2458] Forwarding the update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 to [email protected]:5050 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.346415 9848 slave.cpp:2391] Sending acknowledgement for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 to executor(1)@192.168.49.1:42710 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.443266 9820 status_update_manager.cpp:389] Received status update acknowledgement (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.443447 9820 status_update_manager.hpp:346] Checkpointing ACK for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.419437 9833 slave.cpp:2898] Executor 'TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' of framework 20150311-145345-20031680-5050-2698-0000 exited with status 0 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.445489 9833 slave.cpp:3007] Cleaning up executor 'TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' of framework 20150311-145345-20031680-5050-2698-0000 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471329 9837 gc.cpp:56] Scheduling '/tmp/mesos/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2/runs/473a2313-0147-44ae-ab9c-b39f5a23be22' for gc 6.99999454929185days in the future 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471817 9837 gc.cpp:56] Scheduling '/tmp/mesos/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' for gc 6.99999454685037days in the future 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471911 9837 gc.cpp:56] Scheduling '/tmp/mesos/meta/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2/runs/473a2313-0147-44ae-ab9c-b39f5a23be22' for gc 6.99999454636444days in the future 
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471997 9837 gc.cpp:56] Scheduling '/tmp/mesos/meta/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' for gc 6.99999454594963days in the future

一個答案，我發現有相同的錯誤別人的問題，建議檢查它是否得到由OOM殺手殺死了，我查了，沒有內存不足問題，沒有相關的內核日誌。 mesos-slave本身的日誌是要求框架殺死它，所以我不認爲這是一個外部過程，如果我錯了，糾正我。

我目前使用的：
Mesos：0.21.1-1.2.debian77
馬拉松：0.8.0-1.1.97.debian77
的Chronos：2.3.2-0.1.20150207000917.debian77

我知道他們已經過時了，但這個問題似乎隨機影響隨機容器很長一段時間，即使它在未來的版本中發生得更少，我仍然困擾着爲什麼一個奴隸決定在沒有記錄任何理由的情況下殺死一個任務...

如果您需要更多日誌，只需詢問提供哪一個。我只包含這麼一點點，因爲那個容器運行了一天以上沒有任何問題或錯誤/警告登錄mesos或stderr，突然第一行出現在日誌中，要求奴隸殺死它。

來源

2016-01-26 Salaander

這些任務是否被殺死或遷移到其他奴隸？如果是這樣的話，這可能是在應用程序最初運行的從站上缺少資源的問題... – Tobi

任務在馬拉松中被終止後，它會再次啓動，但馬拉松不遵循正常的比例/升級過程，因爲它忽略了minimumHealthCapacity屬性;它只是簡單地殺了這個任務，並開始一個新的任務（有時在同一個主機上），而不用等待它的健康。如果一個Chronos任務被殺死，只計劃一次運行，它不會由Chronos重新啓動。這些行爲模式真的是有關...... – Salaander

請問爲什麼你不升級到更新版本的Mesos堆棧？ – Tobi

將健康檢查命令添加到您的馬拉松應用程序。馬拉松應用程序的新版本的寬限期（300秒）後殺死不健康的應用程序，它不斷重生一些其他的奴隸，把健康檢查

最簡單方法是如果健康檢查不使用pwd命令

工作中，嘗試增加CPU & RAM

來源

2016-05-17 12:35:39 HimalayanCoder

所有的應用程序都進行了健康檢查，如果它們變得不健康，可以在日誌中找到，但是這並未發生，因爲這樣會導致完美健康的運行碼頭集裝箱。 – Salaander

嘗試增加ram和cpu – HimalayanCoder

最近我們遇到了這個問題爲好。我們發現的是被OOM殺手實際殺死的任務。

它在docker's reference doc提到：如果發生失存儲器（OOM）錯誤

默認情況下，內核殺死過程在容器中。要更改此行爲，請使用--oom-kill-disable選項。

我們意識到OOM錯誤並不需要在mesos-slave主機（即docker主機）上，以防docker容器內存不足，而docker主機仍有空閒內存，這個過程也被殺死了。

在我們將--oom-kill-disable選項添加到我們的馬拉松任務後，問題就消失了。

"parameters": [ 
    { 
    "key": "oom-kill-disable", 
    "value": "true" 
    } 
]

來源

2016-07-05 08:37:22 fayndee

爲什麼mesos-slave被要求殺死一個任務？

回答

相關問題