[Lxc-users] lxc-unshare woes and signal forwarding in lxc-start

Daniel Lezcano daniel.lezcano at free.fr
Wed May 5 13:55:08 UTC 2010


Ferenc Wagner wrote:
> Hi,
>
> as of git 305bc646, the following happens:
>
> # strace -f lxc-unshare -s NETWORK
> [...]
> clone(Process 3085 attached (waiting for parent)
> Process 3085 resumed (parent 3084 ready)
> child_stack=0xbfe836d4, flags=0x40000000|SIGCHLD) = 3085
> [pid  3085] getpid()                    = 3085
> [pid  3085] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 3085 detached
> waitpid(3085, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0) = 3085
> --- SIGCHLD (Child exited) @ 0 (0) ---
> exit_group(11)                          = ?
>
> On the other hand, 'lxc-unshare -s NETWORK -- ifconfig -a' works all
> right.  If I read the history correctly, lxc-unshare now always forks,
> but the argument checking didn't follow this, so execvp fails when
> args=NULL.  The usage notes should also be changed to reflect this, and
> the -f switch is past as well.  "Ored list of flags" isn't particularly
> clear, btw, and also a little cumbersome to use on the command line.
> Why not do away with all the complexity of expression and parsing and
> enable repeated -s options?  Okay, it's a testing tool, but still... :)
>   
Agree, that makes sense.

> 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 ...

> 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.

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'.





More information about the lxc-users mailing list