[lxc-devel] setns/fork(glibc) weird interaction, lxc-attach may hang sporadically

Christian Seiler christian at iwakd.de
Tue Apr 23 15:56:51 UTC 2013


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 the very beginning anyway in
order to make user namespaces work, so threading should be properly
taken care of at that point. So when the pthread_atfork() handlers are
called then, no deadlocks will occur and all the nss stuff should be
cleaned up. The clone in the subprocess should then be unproblematic.
Nevertheless, I've just played around with CLONE_PARENT in a simple
test program and it really has the advantage that we don't clutter up
the process list with too many attach processes, so I think clone is
definitely the better option than a direct syscall. (Also, we have
lxc_clone ready to use.)

>> My suggestion would be to use clone() and to use that occasion to
>> simplify the synchronization logic between all of those processes by
>> using CLONE_PARENT. If I can get an agreement on this, I'll 
>> implement
>> this, but I wanted to hear some thoughts in advance.
>
> Agreed.

Ok, thanks, I'll prepare a patch then.

-- Christian





More information about the lxc-devel mailing list