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

[Alexandru Gheorghe]

On 10/22/2014 06:50 PM, vivo75 at gmail.com wrote:
> Il 22/10/2014 17:43, Dwight Engen ha scritto:
>> 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())

    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)



> And init scripts generally return 0 and output a warning if the service
> is already started, it may be wise to follow the convention
Certainly, however, if you would like to base your next actions whether
the service is already started, should you want to parse of stdout/stderr?

IMHO a different return code (that's documented) is easier to go with in
order to scale the wrappers accordingly.

Btw, not all init scripts return 0 and output a warning (kudzu is an
example).

>>>> 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
> 

-- 
; Alexandru Gheorghe
; alghe.global {at} gmail {dot} com
; OpenPGP key ID 0xCAF985D2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141022/98e76b01/attachment.sig>