linux/poky.git/bitbake/lib/bb/server/process.py, branch uninative-2.1

bitbake: bitbake: cooker: don't stop file notifier when cooker is shutdown

2018-02-14T15:26:03+00:00

It should be live/exited with server rather than cooker, fixed: $ bitbake --server-only -T -1 Set MACHINE = "qemux86" in conf/local.conf $ bitbake quilt Set MACHINE = "qemuppc" in conf/local.conf $ bitbake quilt [snip] ERROR: When reparsing /workspace1/lyang1/poky/meta/recipes-connectivity/openssl/openssl_1.0.2m.bb.do_package, the basehash value changed from c216f7f4fdd3cf4a0b10b975a636426c to d5a8e9431ab261381752d7a64c7b2fa9. The metadata is not deterministic and this needs to be fixed. [snip] This is because the server doesn't know local.conf is changed since the notifiers are stopped, so it doesn't reparse, and then we would get the errors, let the notifiers live/exited with server can fix the problem. (Bitbake rev: a6a641cb9c5f3abe901b150da915372e295383d7) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: server/process: Increase runCommand timeout

2017-09-25T13:14:17+00:00

We were seeing cases where we could hit the 5s timeout on large/fast machines running many different tasks at once. Increase this to 30s since the main connection timeout path should no longer hit this slow path. [YOCTO #12116] (Bitbake rev: 131d4b8a5834781a93ed41e2967d8dcd4d80f29a) Signed-off-by: Richard Purdie

bitbake: server/process: ensure server failure log is limited to current session

2017-09-12T22:55:29+00:00

Printing the last 10 lines of bitbake-cookerdaemon.log when the server fails to start can sometimes result in printing the output from a previous run, which could lead the user completely down the wrong path in terms of the cause of the failure. Use a known start text containing the time which we can then look for when scanning through the log, and then grab the last 10 lines of that part instead. Fixes [YOCTO #11903]. (Bitbake rev: 567f2cf1bc455b4f3cfb1cbd7f25145360b05a62) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: process/cooker: Improve readypipe handling

2017-09-12T22:55:29+00:00

Issues in start are not being correctly detected by the current readypipe code. Change it to use specific "ready" or "fail" messages to correctly determine the correct failure mode and avoid bitbake seeming to hang (it does currently timeout eventually). [YOCTO #12062] (Bitbake rev: 60d4791e3dd05729d2a2adf6f3b203c80d466a73) Signed-off-by: Richard Purdie

bitbake: cooker: Change to consistent prefile/postfile handling

2017-08-31T22:30:03+00:00

Currently the original prefile and postfile passed when starting bitbake server are 'sticky'. With the new memory resident model this doesn't make sense as the server the system is started with isn't special. This patch changes the code so the prefile/postfile are used if specified on the commandline and not used otherwise. This makes the behaviour much more predictable and expected and as an added bonus simplifies the code. (Bitbake rev: 638d366234fad78f283d3a13a12b07cb0ccbe914) Signed-off-by: Richard Purdie

bitbake: process: Clean up connection retry logic

2017-08-24T12:48:40+00:00

Its possible for a connection to connect to the server as its shutting down but before its removed the socket file. This patch: a) Removes the socket file earlier to avoid connections. b) Handles EOFError in initial connections gracefully. These occur if the socket is closed during the server shutdown. c) Ensure duplicate events aren't shown on the console. This makes debugging these issues very very confusing. With these changes the backtrace that was concerning users is hidden and the server works as expected with a reconnect when it catches it in a bad state. (Bitbake rev: f45196cf84669723382730944dddc7eaf50826f2) Signed-off-by: Richard Purdie

bitbake: process: Ensure we call select() to know which fds to read

2017-08-22T18:50:25+00:00

There is an interesting bug in the current code where a sync command is not seen until the current async command completes, by which time the UI may have shut down. The reason is that if there are idle commands, we may not end up sleeping in the select call at all, partiularly under heavy load like parsing. Fix this by calling select with a zero timeout so that we see active fds and know to read from them. This fixes various problems toaster was having with the recent server changes. [YOCTO #11898] (Bitbake rev: bbcce58e824b2793abf50efa52db158ae16e23e4) Signed-off-by: Richard Purdie

bitbake: process: Increase server startup timeout

2017-08-15T23:04:38+00:00

We're seeing the server fail to start within 8s on heavily loaded autobuilders so increase this timeout to 30s which should be more than enough time. (Bitbake rev: 8d4c120ec46d6d7a54947c64d33e18cb60b60505) Signed-off-by: Richard Purdie

bitbake: process: Improve client disconnects

2017-08-15T23:04:38+00:00

There have been cases where the server could loop indefinitely and incorrectly handle client disconnects. In the EOFError case, ensure a full disconnect happens in the alternative disconnect path to avoid this. (Bitbake rev: 5e267f14bb0155889615f567a920af4a37eb3c6b) Signed-off-by: Richard Purdie

bitbake: server/process: Ensure we don't loop on client EOFError

2017-08-13T08:28:14+00:00

The server currently crashes if we hit an EOFError due to controllersock still being in ready and the continue meaning ready isn't re-evaluated. Setting the value to False can mean the shutdown code doesn't handle the situation cleanly. Clear ready to avoid the crash/loop instead and handle any OSError whilst we're in here. (Bitbake rev: 2bc47e887c3b41417edaa89a8708c223fd2085de) Signed-off-by: Richard Purdie