<div dir="ltr"><div>Thanks for replying.</div><div><br></div>I think that we're talking about different problems. What is see is:<div><br></div><div>- 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</div>
<div>- open a second terminal and source oe-init-build-env; this will kill the started server and leave the toaster in an inconsistent state</div><div><br></div><div>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.</div>
<div>Is the idea to source oe-init-build-env after manually setting BBSERVER variable in the second terminal ?</div><div><br></div><div>Alex</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 2:42 PM, Jason Wessel <span dir="ltr"><<a href="mailto:jason.wessel@windriver.com" target="_blank">jason.wessel@windriver.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 01/03/2014 08:19 AM, Jason Wessel
wrote:<br>
</div>
<blockquote type="cite">
<div>On 01/03/2014 07:09 AM, Damian,
Alexandru wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Jason,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
<br>
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.<br>
<br>
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?<br>
</blockquote>
<br>
<br></div></div>
I took a look at the code, you asked about and I believe the fix is
quite simple.<br>
<br>
<br>
2013-10-04 14:14 Richard Purdie 5cc4d31 │ if [ -n
"$BBSERVER" ]; then<br>
2013-10-04 14:14 Richard Purdie 5cc4d31 │ unset
BBSERVER<br>
2013-10-04 14:14 Richard Purdie 5cc4d31 │ fi<br>
<br>
<br>
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.<br>
<br>
See the attached patch.<br>
<br>
Cheers,<br>
Jason.<br>
<br>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alex Damian<div>Yocto Project<br></div><div>SSG / OTC </div></div>
</div>