On Tue, 23 Apr 2013 19:30:07 +0100
Christian Seiler wrote:
> Hi again,
>
> > util-linux is affected the same way as far as I can tell (haven't
> > tried
> > it though), and should run into the assertion and fail for no good
> > reason.
>
> Btw. I just noticed: -F is actually worse than not usi
Hi again,
> util-linux is affected the same way as far as I can tell (haven't
> tried
> it though), and should run into the assertion and fail for no good
> reason.
Btw. I just noticed: -F is actually worse than not using -F. If you use
the -F flag for nsenter, nsenter itself will not fork(), bu
Hi,
> 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?
Actually, I was just compiling a bug report for glibc and I had another
look at the stack trace - it appears to
On Tue, 23 Apr 2013 12:55:49 -0400
Dwight Engen wrote:
> On Tue, 23 Apr 2013 15:03:49 +0100
> Christian Seiler 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 vas
On Tue, 23 Apr 2013 15:03:49 +0100
Christian Seiler wrote:
> Hi there,
>
> I've found a problem that comes from the interaction between setns()
> and glibc's implementation of fork() (at least on x86_64). It is
> rather complicated to describe, and forgive me if my mail is very
> long. I know of
Hi there,
>> - Call the fork syscall directly via syscall(__NR_fork)
>> Since lxc-attach is single-threaded anyway, the things glibc
>> does
>
> lxc-attach isn't but at some point we'll want attach in the API, and
> that is not single-threaded.
Now that I think about it, we do fork() in th
Quoting Christian Seiler (christ...@iwakd.de):
> Hi there,
>
> I've found a problem that comes from the interaction between setns()
> and glibc's implementation of fork() (at least on x86_64). It is rather
> complicated to describe, and forgive me if my mail is very long. I
> know of several ways
Hi there,
I've found a problem that comes from the interaction between setns()
and glibc's implementation of fork() (at least on x86_64). It is rather
complicated to describe, and forgive me if my mail is very long. I
know of several ways how to address the problem but wanted to have a
discussion
