[lxc-devel] lxc-stop related bug in 2.6.37?

[Rob Landley]

On 01/13/2011 05:45 PM, Andreas Philipp wrote:
> 
> 
> On 13.01.2011 23:42, Daniel Lezcano wrote:
>> On 01/13/2011 08:30 PM, Andreas Philipp wrote:
>>> Hi all,
>>>
>>> After upgrading a machine to kernel version 2.6.35.8 to 2.6.37 my system
>>> froze each time when I issued a lxc-stop command. Unfortunately, I was
>>> not able to get any more information out of my box due to it freezing
>>> totally (no logs written to disk, nothing). Does anyone have experience
>>> with this (or a similar) issue?
>>
>> I just compiled a 2.6.37 and tested with a simple 'sleep' inside a
>> container and then stopped but the hang did not occur.
>> I also tried with an ubuntu container and busybox without problem.
>>
>> I tried on kvm x86_64
> In the meantime I tried to issue a 'halt' inside a container instead of
> issuing 'lxc-stop' on the host. This time now hang occurred. So, the
> suggestion is, if there is something going wrong, it goes wrong within
> lxc_stop.

You mean no hang occurred?

lxc_stop may be triggering a bug, but if the host is hanging the bug is
in the kernel.  No userspace program should be able to hang the entire
system.

So the question is, what's the kernel bug and how is lxc-stop triggering it.

Since a change in the kernel, not a change in lxc-stop, is what
triggered this behavor, then the easy way to track down what it was is
to git bisect the kernel to find the commit that introduced the
behavioral change.  (Assuming it's not buried in a range of "does not
compile" or "doesn't work for some other unrelatd reason" commits, which
is often the case with bisects through development versions of stuff.)

Another thing you could try is running strace on lxc-stop and telling us
what the last output it produces is.  That might tell us what lxc-stop
did to trigger the bug.  (Or it might hang before producing the relevant
output.)

Rob