[PATCH] [RFC] c/r: Add UTS support
Eric W. Biederman
ebiederm at xmission.com
Wed Mar 18 18:06:30 PDT 2009
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.
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.
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.
More information about the Containers