On Tue, 23 Apr 2013 12:55:49 -0400 Dwight Engen <dwight.en...@oracle.com> wrote:
> On Tue, 23 Apr 2013 15:03:49 +0100 > Christian Seiler <christ...@iwakd.de> wrote: [...] > > The question is: What do we do to resolve the other problem? I don't > > think the assert in glibc() in an by itself should necessarily go > > away, because in the vast, vast, vast majority of cases the check is > > very reasonable. > > > > The long-term solution for glibc could be to also wrap setns() to > > remember if it was called to enter a new pidns and in that case not > > to do the check, but otherwise still do it. > > > > But we don't know against what version of glibc lxc-attach is going > > to be build, so we need a better solution in the short term: > > Hi Christian, I agree we need a short term solution and one that works > with existing glibcs. My question is if you think that glibc will > eventually fix this at some point? I pulled down the most recent > core-utils to see if/how they had worked around it but it looks to me > like nsenter could possibly run into the same thing unless -F is > given. I can try to reproduce the hang with nsenter, which might help > encourage glibc to fix it sooner :) Sorry, I meant util-linux, not core-utils. ------------------------------------------------------------------------------ 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_apr _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
