<div dir="ltr">Hi,<div><br></div>I think staging (my head is @ 813a48...) started to stuck while creating containers concurrently after monitoring related changes. <div><br></div><div>I observed that issue with the Go bindings first. Then I wrote a test case to remove Go from the picture and I also thought that having a test case would be helpful (see "[PATCH] tests: Introduce lxc-test-concurrent for testing basic actions concurrently").</div>

<div><div><br></div><div>Normally one should see following </div><div><br></div><div>[caglar@qgq:~/Projects/lxc(staging)] sudo lxc-test-concurrent</div><div><br></div><div><div>Executing (create) for 5 containers...</div>

<div><br></div><div>Executing (start) for 5 containers...</div><div><br></div><div>Executing (stop) for 5 containers...</div><div><br></div><div>Executing (destroy) for 5 containers...</div><div> <br></div></div><div><br>

</div><div>but occasionally create started to stuck on my test system (just try to run couple of times). </div><div><br></div><div>Cheers,</div><div> </div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, Sep 12, 2013 at 10:41 AM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">Quoting Dwight Engen (<a href="mailto:dwight.engen@oracle.com">dwight.engen@oracle.com</a>):<br>
> On Thu, 12 Sep 2013 00:27:04 -0400<br>
> Stéphane Graber <<a href="mailto:stgraber@ubuntu.com">stgraber@ubuntu.com</a>> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > It looks like Dwight's last change introduce a bit of a regression<br>
> > when running lxc-start -d.<br>
><br>
> Yikes, sorry I didn't catch that in my testing. My follow on patch<br>
> for doing the monitor socket in the abstract space gets rid of this<br>
> entirely, so this is an additional reason to consider it.<br>
><br>
> > Tracing it down (added a ton of printf all over), it looks like it's<br>
> > hanging on:<br>
> >  - lxcapi_start<br>
> >    - wait_on_daemonized_start<br>
> >      - lxcapi_wait<br>
> >        - lxc_wait<br>
> >          - lxc_monitor_open<br>
> >            - lxc_monitor_sock_name<br>
> ><br>
> > Specifically, it's hanging at the process_lock() call because<br>
> > process_lock() was already called as part of lxcapi_start and only<br>
> > gets unlocked right after wait_on_daemonized_start returns.<br>
> ><br>
> ><br>
> > Looking at the code, I'm not even sure why we need process_lock there.<br>
> > What it protects is another thread triggering the mkdir_p in parallel,<br>
> > but that shouldn't really be a problem since running two mkdir_p at<br>
> > the same time should still result in the hierarchy being created, or<br>
> > did I miss something?<br>
><br>
> That sounds logical to me, but hmm, does that mean we don't need it in<br>
> lxclock_name() either (where I was modeling this on)? I wonder if<br>
> there is a code flow that its possible for us to hang there.<br>
<br>
</div></div>Well mkdir uses the umask right?  (and *may* use the cwd).  Both of<br>
which are shared among threads.  It won't set them, but something else<br>
might change them underneath them.<br>
<br>
So I could be wrong and we might not need it, but it seemed like we<br>
might.<br>
<span class="HOEnZb"><font color="#888888"><br>
-serge<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
------------------------------------------------------------------------------<br>
How ServiceNow helps IT people transform IT departments:<br>
1. Consolidate legacy IT systems to a single system of record for IT<br>
2. Standardize and globalize service processes across IT<br>
3. Implement zero-touch automation to replace manual, redundant tasks<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Lxc-devel mailing list<br>
<a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/lxc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>>
</div>