Quoting Ferenc Wagner ([email protected]): > Daniel Lezcano <[email protected]> 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. > 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). > -- > Thanks, > Feri. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lxc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxc-users ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
