> On Sept. 21, 2012, 7 p.m., Vinod Kone wrote:
> > lgtm. i've a feeling we need to also do a force kill. but we can do this 
> > after we see how brian's test pans out.

I tried just setting FREEZING to the cgroup freezer.state manually and that 
didn't seem to work. Meanwhile, I sent a SIGKILL to the process in the cgroup 
still in R, and that got everything to cleanup. So I expect that you're 
correct, and we'll also need to send explicit SIGKILLs to those processes still 
in R (in fact, probably just to all processes still in the cgroup). Review 
incoming.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7203/#review11794
-----------------------------------------------------------


On Sept. 21, 2012, 2:02 a.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/7203/
> -----------------------------------------------------------
> 
> (Updated Sept. 21, 2012, 2:02 a.m.)
> 
> 
> Review request for mesos, Vinod Kone, Brian Wickman, and Jie Yu.
> 
> 
> Description
> -------
> 
> See summary and 
> http://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt:
> 
> It's important to note that freezing can be incomplete. In that case we return
> EBUSY. This means that some tasks in the cgroup are busy doing something that
> prevents us from completely freezing the cgroup at this time. After EBUSY,
> the cgroup will remain partially frozen -- reflected by freezer.state 
> reporting
> "FREEZING" when read. The state will remain "FREEZING" until one of these
> things happens:
> 
>       1) Userspace cancels the freezing operation by writing "THAWED" to
>               the freezer.state file
>       2) Userspace retries the freezing operation by writing "FROZEN" to
>               the freezer.state file (writing "FREEZING" is not legal
>               and returns EINVAL)
>       3) The tasks that blocked the cgroup from entering the "FROZEN"
>               state disappear from the cgroup's set of tasks.
> 
> 
> Diffs
> -----
> 
>   src/linux/cgroups.cpp 4efd06e 
> 
> Diff: https://reviews.apache.org/r/7203/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Reply via email to