[lxc-devel] [PATCH] python3: Allow setting daemonize and close_fds

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Fri, Nov 29, 2013 at 09:27:15AM -0600, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > This extends the list of arguments of start() allowing the user to
> > > request the container be started in the foreground and have control on
> > > whether fds will be closed or not (daemonize=True implies that too).
> > > 
> > > One problem at the moment however is that while we have functions to set
> > > close_fds and daemonize in the API, we don't have functions to unset
> > > those flags, so those new parameters will only work on the initial call
> > > to start() any further call will use the values of the previous one.
> > > 
> > > I think it'd make sense to change lxcapi slightly to have daemonize and
> > > close_fds offer a similar interface, both returning booleans and both
> > > accepting a value as a parameter so API users can set the value they
> > > want.
> > 
> > What would be the point in checking the value as opposed to simply
> > setting the one you want?
> > 
> > If unsetting is all we need, we could just add a boolean argument to
> > want_damonize and want_close_all_fds.  If there is a good reason to
> > be able to check the values, then we can either add a get_daemonize,
> > or make the second argument to want_daemonize an int, where -1 means
> > unset, 1 means set, and 0 means just give me the return value.
> > 
> > Or maybe we want to just add new api fns so as not to change the
> > existing api?  I'm feeling indecisive.
> 
> I don't want to check the values but I want to get error reporting.
> 
> Currently want_daemonize doesn't return anything so I don't know whether

Oh, gotcha.  Ok.

> the setting was save or not. want_close_all_fds solves that issue by
> returning a bool with true meaning that the value was saved and false
> meaning that something went wrong.
> 
> 
> Considering that we haven't commited to a stable API yet, I'd think that
> just adding a second argument to both functions to pass the state we
> want would be perfectly fine and it'll be trivial to update any code
> using that.
> 
> If you're happy with that, I'll send a patch later today doing just that.

Cool, thanks.