[lxc-devel] [PATCH 3/9] lxc_start: ERROR if container is already running.

[Serge Hallyn]

Quoting Alexandru Gheorghe (alghe.global at gmail.com):
> 
> 
> On 10/22/2014 06:43 PM, Dwight Engen wrote:
> > On Wed, 22 Oct 2014 14:31:15 +0000
> > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > 
> >> Quoting Alexandru Gheorghe (alghe.global at gmail.com):
> >>> On 10/21/2014 07:54 PM, Serge Hallyn wrote:
> >>>> Quoting Dwight Engen (dwight.engen at oracle.com):
> >>>>> On Tue, 21 Oct 2014 09:58:29 -0500
> >>>>> Tycho Andersen <tycho.andersen at canonical.com> wrote:
> >>>>>
> >>>>>> On Tue, Oct 21, 2014 at 02:54:34PM +0000, Serge Hallyn wrote:
> >>>>>>> Quoting Tycho Andersen (tycho.andersen at canonical.com):
> >>>>>>>> On Tue, Oct 21, 2014 at 02:29:28PM +0000, Serge Hallyn wrote:
> >>>>>>>>> Quoting Tycho Andersen (tycho.andersen at canonical.com):
> >>>>>>>>>> On Fri, Oct 10, 2014 at 11:16:54AM +0800, Dongsheng Yang
> >>>>>>>>>> wrote:
> >>>>>>>>>>> We should exit with a error when starting a running
> >>>>>>>>>>> container.
> >>>>>>>>>>
> >>>>>>>>>> Is this intentional? I just noticed it when pulling from
> >>>>>>>>>> master that it breaks some of my scripts. Are we sure it
> >>>>>>>>>> doesn't break anything else?
> >>>>>>>>>
> >>>>>>>>> Which scripts does it break?
> >>>>>>>>
> >>>>>>>> No public ones, just some that I wrote myself. Just curious
> >>>>>>>> if the behavior change was intentional or not (I prefer the
> >>>>>>>> previous behavior :)
> >>>>>>>
> >>>>>>> What exactly is the change?  Did it used to return true
> >>>>>>> instead of false?  The intent was simply to shortcut a bunch
> >>>>>>> of extra work in the case where the container was already
> >>>>>>> running.
> >>>>>>
> >>>>>> Yes, sorry. It used to exit 0 instead of 1 when the container
> >>>>>> was already running (and didn't print any ERROR or anything).
> >>>>>
> >>>>> I also find this a bit inconsistent, we purposefully don't
> >>>>> report an error when doing stop on an already stopped container
> >>>>> (see the early return 0 in lxc_cmd_stop()). I think it can be
> >>>>> argued that its not an error since the command did what the
> >>>>> caller wanted (ensure the container is started/stopped).
> >>>>
> >>>> Ok - I don't want to revert the patch, but am happy to have it
> >>>> return 0.
> >>>
> >>> Why not return a different code, like 5, when is already running
> >>> (and trying to start)/stopped (and trying to stop it), so wrappers
> >>> can detect this and use the information further?
> >>
> >> Yup, that sounds good.  I could just do it I suppose, I've just been
> >> waiting for someone to send a patch :)
> > 
> > Won't that still break shell scripts that are testing $?
> Yes, it'll, thus, I assume we've two situations:
>     1) wrappers need to know if the state of the container is already in
> the desired state (i.e., start container if $?  is 5:
> commit_other_action())

Then they can test for "lxc-wait -n b1 -s RUNNING -t 0" before doing
lxc-start

>     2) already existing wrappers will break if retcode != 0, so they
> need backward compatibility
> 
> is there a way to sacrifice a way to fulfill the both? apply the patch
> for 5 retcode (or whatever number is used) but permit others to have
> backward compatibility to 0? (maybe a config param? [1])
> 
> 
> I assume the former (point 1) will permit more flexibility to certain
> situations should someone desire, while the latter (point 2) will allow
> the already existing ones that expect this behavior to still work.
> 
> 
> [1] the config param can be switched in between the context:
> a) could be that when is set to return 5 (patch sets as default 0 retcode)
> b) could be that when is set to return 0 (patch sets as default 5 retcode)
> 
> >>> Could this be useful? At least it will allow some more handling by
> >>> knowing if it's an error (1) or it really succeeded (0), and that is
> >>> already in the state wanted (5) when tried so.
> >>>
> >>> --
> >>> ; Alexandru Gheorghe
> >>> ; alghe.global {at} gmail {dot} com
> >>> ; OpenPGP key ID 0xCAF985D2
> >>>
> >>
> >>
> >>
> >>> _______________________________________________
> >>> lxc-devel mailing list
> >>> lxc-devel at lists.linuxcontainers.org
> >>> http://lists.linuxcontainers.org/listinfo/lxc-devel
> >>
> >> _______________________________________________
> >> lxc-devel mailing list
> >> lxc-devel at lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-devel
> > 
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> > 
> 
> -- 
> ; Alexandru Gheorghe
> ; alghe.global {at} gmail {dot} com
> ; OpenPGP key ID 0xCAF985D2
> 



> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel