Ferenc Wagner wrote: > 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.
Ok, got it. I think that makes sense to forward the signals, especially for job management. What signals do you want to forward ? ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
