Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the corresponding qemu process immediately. The proper fix is to
set hard_limit iff user has
On 20/08/13 17:10, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the corresponding qemu process immediately. The
On 08/20/13 12:08, Osier Yang wrote:
On 20/08/13 17:10, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
s/default,/default/
configured any, we set the zero in cgroup subsystem making the
On 08/20/2013 11:10 AM, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the corresponding qemu process immediately.
On 20.08.2013 14:11, Ján Tomko wrote:
On 08/20/2013 11:10 AM, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the
On 08/20/2013 03:09 PM, Michal Privoznik wrote:
On 20.08.2013 14:11, Ján Tomko wrote:
On 08/20/2013 11:10 AM, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero
