[lxc-devel] [PATCH] lxcapi_restore shouldn't steal the calling process

[Tycho Andersen]

On Mon, Apr 06, 2015 at 12:03:55PM -0400, Stéphane Graber wrote:
> On Fri, Apr 03, 2015 at 11:02:11AM -0600, Tycho Andersen wrote:
> > On Fri, Apr 03, 2015 at 04:41:01PM +0000, Serge Hallyn wrote:
> > > Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > > > Previously, lxcapi_restore used the calling process as the lxc monitor process
> > > > (and just never returned), requiring users to fork before calling it. This, of
> > > > course, would cause problems for things like LXD, which can't fork.
> > > > 
> > > > Now, restore() forks the monitor as a child of the process that calls it. Users
> > > > who want to daemonize the restore process need to fork themselves.
> > > > lxc-checkpoint has been updated to reflect this behavior change.
> > > > 
> > > > Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
> > > 
> > > Thanks, Tycho.  I'm ok with it as is,
> > > 
> > > Acked-by: Serge E. Hallyn <serge.hallyn at ubuntu.com>
> > > 
> > > but there's one thing that could stand improvement (with a later
> > > patch).  The lxcapi_restore() will hang on many errors in the
> > > restoring task bc you don't always send a failure status back over the
> > > socket.  Yo ucoudl either alway ssend a failure status, or you could
> > > probably just select() before the read, though you'd have to guess at a
> > > decent timeout.
> > 
> > Good point. I think always sending a failure status sounds good; I'll
> > send a patch for that soon.
> > 
> > Thanks,
> > 
> > Tycho
> 
> This patch is failing to apply to current git master.
> 
> Please send a rebase version.

See attached.

Tycho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lxcapi_restore-shouldn-t-steal-the-calling-process.patch
Type: text/x-diff
Size: 7348 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150406/ab212e0d/attachment.patch>