[PATCH] [RFC] c/r: Add UTS support
mikew at google.com
Wed Mar 18 18:51:41 PDT 2009
Eric W. Biederman wrote:
> Mike Waychison <mikew at google.com> writes:
>> Eric W. Biederman wrote:
>>> Mike Waychison <mikew at google.com> writes:
>>>> Cedric Le Goater wrote:
>>>>> Dan Smith wrote:
>>>>>> SH> (Note that in Dan's next version, he did move unshare into
>>>>>> SH> userspace)
>>>>>> The idealist in me still wants it to be in the kernel. However, after
>>>>>> seeing it done I agree that it's the right thing to do, at least in
>>>>>> this case.
>>>>> I would say in all cases.
>>>>> as you can't unshare(CLONE_NEWPID),
>>>> Is there a particular reason the above doesn't work? I made an attempt to
>>>> implement it a while back, but haven't convinced myself that signals and
>>>> re-attaching a new struct pid to a running task is correct.
>>> Last time I was thinking about this I figured unsharing a pid namespace would
>>> simply place it's children in a different pid namespace, not the originating
>>> Would that semantic be useful? It would certainly be a lot less effort than
>>> changing the pid on a running process correctly.
>> Hmm, that would be a little odd. I think getting the unsharing task to become
>> pid 1 is a bit easier to understand and it makes it clear which task is the
>> reaper for the new namespace. Otherwise the first child becomes pid 1 but it
>> isn't the reaper.
> For very lightweight pid namespaces that may be desirable, and that is where
> all of this conversation originally started. I am happy to set the starting
> pid to 2 to avoid confusion on that point.
I wasn't really taking into consideration the notion of a 'lightweight'
pid namespace that didn't have a 'container-init' process.
> One of the other problems with changing the pid is that user space in general
> glibc in particular can not cope with the pid of a process changing.
> My memories are foggy at the moment but I do know that on the several occasions
> we have looked at unshare of the pid namespace it has failed due to kernel issues.
> I also remember I was close to having resolved the issues of unsharing the pid
> namespace if we did not change the pid of processing calling unshare.
Do you have pointers to discussions about these issues?
> You did not answer my question. I don't quite see how you were envisioning
> using unsharing the pid namespace as part of restart so I can't tell if my
> proposed semantics would work for that case.
Well, one way to look at doing restart with nested namespaces would be
to have userland go off and begin by rebuilding the process tree. While
rebuilding, any given process being recreated would need to have the
same pid in the parenting pid namespace (the outer most namespace in the
container). It would need to know if it 'got' the right pid, and if so,
would then create the new child pid namespace. Requiring CLONE_NEWPID
set on each and every clone(2) [*] would certainly be possible, as long
as we had some way for the task being created to know what it's parent
namespace pid is. I guess this could be done by a shared memory segment
shared between the parent and child of the clone as well, though it
doesn't seem as clear-cut to me.
[*] Yes, I'm dancing around the clone_with_pid issue..
More information about the Containers