linux/poky.git/bitbake/lib/bb/server, branch krogoth-15.0.1

bitbake: bitbake: xmlrpc: set single use mode differently

2016-03-24T12:31:50+00:00

Currently xmlrpc server implicitly sets itself into single use mode when bitbake server is started with anonymous port (0) or no port is provided in command line. In this mode bitbake shuts down xmlrpc server after build is done. This assumption is incorrect in some cases. For example Toaster uses bitbake in this mode and expects xmlrpc server to stay in memory. Till recent changes single use mode was always unset due to the bug. When the bug was fixed it broke toaster builds as Toaster couldn't communicate with bitbake server in single use mode. Reimplemented logic of setting single use mode. The mode is explicity set when --server-only command line parameter is not provided to bitbake. It doesn't depend on the port number anymore. [YOCTO #9275] [YOCTO #9240] [YOCTO #9252] (Bitbake rev: afc0dd5c532684f6201b1e12bbf4c226ea19062d) Signed-off-by: Ed Bartosh Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie

bitbake: server/process: Try connecting 4 times before giving up

2016-03-09T22:47:29+00:00

Instead of trying one time with a timeout of 20 seconds try 4 times with a timeout of 5 seconds, to account for a slow server start. (Bitbake rev: 4a7fe63126dd8177baa5ad21e59e0bebeea8c596) Signed-off-by: Lucas Dutra Nunes Signed-off-by: Richard Purdie

bitbake: xmlrpc: fix bug in setting XMLRPCServer.single_use

2016-03-09T22:45:16+00:00

XMLRPCServer.single_use attribute was always set to False. This caused xmlrpc server to keep running after build is done as BitBakeServerCommands.removeClient only shuts down server if its single_use attribute is set to True. (Bitbake rev: 0a60b0928a0a746a60d2c2f294ff1903963c7086) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

bitbake: bitbake: Set process names to be meaninful

2016-01-30T11:43:56+00:00

This means that when you view the process tree, the processes have meaningful names, aiding debugging: $ pstree -p 30021 bash(30021)───KnottyUI(115579)───Cooker(115590)─┬─PRServ(115592)───{PRServ Handler}(115593) ├─Worker(115630)───bash:sleep(115631)───run.do_sleep.11(115633)───sleep(115634) └─{ProcessEQueue}(115591) $ pstree -p 30021 bash(30021)───KnottyUI(117319)───Cooker(117330)─┬─Cooker(117335) ├─PRServ(117332)───{PRServ Handler}(117333) ├─Parser-1:2(117336) └─{ProcessEQueue}(117331) Applies to parse threads, PR Server, cooker, the workers and execution threads, working within the 16 character limit as best we can. Needed to tweak the bitbake-worker magic values to tell the workers apart. (Bitbake rev: 539726a3b2202249a3f148d99e08909cb61902a5) Signed-off-by: Richard Purdie

bitbake: xmplrpc: split connect method

2016-01-06T15:27:35+00:00

Current code in connect method sets up event queue, which requires registering UI handler. This functionality may not be needed for some operations, e.g. for server termination. Moved functionality of setting up event queue in from 'connect' method to 'setupEventQueue' in BitBakeXMLRPCServerConnection class. (Bitbake rev: 4429871da76d6bd29e023ff42740fe7daa6b40fa) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

bitbake: uievent: add error to registerEventHandler return

2016-01-06T15:27:34+00:00

Current code throws Exception("Could not register UI event handler") if event handler can't be registered. The real reason of this is that cooker is in busy state. Error message lacks information about this. Added error message to the return value of registerEventHandler. Included returned error message into the log message and exception text. (Bitbake rev: 07de1ca7d57dcd0cc37406feae2949da12a3fa7a) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

bitbake: server/process: Handle SIGTERM more gracefully

2015-09-09T13:27:55+00:00

Currently if you send a SIGTERM to the bitbake UI process, the system basically hangs if tasks are executing. This is because the server process doesn't actually try any kind of shutdown before exiting. This patch trys executing a stateForceShutdown command first, which is enough to stop any active tasks before the system exits. I also noticed that terminate can execute multiple times, once at SIGTERM from the handler and once from the real exit. Double execution leads to stack traces and potential hangs (writes to dead pipes), so ensure the code only can run once. With these fixes, bitbake much more correctly deals with SIGTERM to the UI process. (Bitbake rev: 1032ddddbe3241da02ebb3608a1c40f9123b9e80) Signed-off-by: Richard Purdie

bitbake: event/server: Add _uiready flag to handle missing error messages

2015-09-04T15:23:56+00:00

If you start and suspend a bitbake execution so the bitbake lock is held, then try and run "bitbake -w '' X", you will see bitbake return an error exit code but print no message about what happened at all. The reason is that the -w option creates a "UI" which swallows the messages. The code which handles this exit failure mode thinks a UI has printed the messages and therefore doesn't do so. This adds in an extra parameter to the UI registration code so that we can figure out whether its a primary UI or not and base decisions on whether to display information on that instead. This fixes the error shown above and some bizarre failures on the Yocto Project Autobuilder. [YOCTO #8239] (Bitbake rev: d1d60a68c2de40c2984d5040d14251c1be121b0b) Signed-off-by: Richard Purdie

bitbake: Fix default function parameter assignment to a list

2015-08-19T17:05:44+00:00

With python you should not assign a list as the default value of a function parameter - because a list is mutable, the result will be that the first time a value is passed it will actually modify the default. Reference: http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments (Bitbake rev: 7859f7388f2e3f675d0e1527cfde18625f36f637) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: server/process: Don't log BBHandledException

2015-06-23T10:57:58+00:00

If we see a BBHandledException in the idle handler, the understanding is the system handled it, printing a log and traceback is just confusing. Therefore only print these in the cases where its an unknown/unhandled exception. (Bitbake rev: d88ecc2bc44dce8fd92ca3a2c0fd4124a5e464fa) Signed-off-by: Richard Purdie