about oe-init-build-env: Allow startup with and without memres

about oe-init-build-env: Allow startup with and without memres

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Hi Jason,

I noticed that this patch *oe-init-build-env: Allow startup with and
without memres* will kill any existing bitbake server when
oe-init-build-env is started. I think this always happens since I see no
way to source oe-init-build-env when BBSERVER is set.

I'm trying to figure out a better solution, since simply stopping the
server will leave toaster in an inconsistent state, if the server was
started through toaster.

Can you please tell me what behaviour are you trying to get out of the
system ? Let's try to find something that will also work for Toaster.

Cheers,
Alex

-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 849 bytes --]

Re: about oe-init-build-env: Allow startup with and without memres

[Jason Wessel]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On 01/03/2014 07:09 AM, Damian, Alexandru wrote:
> Hi Jason,
>
> I noticed that this patch *oe-init-build-env: Allow startup with and without memres* will kill any existing bitbake server when oe-init-build-env is started. I think this always happens since I see no way to source oe-init-build-env when BBSERVER is set.
>
> I'm trying to figure out a better solution, since simply stopping the server will leave toaster in an inconsistent state, if the server was started through toaster.
>
> Can you please tell me what behaviour are you trying to get out of the system ? Let's try to find something that will also work for Toaster.


It seems to me there must be a corner case, which should be easy enough to fix.  If the BBSERVER is set, it should simply attach to the existing instance, assuming the instance is reachable.  There is some code that was added to validate the bitbake server instance is healthy or it will get shutdown.

Do you have a step by step set of instructions to duplicate the behavior you are inquiring about or a bugzilla case I can take a peek at?

Thanks,
Jason.

