Santosh, that is the behavior I'm seeing. On May 4, 2016 6:13 PM, "Santosh Marella" <smare...@maprtech.com> wrote:
> > The second involves the cgroup hierarchy and the cgroup mount point. > Here > > the code attempts to create a hierarchy in $CGROUP_DIR/mesos/$TASK_ID. > > This is problematic as mesos will not unmount the hierarchy when the task > > finished (in this case the node manager) > > IIRC, when a task is launched by mesos, the agent creates > $CGROUP_DIR/mesos/$TASK_ID mount point to enforce cpu/mem for that task. > Once the task finishes, the agent should unmount the $TASK_ID. Are you > saying > that's not happening for NMs ? > > Santosh > > On Wed, May 4, 2016 at 10:30 AM, Darin Johnson <dbjohnson1...@gmail.com> > wrote: > > > I've been digging into groups support, there's a few things that are easy > > fixes but a few things become problematic so I'd like to discuss. > > > > First the code makes certain options dictated that can be placed in the > > yarn-site.xml - this should be done to remove code and provide > > flexibility. That's easy. > > > > The second involves the cgroup hierarchy and the cgroup mount point. > Here > > the code attempts to create a hierarchy in $CGROUP_DIR/mesos/$TASK_ID. > > This is problematic as mesos will not unmount the hierarchy when the task > > finished (in this case the node manager), it is also therefore unable to > > unmount it's own task hierarchy (This also creates the need to chmod a > > number of directories as a superuser). This leads to issues. An > > alternative approach would be to use the container-executor program > > (already suid w/ yarn's group) to create the hierarchy as > > $CGROUP_DIR/frameworkname if it doesn't exist, this may open another can > of > > worms as I haven't tested fully. > > > > Any thoughts or suggestions would be appreciated. > > > > Darin > > >
