I think it makes sense for `TASK_KILLED` to be sent in response to a KILL call irrespective of the exit status. IIRC, that was the original intention.
On Thu, Sep 21, 2017 at 8:20 PM, Qian Zhang <zhq527...@gmail.com> wrote: > Hi Folks, > > I'd like to collect the feedbacks on the task state TASK_FINISHED. > Currently the default and command executor will always send TASK_FINISHED > as long as the exit code of task is 0, this cause an issue: when scheduler > initiates a kill task, the executor will send SIGTERM to the task first, > and if the task handles SIGTERM gracefully and exit with 0, the executor > will send TASK_FINISHED for that task, so we will see the task state > transition: TASK_KILLING -> TASK_FINISHED. > > This seems incorrect because we thought it should be TASK_KILLING -> > TASK_KILLED, that's why we filed a ticket MESOS-7975 > <https://issues.apache.org/jira/browse/MESOS-7975> for it. However, I am > not very sure if it is really a bug, because I think it depends on how we > define the meaning of TASK_FINISHED, if it means the task is terminated > successfully on its own without external interference, then I think it does > not make sense for scheduler to receive a TASK_KILLING followed by a > TASK_FINISHED since there is indeed an external interference (killing task > is initiated by scheduler). However, if TASK_FINISHED means the task is > terminated successfully for whatever reason (no matter it is killed or > terminated on its own), then I think it is OK to receive a TASK_KILLING > followed by a TASK_FINISHED. > > Please let us know your thoughts on this issue, thanks! > > > Regards, > Qian Zhang >
