----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61693/#review183101 -----------------------------------------------------------
src/slave/containerizer/composing.cpp Lines 656-657 (patched) <https://reviews.apache.org/r/61693/#comment259104> Hum, this does not look like the right solution to me. How is that different from user manually sending a `SIGKILL` to the leading process of the container, triggering a reap? Don't you have the same problem in that case? Why we do a special case here? A reap event should trigger a destroy of the container, leading to `wait` being returned. The component waiting for the container to terminate will then call destroy, causing the corresponding container in the composing containerizer being cleaned up. - Jie Yu On Aug. 16, 2017, 5:27 p.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61693/ > ----------------------------------------------------------- > > (Updated Aug. 16, 2017, 5:27 p.m.) > > > Review request for mesos, Gastón Kleiman, Gilbert Song, and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > The composing containerizer relies on users invoking `destroy()` > for removing the container from the list of active containers. > However, when using `kill()` the relevant containerizer just > reaps the container without notifying the composing containerizer > i.e., there is no `destroy()` invocation from the user. This change > chains on the `wait()` future to invoke `destroy()` that > eventually does the cleanup. > > > Diffs > ----- > > src/slave/containerizer/composing.cpp > f1a9c3d08b408aa61198f4042b9274df88b789ea > > > Diff: https://reviews.apache.org/r/61693/diff/1/ > > > Testing > ------- > > sudo make check (tests pass) > > > Thanks, > > Anand Mazumdar > >
