Re: [libvirt] heisenbug in command.c

On 03/16/2012 03:52 PM, Jim Paris wrote: >Serge Hallyn wrote: >>On 03/16/2012 11:50 AM, Eric Blake wrote: >>>On 03/16/2012 10:36 AM, Serge Hallyn wrote: >>>>Hi, >>>> >>>>It seems I've run into quite the heisenbug, reported at >>>>https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/922628 >>>> >>>>It manifests itself as virPidWait returning status=4 for iptables (which >>>>should never exit with status=4). >>> >>>Maybe iptables isn't documented as exiting with $? of 4, but that's what >>>is happening. The libvirt code in question is quite clear that it >>>grabbed an accurate exit status from the child process. >>> >> >>Well, yes. I figured that either (1) iptables actually got -EINTR >>from the kernel and passed that along as its exit code, or (2) >>something went wrong with memory being overwritten in libvirt, >>however unlikely. Stranger things have happened. If (1), I was >>wondering if it was being ignored on purpose. > >Why do you bring up EINTR at all? Just because EINTR is 4? Yup. > That >seems very much unrelated. I didn't think so, but looks like you're right :) >This is from iptables: > >enum xtables_exittype { > OTHER_PROBLEM = 1, > PARAMETER_PROBLEM, > VERSION_PROBLEM, > RESOURCE_PROBLEM, > XTF_ONLY_ONCE, > XTF_NO_INVERT, > XTF_BAD_VALUE, > XTF_ONE_ACTION, >}; > >So it looks like iptables is returning RESOURCE_PROBLEM (which could >explain why it's intermittent). That makes a lot more sense then, yes. When scripting a bunch of parallel iptables rules adds (followed by waits), I do once in awhile get iptables: Resource temporarily unavailable. (and sometimes a -EINVAL message) though 'wait' still says status was 0. I've never gotten 4. The next run then succeeds. This still however sounds like src/util/iptables.c might ought to re-run the command if it gets 4.