Re: restart (mktree) program usage

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
> 
> 
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
> >>
> >> Sukadev Bhattiprolu wrote:
> >>> Oren Laadan [orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org] wrote:
> >>> | 
> >>> | 
> >>> | 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.
> >>>
> >>> True. But if originally the application was started as:
> >>>
> >>> 	Create container
> >>> 	Login to contaienr
> >> Actually, I'm not sure what you mean by "login to container" ?
> > 
> > I assume he was thinking of a system container created with liblxc
> > or libvirt, and literally logging in on its console or over ssh.
> 
> This is exactly my point:
> 
> * If you checkpoint full container, you get the sshd (and init) as
> well, so you can't restore into an "existing" container, but create
> a new one.
> 
> * If you checkpoint subtree, you will miss orphans, and you will
> give up leak-detection.
> 
> I'd assume most users of this scenarios will prefer full container.

Yup, I think we are agreed.

-serge