Quoting Tamas Papp (tom...@martos.bme.hu):
> On 05/23/2013 03:39 PM, Tamas Papp wrote:
> > On 05/23/2013 03:35 PM, Stéphane Graber wrote:
> >> That looks like broken locking, though Serge would know for sure.
> >> You may want to try clearing /dev/shm/*lxc* and see if that fixes the
> >> problem (not usually recommended as those locks are there for a reason).
> > OK.
> >
> > At this moment I'm trying to reproduce the problem on a test machine, but
> > still no "luck".
> >
> > I'll let you know, as soon as I have something.
>
> Well, I still was success in this.
>
> No I have 3 other system with the symptoms (FUTEX_WAIT, segfaults).
>
> Regerding to lock file, I renamed /dev/shm/sem.lxcapi.jcb-vmc02 and it's
> recreated automatically. It
> is still there, no changes.
I'm in the process of replacing those locks. In the meantime, the
/dev/shm/sem.* files are removed when things exit normally, but
if you kill a lxc-* command while it is holding the lock, you
may have to remove it manually. If the commands are still running,
then of course they should still be there, as the intent is to keep
two programs which are both doing c->set_config_item("lxc.rootfs", x)
from overwiting each other.
I'll try to get the replacement for that ready for staging by
tomorrow night.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
