我正在运行一个mesos集群，其中有三个主服务器和三个从服务器目前在同一台机器上。
我的问题是，有时我会看到一个过程突然停止马拉松和计时。在检查了我看到的日志之后，每次，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 master@192.168.49.2: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.77
马拉松：0.8.0-1.1.97.77
时间：2.3.2-0.1.20150207000917.debian77
我知道它们已经过时了，但是这个问题出现了很长一段时间，似乎是在随机时间影响随机容器，即使它在未来的版本中发生得更少，我仍然很困扰为什么一个奴隶决定在没有记录任何原因的情况下杀死一个任务。。。
如果你需要更多的日志，只要问哪一个提供。我只包含了很少的内容，因为该容器在mesos或stderr中运行了一天多，没有任何问题或错误/警告日志，突然日志中出现了第一行，要求从服务器杀死它。
2条答案
按热度按时间qeeaahzv1#
向你的马拉松应用程序添加健康检查命令。新版本的马拉松应用程序在一个宽限期（300秒）后杀死了一个不健康的应用程序，并且它在其他一些从属应用程序上不断重生
进行健康检查的最简单方法是使用pwd命令
如果healthcheck不起作用，尝试增加cpu和ram
ct2axkht2#
我们最近也遇到了这个问题。我们发现这个任务实际上是被杀人凶手杀死的。
docker参考文件中提到：
默认情况下，如果发生内存不足（oom）错误，内核将终止容器中的进程。要更改此行为，请使用--oom kill disable选项。
我们意识到oom错误不需要在mesos从主机（即docker主机）上，如果docker容器内存耗尽而docker主机仍有空闲内存，进程也会被终止。
在我们添加
--oom-kill-disable随着问题的消失，我们可以选择马拉松式的任务。