为什么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被要求杀死一个任务？

回答

相关问题