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. ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users