[lxc-devel] [PATCH] lxcapi_restore shouldn't steal the calling process
tycho.andersen at canonical.com
Mon Apr 6 16:38:18 UTC 2015
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7348 bytes
Desc: not available
More information about the lxc-devel