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. Oren. > > Or maybe drop implying and let user explicitly specify one, none or > both of --pids, --pidns ? > > Sukadev > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
