Serge E. Hallyn wrote: > Quoting Ferenc Wagner (wf...@niif.hu): >> Daniel Lezcano <daniel.lezc...@free.fr> writes: >> >>> Ferenc Wagner wrote: >>> >>>> I can see that lxc-unshare isn't for me: I wanted to use it to avoid >>>> adding the extra lxc-start process between two daemons communicating via >>>> signals, but it's impossible to unshare PID namespaces, so I'm doomed. >>> >>> There is a pending patchset to unshare the pid namespace, maybe for >>> 2.6.35 or 2.6.36 ... >> Then why does lxc-unshare insist on forking? > > I'm not sure what you mean - both the lxc version you mentioned, and > the newest commit in my git tree, go through lxc_clone(), which uses > clone, not fork.
Ferenc is referring to the "unshare pid namespace" patchset of Eric. http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-2.6.33-nsfd-v5.git;a=commit;h=a6d862ffdeca62c95f6a3e1a5ca7756e7fc9925a But as I explained, it is not yet in mainline. >> I thought unsharing the >> PID namespace was infeasible, because it changed the value returned by >> getpid(), but if more and more unsharing gets implemented, a >> PID-conserving helper would seem quite useful. Maybe not for >> virtualizing full systems, but very much for insulating batch jobs under >> the supervision of some scheduler (like SGE for example). ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
