On Fri, 08 Feb 2013 14:05:55 -0800 ebied...@xmission.com (Eric W. Biederman) wrote:
> Josh Boyer <jwbo...@redhat.com> writes: > > >> So it looks mock is taking a buggy untested code path and things are not > >> working as it expected. > > > > Quite possibly, yes. I instrumented the kernel a bit and it is indeed > > failing in the alloc_pid call. > > > > Clark, thoughts here? > > I will just add the solution is probably for mock to fork immediate > after the unshare succeeds in creating a pid namespace. With the > original process waiting for mock to exit and the child process > doing everything that mock does now. > > That will allow mock to act as the init process in the pid namespace it > just created. > > Eric > Well, mock is not really setup to act as an init (i.e. reap all the child processes in the new namespace). Not really sure that's what I want anyway, verses just nuking CLONE_NEWPID and running in the same pidspace. I added some debugging output in the code around the unshare() calls and so far I can't seem to get unshare() to succeed when NEWPID is one of the flags. I'll admit that I'm running a realtime kernel (3.6.11-rt28 with CONFIG_PID_NS=y) so I'll boot into the latest F18 and make sure of this, but I'm leaning towards just removing NEWPID, since we weren't using it right and I'm not convinced that we need it. Clark
signature.asc
Description: PGP signature