[-- Attachment #2: Type: text/html, Size: 1904 bytes --]

Re: about oe-init-build-env: Allow startup with and without memres

[Jason Wessel]

[-- Attachment #1.1: Type: text/plain, Size: 1867 bytes --]

On 01/03/2014 08:19 AM, Jason Wessel wrote:
> On 01/03/2014 07:09 AM, Damian, Alexandru wrote:
>> Hi Jason,
>>
>> I noticed that this patch *oe-init-build-env: Allow startup with and without memres* will kill any existing bitbake server when oe-init-build-env is started. I think this always happens since I see no way to source oe-init-build-env when BBSERVER is set.
>>
>> I'm trying to figure out a better solution, since simply stopping the server will leave toaster in an inconsistent state, if the server was started through toaster.
>>
>> Can you please tell me what behaviour are you trying to get out of the system ? Let's try to find something that will also work for Toaster.
>
>
> It seems to me there must be a corner case, which should be easy enough to fix.  If the BBSERVER is set, it should simply attach to the existing instance, assuming the instance is reachable.  There is some code that was added to validate the bitbake server instance is healthy or it will get shutdown.
>
> Do you have a step by step set of instructions to duplicate the behavior you are inquiring about or a bugzilla case I can take a peek at?


I took a look at the code, you asked about and I believe the fix is quite simple.


2013-10-04 14:14 Richard Purdie     5cc4d31    ?    if [ -n "$BBSERVER" ]; then
2013-10-04 14:14 Richard Purdie     5cc4d31    ?       unset BBSERVER
2013-10-04 14:14 Richard Purdie     5cc4d31    ?    fi


I had not noticed this environment variable change.  When all the logic for dealing with BBSERVER was moved into the bitbake startup sequence it is no longer needed.  In fact, a bit further down in the in same file there is a check to deal with not killing anything when BBSERVER is set, but if it was already purged by the prior code there in lies the problem.

See the attached patch.

Cheers,
Jason.



[-- Attachment #1.2: Type: text/html, Size: 3236 bytes --]

[-- Attachment #2: 0001-oe-init-build-env-Allow-use-of-BBSERVER-if-it-is-set.patch --]
[-- Type: text/x-diff, Size: 1169 bytes --]

From 2372196669c929a6ad041f48c3b45a711eaa73a2 Mon Sep 17 00:00:00 2001
From: Jason Wessel <jason.wessel@windriver.com>
Date: Fri, 3 Jan 2014 08:37:43 -0600
Subject: [PATCH] oe-init-build-env: Allow use of BBSERVER if it is set

After commit d71059c86 (oe-init-build-env: Allow startup with and
without memres), the bitbake server can fully deal with BBSERVER being
set or unset.

The oe-init-build-env should no longer remove BBSERVER from the
environment such that other users such as the toaster may freely set
and use the init scripts.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 oe-init-build-env |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/oe-init-build-env b/oe-init-build-env
index 8ef32f3..78beeec 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -35,10 +35,7 @@ else
    else
       OEROOT="`pwd`"
    fi
-   if [ -n "$BBSERVER" ]; then
-      unset BBSERVER
-   fi
-    OEROOT=`readlink -f "$OEROOT"`
+   OEROOT=`readlink -f "$OEROOT"`
    export OEROOT
    . $OEROOT/scripts/oe-buildenv-internal && \
         $OEROOT/scripts/oe-setup-builddir && \
-- 
1.7.9.5

Re: about oe-init-build-env: Allow startup with and without memres

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

Thanks for replying.

I think that we're talking about different problems. What is see is:

- source oe-init-build-env and then launch toaster (source toaster start)
in a terminal; this will start a server and set BBSERVER in that terminal
- open a second terminal and source oe-init-build-env;  this will kill the
started server and leave the toaster in an inconsistent state

I'm wondering why we shutdown any bitbake server if the BBSERVER variable
is not set (last 8 lines of oe-init-build-env) ? I'm not sure I get the
reasoning behind this.
Is the idea to source oe-init-build-env after manually setting BBSERVER
variable in the second terminal ?

Alex


On Fri, Jan 3, 2014 at 2:42 PM, Jason Wessel <jason.wessel@windriver.com>wrote:

>  On 01/03/2014 08:19 AM, Jason Wessel wrote:
>
> On 01/03/2014 07:09 AM, Damian, Alexandru wrote:
>
> Hi Jason,
>
>  I noticed that this patch *oe-init-build-env: Allow startup with and
> without memres* will kill any existing bitbake server when
> oe-init-build-env is started. I think this always happens since I see no
> way to source oe-init-build-env when BBSERVER is set.
>
>  I'm trying to figure out a better solution, since simply stopping the
> server will leave toaster in an inconsistent state, if the server was
> started through toaster.
>
>  Can you please tell me what behaviour are you trying to get out of the
> system ? Let's try to find something that will also work for Toaster.
>
>
>
> It seems to me there must be a corner case, which should be easy enough to
> fix.  If the BBSERVER is set, it should simply attach to the existing
> instance, assuming the instance is reachable.  There is some code that was
> added to validate the bitbake server instance is healthy or it will get
> shutdown.
>
> Do you have a step by step set of instructions to duplicate the behavior
> you are inquiring about or a bugzilla case I can take a peek at?
>
>
>
> I took a look at the code, you asked about and I believe the fix is quite
> simple.
>
>
> 2013-10-04 14:14 Richard Purdie     5cc4d31    │    if [ -n "$BBSERVER" ];
> then
> 2013-10-04 14:14 Richard Purdie     5cc4d31    │       unset BBSERVER
> 2013-10-04 14:14 Richard Purdie     5cc4d31    │    fi
>
>
> I had not noticed this environment variable change.  When all the logic
> for dealing with BBSERVER was moved into the bitbake startup sequence it is
> no longer needed.  In fact, a bit further down in the in same file there is
> a check to deal with not killing anything when BBSERVER is set, but if it
> was already purged by the prior code there in lies the problem.
>
> See the attached patch.
>
> Cheers,
> Jason.
>
>
>


-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 4087 bytes --]