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 ...
Good to know, but I'd like to stick with 2.6.32 if possible. >> But now I see that signal forwarding was just added to lxc-init, would >> you consider something like that in lxc-start as well? > > It's the lxc-init process who forward the signals. The lxc-kill sends > a signal to the pid 1 of the container. When lxc-init is the first > process, it receives the signal and forward it to the pid 2. Yes. > In the case of lxc-start, let's say 'lxc-start -n foo sleep 3600'. The > sleep' process is the first process of the container, hence if you > lxc-kill -n foo <signum>' command, that will send the signal to > sleep'. Sure, but it isn't me who sends the signals, but that who spawned lxc-start. I'd like to use lxc-start a wrapper, invisible to the parent and the (jailed) child. Of course I could hack around this by not exec-ing lxc-start but keeping the shell around, trap all signals and lxc-kill them forward. But it's kind of ugly in my opinion. -- Thanks, Feri. ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
