restart (mktree) program usage

Oren Laadan orenl at
Wed Sep 9 15:26:04 PDT 2009

Sukadev Bhattiprolu wrote:
> I have a usage question on the 'restart' (formerly mktree) program.
> In the following container c/r case: 
> 	- create a container
> 	- log in to the container,
> 	- restore filesystem(s) from snapshot
> 	- restart application from checkpoint

FWIW, I'd expect that future versions of 'restart' will be capable
of doing this entire setup, (filesystem(s) included), as it matures.

Note that this use case that you suggest will only work to restart
subtrees; it is unsuitable for full containers (with pids) because
the pid of init (1) will already be in use.

Perhaps we should think of some "plugin" architecture for 'restart'
that will allow the user to ask it to execute some work at between
creating a new container and actually restarting into it ?

> On restart, suppose the user wants to restore the original pids.
> But he does not want to create a new pid-ns, (since he just created
> the container, and is sure the original pids are available).
> To accomplish this the user has to specify the arguments in the following
> order right  (since -pids implies --pidns).
> 	restart --pids --no-pidns
> IOW, the order of the arguments matters.
> Would it be easier to understand if --pids did not imply --pidns ?

Either that, or simply change the semantics such that the order
does not matter:

> (Or in fact the reverse seems to make more sense -i.e --pidns implies
> --pids, with a new option, --no-pids if user absolutely hates the pids
> he was dealt before checkpoint :-)
> 	$ restart
> 		don't create pid ns, don't try to restore pids
> 	$ restart --pids
> 		try to restore original pids, don't create pid-ns
> 	$ restart --pidns
> 		create new pid-namespace and restore original pids
> 	$ restart --pidns --no-pids
> 	$ restart --no-pids --pidns
> 		create new pid-namespace, DO NOT restore pids

Yes, something like that.


> Or maybe drop implying and let user explicitly specify one, none or
> both of --pids, --pidns ?
> Sukadev
> _______________________________________________
> Containers mailing list
> Containers at

More information about the Containers mailing list