[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