> 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 >
