Serge E. Hallyn [se...@us.ibm.com] wrote:
| > diff --git a/restart.c b/restart.c
| > index b1518f2..a163862 100644
| > --- a/restart.c
| > +++ b/restart.c
| > @@ -530,6 +530,12 @@ int app_restart(struct restart_args *args)
| > ret = ckpt_coordinator(&ctx);
| > }
| >
| > + /*
| > + * Hack for LXC - which currently only uses pidns == 1, pid0 == 1;
| > + */
| > + if (ret >= 0)
| > + ret = global_child_pid;
| > +
|
| Hmm? Maybe I'm looking at the wrong context, but isn't this specifically
| the existing pidns case?
Yes it is.
| Should the second block ("new pidns with init")
| be the one to execute if your comment is correct?
Oh, you mean I could just return the global_child_pid from within the
"new pid ns with init" block ?. I could do that for now.
BTW, from a long-term API pov, should app_restart():
- support the other two types of restart ("new pidns without
init" and "subtree in current pidns"). LXC may not use those,
but any reason for the API to not support those cases ?
- If the API supports them, should app_restart() always return the
pid of the coordinator (i.e global_child_pid). That way the
caller knows the root of the restarted process-tree ?
- Also, like the kernel's API, how about app_checkpoint() and
app_restart() take a logfp/logfd and we send all the debugging
output to that file ?
Thanks,
Sukadev
|
| > return ret;
| > }
| >
| > --
| > 1.6.6.1
_______________________________________________
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
