Bug 12062 - bitbake server fails to start when there are config errors
Summary: bitbake server fails to start when there are config errors
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.4
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2017-09-07 14:38 UTC by Patrick Ohly
Modified: 2017-09-19 14:12 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Ohly 2017-09-07 14:38:27 UTC 
To reproduce (untested, I ran into this under slightly different conditions):
- set up a build directory
- bump LCONF_VERSION in bblayers.conf by 10
- run "bitbake core-image-minimal"

Expected behavior: image gets built

Actual behavior:

ERROR: Unable to start bitbake server
ERROR: Last 10 lines of server log .../bitbake-cookerdaemon.log:
  File ".../bitbake/lib/bb/cooker.py", line 357, in initConfigurationData
    self.databuilder.parseBaseConfiguration()
  File ".../bitbake/lib/bb/cookerdata.py", line 316, in parseBaseConfiguration
    raise bb.BBHandledException
bb.BBHandledException
ERROR: Your version of bblayers.conf has the wrong LCONF_VERSION (has ..., expecting ....).
Please compare your file against bblayers.conf.sample and merge any changes before continuing.
"meld conf/bblayers.conf /fast/work/intel-iot-refkit//meta-refkit/conf/bblayers.conf.sample"

is a good way to visualise the changes.

This probably also happens for other kinds of base config errors (local.conf version, syntax errors, ...) hence the rather generic issue summary.
Comment 1 Patrick Ohly 2017-09-07 14:38:50 UTC 
bitbake revision was 1ca2eec459424892391f060442ef38cf28d6a54a (current master).
Comment 2 Richard Purdie 2017-09-07 15:59:12 UTC 
If there is a configuration error then we need to report that configuration issue to the user and exit. That appears to be what happens here?

The server fails to start and prints the error. There is an open bug about a log separator to make the output a bit cleaner but I'm not sure what you're asking we fix here?
Comment 3 Patrick Ohly 2017-09-07 16:26:13 UTC 
(In reply to comment #2)
> If there is a configuration error then we need to report that configuration
> issue to the user and exit. That appears to be what happens here?

There was a long delay before the error was printed. I forgot to mention that.

> The server fails to start and prints the error.

But there was a bitbake process afterwards which was listening on bitbake.sock. So it did not fail entirely, it just didn't respond to the bitbake client.

> There is an open bug about a
> log separator to make the output a bit cleaner but I'm not sure what you're
> asking we fix here?

I'd expect the error to printed immediately.

As it stands now, initially I didn't  wait for the error to appear and aborted while trying to figure out why bitbake was apparently stuck doing nothing.
Comment 4 Richard Purdie 2017-09-07 21:38:53 UTC 
So the real bug here is that the UI takes time to return the message, the delay was the key missing detail. There is clearly some error in the timeout code path. 

You can reproduce this on poky by setting LCONF_VERSION = "12" in bblayers.conf.

Whilst I see bitbake.sock left behind, I don't see any processes left behind actually listening on that socket though?