The essential one you have not mentioned is the shutdown escalation in the slave.
The executor driver and command executor shutdowns are orthogonal and are not strictly required given that Mesos will attempt to reliably shutdown the executor. However, a good executor implementation will comply with the shutdown request, this is why the command executor does signal escalation. The one in the executor driver is tougher to justify, but I suspect it was added as an additional layer of safety when using POSIX isolation. For example, if the executor driver is inside an executor that has "escaped" the process tree / group / session of the process forked by the slave, then the killpg of the executor driver would help. On Tue, Sep 2, 2014 at 3:46 PM, Alex Rukletsov <[email protected]> wrote: > Thanks for the answer, Benjamin. Let me reformulate my question a bit. For > me it looks like both do the same thing: after a certain timeout perform > hard shutdown. Maybe it makes sense to choose one approach and apply it > everywhere for consistency? > > > On Tue, Sep 2, 2014 at 8:56 PM, Benjamin Mahler <[email protected] > > > wrote: > > > Are you still wondering about this? > > > > ShutdownProcess is inside the libmesos executor driver and ensures that > we > > forcibly shutdown an executor if it doesn't comply with the shutdown > > request within the timeout. The second bullet in your list is the > "Command > > Executor", which is the executor that is used when only a TaskInfo is > > provided. Many frameworks use their own executor. > > > > > > On Wed, Aug 27, 2014 at 3:12 PM, Alex Rukletsov <[email protected]> > > wrote: > > > > > There are at least two mechanisms for shutdown by timeout in mesos: > > > * through the separate ShutdownProcess (src/exec/exec.cpp:383) > > > * delay in the same process (src/launcher/executor.cpp:325) > > > Why do we need two different ways of doing that? > > > > > > Regards, > > > Alex > > > > > >
