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

Ferenc Wagner wferi at niif.hu
Wed May 5 12:45:44 UTC 2010


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

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.
But now I see that signal forwarding was just added to lxc-init, would
you consider something like that in lxc-start as well?
-- 
Thanks,
Feri.

Ps: On a purely cosmetic account, it seems to me that struct start_arg
consists of pointers for no good reason.




More information about the lxc-users mailing list