summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/server
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: remove True option to getVar calls (take 2)Joshua Lock2016-12-161-1/+1
| | | | | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (a follow on patch to fix up a few recent introductions) (Bitbake rev: f9961fd5beb31d5ab9656a5be59f7ab3effef2f0) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: don't change UI process signal handler on terminatePaul Eggleton2016-12-141-1/+0
| | | | | | | | | | | | | | | | | | | | | On terminating the connection to the server, we were disabling SIGINT - and this is executed on the UI side. I'm not sure whether the intention here was to undo the SIGINT disabling we did in the server, and it was just a mistake that it disabled rather than restored and it's run on the wrong side, or whether we wanted to stop the user from breaking out of the shutdown code - the commit message provides no clues either way. Regardless, we do not want to permanently disable Ctrl+C here - it's legitimate to terminate the connection to the server and then re-establish it within the same process; at least currently, devtool modify by virtue of using tinfoil in two separate parts of the code does this, and the result of this disabling is that during the second tinfoil usage we can potentially be parsing all recipes without the ability to easily interrupt the process. (Bitbake rev: 58c60a951229dcbd8253863fb24228d046c23f6e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: send back 503 response with correct encodingPaul Eggleton2016-12-141-1/+1
| | | | | | | | | | | | If you send back a string here you get "TypeError: 'str' does not support the buffer interface" errors in bitbake-cookerdaemon.log and "IncompleteRead(0 bytes read, 22 more expected)" errors on the client side. (Bitbake rev: 0d659a7dfe5fb096f8aa4380320f9e2a464b3cb5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker process: fire heartbeat event at regular time intervalsPatrick Ohly2016-12-071-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | The intended usage is for recording current system statistics from /proc in buildstats.bbclass during a build and for improving the BB_DISKMON_DIRS implementation. All other existing hooks are less suitable because they trigger at unpredictable rates: too often can be handled by doing rate-limiting in the event handler, but not often enough (for example, when there is only one long-running task) cannot because the handler does not get called at all. The implementation of the new heartbeat event hooks into the cooker process event queue. The process already wakes up every 0.1s, which is often enough for the intentionally coarse 1s delay between heartbeats. That value was chosen to keep the overhead low while still being frequent enough for the intended usage. If necessary, BB_HEARTBEAT_EVENT can be set to a float specifying the delay in seconds between these heartbeat events. (Bitbake rev: 7cf22ea057d28c54bd98dc1ab7a43402a29ff1f5) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: implement idle timeout for xmlrpc serverEd Bartosh2016-07-211-3/+16
| | | | | | | | | | | | | | Idle timeout can be specified either by -T/--idle-timeout option or by sessing BBTIMEOUT environment variable. Bitbake xmlrpc server will unload itself when timeout exprired, i.e. when server is idle for more than <idle timeout> seconds. [YOCTO #5534] (Bitbake rev: 5fa0b3a19e7d0f40790f737abeddf499d53f1f6a) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: xmlrpc: implement check of connection to serverEd Bartosh2016-07-201-0/+17
| | | | | | | | | | | | | | | | | Implemented check_connection function. The purpose of this function is to check if bitbake server is accessible and functional. To check this this function tries to connect to bitbake server and run getVariable command. This API is going to be used to implement autoloading of bitbake server. [YOCTO #5534] (Bitbake rev: 1a18f5ceb478f766b53850451549333f655621ea) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: add parameter use_builtin_typesEd Bartosh2016-06-021-1/+1
| | | | | | | | | | | | Added use_builtin_types parameter to XMLRPCProxyServer.__init__ to fix this error: ERROR: Could not connect to server 0.0.0.0:37132 : __init__() got an unexpected keyword argument 'use_builtin_types' (Bitbake rev: ceb6e5bd33a25c45c2afe1559b9394c466db8a92) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Convert to python 3Richard Purdie2016-06-022-27/+29
| | | | | | | | | Various misc changes to convert bitbake to python3 which don't warrant separation into separate commits. (Bitbake rev: d0f904d407f57998419bd9c305ce53e5eaa36b24) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Fix missing log messages issueRichard Purdie2016-05-141-4/+4
| | | | | | | | | | | | | | | | | Currently if the server dies, its possible that log messages are never displayed which is particularly problematic if one of those messages is the exception and backtrace the server died with. Rather than having the event queue exit as soon as the server disappears, we should pop events from the queue until its empty before exiting. This patch tweaks that code so that even if the server is dead and we're going to exit, we return any events left in the pipe. This makes debugging certain failures much easier. (Bitbake rev: 29f6ade68fb2b506a23a7eb3a00cdcffa291b362) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: xmlrpc: set single use mode differentlyEd Bartosh2016-03-242-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ed.bartosh@linux.intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Try connecting 4 times before giving upLucas Dutra Nunes2016-03-091-4/+6
| | | | | | | | | | 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 <ldnunes@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: fix bug in setting XMLRPCServer.single_useEd Bartosh2016-03-091-3/+1
| | | | | | | | | | | | 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 <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Set process names to be meaninfulRichard Purdie2016-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: xmplrpc: split connect methodEd Bartosh2016-01-062-2/+5
| | | | | | | | | | | | | | 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 <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: add error to registerEventHandler returnEd Bartosh2016-01-061-2/+2
| | | | | | | | | | | | | | | 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 <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Handle SIGTERM more gracefullyRichard Purdie2015-09-091-0/+9
| | | | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: event/server: Add _uiready flag to handle missing error messagesRichard Purdie2015-09-042-2/+2
| | | | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: Fix default function parameter assignment to a listPaul Eggleton2015-08-192-3/+8
| | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Don't log BBHandledExceptionRichard Purdie2015-06-231-2/+3
| | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: cooker/server: Fix up 100% CPU usage at idleRichard Purdie2015-03-102-0/+6
| | | | | | | | | | | | | | | The recent inotify changes are causing a 100% cpu usage issue in the idle handlers. To avoid this, we update the idle functions to optionally report a float value which is the delay before the function needs to be called again. 1 second is fine for the inotify handler, in reality its more like 0.1s due to the default idle function sleep. This reverts performance regressions of 1.5 minutes on a kernel build and ~5-6 minutes on a image from scratch. (Bitbake rev: 0e0ba408c2dce14a0fabd3fdf61d8465a031495b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc server: delete function on errorsAlexandru DAMIAN2015-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | This patch makes sure to delete an idle function that raises an exception for the xmlrpc server. The counterpart functionality in the process server was added with: commit db50630948394bdcd361f3511af40c1896b1a017. duthor: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Wed Aug 20 22:31:06 2014 +0000 bitbake: process: Deal with infinite looping of the server This patch fixes [YOCTO #7316] (Bitbake rev: e7c9a6788d969c901fd6394416ac3936e62c4c72) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpcserver: do not connect client on errorAlexandru DAMIAN2015-03-091-0/+2
| | | | | | | | | | | We roll back the client connection if some error happens, like during setFeatures, as to leave the server accessible to other clients. (Bitbake rev: 4e4a2ee2f05f8741b2e09263e328420363975b02) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Fix select callRichard Purdie2015-01-231-1/+1
| | | | | | | | | | | | | There was a report that bitbake -e | less would use 100% cpu when it shouldn't really. The issue appears to be a bogus file descriptor in the select call. We shouldn't be blocking if there is event data pending to a *reader* from server context. [YOCTO #7138] (Bitbake rev: 8f166e1a0f3574ae7d1e917a8bb403b87bad15bf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Ensure abnormal exits set an error levelRichard Purdie2014-09-021-1/+1
| | | | | | (Bitbake rev: 8f5c1cdae1ee6ce04ae0d04d0b95bd80efbf7534) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Further improve robustness against server shutdownRichard Purdie2014-08-231-3/+14
| | | | | | | | | | | | | | | | | Currently, if an exception occurs in an event handler, the server shuts down but the UI simply hangs. This happens in two places, firstly waiting for events and secondly, sending events to a server which no longer exists. The latter does time out, the former does not. These patches improve both code sections to check if the main server process is alive and if not, trigger things to shut down gracefully. This avoids the timeout in the command sending case too. This resolves various cases where the UI would simply hang indefintely. (Bitbake rev: ac418e1112ff5f9c3157569316902f7a27fba4b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Deal with infinite looping of the serverRichard Purdie2014-08-231-0/+2
| | | | | | | | | | | | | | | Currently if an exception occurs, we just run the idle handler again and again, usually looping indefintely. Chances are the exception that occurred will keep occuring and this is not a good place to be. This was breaking the autobuilders with gigabytes of logs. At least improve things so the cooker shuts down gracefully when this happens. Some trace of the original problem may still be present on the console too! (Bitbake rev: 1f28d8d3311262427938180435b68f0a35c2b330) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: add support for token reusingAlexandru DAMIAN2014-06-131-7/+12
| | | | | | | | | | | | | | | | | | | | We add support to specify a connection token in the command line and in the environment variable BBTOKEN. When a client registers to a bitbake server, that client will have exclusive access to the server. The client is identified by a server-supplied token. If a client terminates, we cannot reconnect to the server as the token is lost. This patch adds the capability to specify the connection token in the command line for xmlrpc clients. This allows us to have bitbake work as an already-authenticated client with the server and resume sending commands to a server. (Bitbake rev: db5390940c0afbcdc9fbcf1225761968ae51d4a7) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: client - remove fatal errorsAlexandru DAMIAN2014-06-061-7/+14
| | | | | | | | | | | | | | | | | | | | | When we use the XMLRPC client API to connect to a bitbake server, we want to receive errors from the API instead of having the API exiting without warning. Thus the "bb.fatal" calls have been replaced with "bb.warn" calls, and we re-raise the original exception for handling by the original caller. The bitbake starting script has been modified to properly test for failures in calling the client API and handle them. Additional error handling added in the client, as to prevent fatal crashes. (Bitbake rev: eb63f08c33644f64752aaae2146a000956ce894a) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: move configuration reading codeAlexandru DAMIAN2014-06-061-24/+0
| | | | | | | | | | | | | | | The configuration reading code should live in the main bitbake entry point, and the server modules should be supplied with correct configuration instead of attempting to parse from configuration files. This patch moves the endpoint address reading from XMLRPC to the bitbake main script. (Bitbake rev: ac5753274ff932e1d6f073ab4dab7bd6fe5355a1) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: mark setFeatures command as read-onlyAlexandru DAMIAN2014-04-011-1/+1
| | | | | | | | | | | | | | | | This patch makes sure that the setFeatures command is marked as read-only and that it can only run if the cooker is in the initial state. Additionally, remove logging from the XMLRPC module in favor of sending the exception to the client for easy processing. [YOCTO #6089] (Bitbake rev: f0a1a3e24757f7658d272035620465f92a3e4c3c) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: Simlify featureset handlingRichard Purdie2014-03-301-9/+8
| | | | | | | | | | Rather than passing featureset around various places where the data doesn't really belong, run a command at connection time to set the appropriate features. This is similar to what the process server does. (Bitbake rev: c3b5cc5691291c74dd315c4439c80e0e4b2b5c1d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Optimise latency when finishing idle functionsRichard Purdie2014-03-101-0/+1
| | | | | | | | | | When idle functions finish, its likely we have some other work to do, so don't sleep in the select call but instead, skip it. This removes small amounts of latency in common commands. (Bitbake rev: 069d6538f83b607cb46c6fe21bf6c596e8b99242) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Drop unnecessary exit delayRichard Purdie2014-03-101-1/+0
| | | | | | | | | | When the server exits, we no longer appear to need this delay. This is likely due to improvements in the various exit codepaths. There is therefore no longer any point in taking the latency hit. (Bitbake rev: 8e75ee29ae07e13f23525c5c6045fbf6cdbe7675) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Use a pipe for quit events instead of Event()Richard Purdie2014-03-101-5/+9
| | | | | | | | | | | | | | Its not possible to notice the change of status of an Event() in the select call we sleep in. It would be possible in python 3.3 but for now use a pipe instead. This removes small latency when bitbake commands finish since the system doesn't sit in the select call. (Debugging these kind of issues is apparent by setting a long sleep for the select call) (Bitbake rev: def28239b0f0d5f1cf13214b263114a5328538b7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Deal more gracefully with SIGTERMRichard Purdie2014-03-101-1/+15
| | | | | | | | | | | | Currently a SIGTERM to the UI process causes the UI simply to lock up. By setting an exit flag, the waitEvent can raise a SIGINT, allowing the UI to break out the event loop and exit. Currently this is results in a traceback but that is more desirable than a hanging process. (Bitbake rev: 0d12041eceeae6bba2034b04913bb13abd67bd15) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Use the setFeatures command on the server instead ↵Richard Purdie2014-03-101-13/+8
| | | | | | | | | | | | | | | of a manger The use of a manager in the process server causes some issues since it remains around for the lifetime of the server even though its only used during initialisation and the system doesn't respond well to SIGTERM events to the extra process (and two threads) the implementation involves. Switching to a dedicated command simplifies the server process structure. (Bitbake rev: 74532a7cf8ccea8b85f1cda5d5bc23d2f3c72a08) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake.lock: Add host:port to bitbake.lock for memres serverJason Wessel2013-12-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea is to build on the --status-only option for bitbake and expose a mechanism where the oe init scripts can easily switch between memres server and the non-memres server. In the case of the standard oe init script the following can shut down the server: if [ -z "$BBSERVER" ] && [ -f bitbake.lock ] ; then grep ":" bitbake.lock > /dev/null && BBSERVER=`cat bitbake.lock` bitbake --status-only if [ $? = 0 ] ; then echo "Shutting down bitbake memory resident server with bitbake -m" BBSERVER=`cat bitbake.lock` bitbake -m fi fi A similar function can be used to automatically detect if the server is already running for the oe memres init script. This new functionality allows for the memres init script to be started in a new shell and connect up to an alaready running server without seeing the error of trying to start the server multiple times. (Bitbake rev: b1803958de8d7c3c3279841e38604a08dc2316cc) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake, xmlrpc.py: Implement memory resident auto port ↵Jason Wessel2013-12-021-4/+29
| | | | | | | | | | | | | | | | | | | | | | configuration/restart This patch adds the ability to dynamically select a port for the bitbake memory resident server when the BBSERVER port is set to -1. This allows for running multiple instances of the bitbake memory resident server on the same system in different build directories. The client portion of the bitbake instance can also request that the server automatically start when using the auto port feature. This is to deal with a bitbake instance that eventually times out and exits or that has died for some unknown reason. The new functionality allows for lazy startup of the server after sourcing the init script for the memory resident functionality. (Bitbake rev: d6abc07ff385357d312d8435b89e0a9c1f965433) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: Show a better error message for connection failuresRichard Purdie2013-10-071-3/+6
| | | | | | | | | Showing a traceback when unable to connect to a bitbake server is rather ugly. This change allows us to show a sensible error message. (Bitbake rev: 26913202f83fbbecdce95da59515af102bcde4a7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker,xmlrpc,servers: implement CookerFeaturesAlexandru DAMIAN2013-09-223-13/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementing feature set selection that allows a client to enable specific features in the server at connection time. Only enabling of features is supported, as there is no way to safely remove data loaded into the cooker. Once enabled, a feature will remain enabled for the life of the cooker. Client-server connection now supports specifying the feature set required by the client. This is implemented in the Process server using a managed proxy list, so the server cooker will now load dynamically needed features based on what client connects to it. In the XMLRPC server the feature set is requested by using a parameter for registerUIHandler function. This allows observer-only clients to also specify features for the server. The server code configuration now is completly separated from the client code. All hardcoding of client knowledge is removed from the server. The extra_caches is removed as the client can now specify the caches it needs using the feature. The UI modules now need to specify the desired featureSet. HOB is modified to conform to the featureSet specification. The only feature available is CookerFeatures.HOB_EXTRA_CACHES which forces loading the bb.cache_extra:HobRecipeInfo class. (Bitbake rev: 98e594837aab89ea042cfa9f3740d20a661b14e2) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Rename confusing 'stop' state to 'forceshutdown'Richard Purdie2013-09-141-1/+1
| | | | | | | | | | | | The shutdown state causes the server to finish what its doing, stop was them meant to completely stop it. It doesn't mean the server is stopped though. Renaming the current stop event for forceshutdown gives more meaning to what it actually does. The stopped namespace then becomes available to indicate a completely stopped server. (Bitbake rev: 12e9d33bfae5294e3870dfd1202f63383ad05e92) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: xmlrpc: delete unused code BitBakeUIEventServerAlexandru DAMIAN2013-09-131-45/+0
| | | | | | | | | | | | | BitBakeUIEventServer is an unused class that pushes UI events over a separate thread. The current version of XMLRPC server works just fine with the classic UI event handlers, so this class is not needed. (Bitbake rev: 8e8e17631d790271b1be747c4b45059ec38ab606) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: stop server on client exitAlexandru DAMIAN2013-09-011-0/+5
| | | | | | | | | | | | If the server only expects a single client to connect (i.e. no bind parameter set, so there is no way for the clients to get the server port), stop the server after the first client exits. (Bitbake rev: eb6bae56f62082bf147045311154cbae4bca0f4c) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process, server/xmlrpc, runqueue: Use select.select() on ↵Richard Purdie2013-09-012-19/+18
| | | | | | | | | | | | | | | | | | | | | | fds, not time.sleep() The existing backend server implementations were inefficient since they were sleeping for the full length of the timeouts rather than being woken when there was data ready for them. It was assumed they would wake and perhaps did when we forked processes directory but that is no longer the case. This updates both the process and xmlrpc backends to wait using select(). This does mean we need to pass the file descriptors to wait on from the internals who know which these file descriptors are but this is a logical improvement. Tests of a pathaolgical load on the process server of ~420 rapid tasks executed on a server with BB_NUMBER_THREAD=48 went from a wall clock measurement of the overall command execution time of 75s to a much more reasonable 24s. (Bitbake rev: 9bee497960889d9baa0a4284d79a384b18a8e826) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: Increase timeout to 60sRichard Purdie2013-08-301-1/+1
| | | | | | | | | | | | This is a better value that the earlier infinite timeout yet still allows for servers with high loads. It does mean the bitbake process can hang at exit for the timeout period but that should never happen and only happened for me in some test cases which wouldn't happen in normal use. (Bitbake rev: ab8d926b9bc27c58011e7db9327e031ac76ba34b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add ui event handlers filteringRichard Purdie2013-08-262-5/+13
| | | | | | | | | | | | | | | | | | | Add functionality to allow UIs to update and change the types of events they recieve. To do this we need to add a new command and also need to be able to obtain the current event hander ID. In the case of xmlrpc, this is straightforward, in the case of the process server we need to save the result in a multiprocessing.Value() so we can retrive it. An excplit command was added to the server API to facilitate this. The same function can also be used to mask or unmask specific log messages, allowing the UI to optionally differ from the standard set of message filtering. Based upon work by Cristiana Voicu <cristiana.voicu@intel.com> (Bitbake rev: ba5a6c88785d9889d4172ec79937ac2a5555327e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc/prserv: Add sane timeout to default xmlrpc serverRichard Purdie2013-08-261-4/+18
| | | | | | | | | | | | | | | | | The standard python socket connect has long timouts which make sense for remote connections but not local things like the PR Service. This adds a timeout parameter to the common xmlrpc server creation function and sets it to a more reasonable 5 seconds. Making the PR server instantly exit is a good way to test the effect of this on bitbake. We can remove the bodged timeout in the PRServer terminate function which has the side effect of affecting global scope. (Bitbake rev: 8c01cff94787abbb64fbdf0c16cd63f8f97a7e03) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Improve exit handling and hangsRichard Purdie2013-08-261-19/+17
| | | | | | | | | | | | | | | | | | | | | | | It turns out we have a number of different ways the process server termination can hang. If we call cancel_join_thread() on the event queue, it means that it can be left containing partial data. This means the reading of the event queue in the terminate() function can hang, the timeout and block parameters to Queue.get() don't make any difference. Equally, if we don't call cancel_join_thread(), the join_thread in terminate() will hang giving a different deadlock. The best solution I could find is to loop over the process is_alive() after requesting it stops, trying to join the thread and if that fails, try and flush the event queue again. It wasn't clear what difference a force option should make in this case, we're gracefully trying to empty queues and shut down regardless of whether its a SIGTERM so I've simply removed the force option. (Bitbake rev: c5c8f33ca4b81877a0115887849881001b745bf0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty, xmlrpc: add observer-only modeAlexandru DAMIAN2013-06-171-8/+18
| | | | | | | | | | | | | | | | | | | | | I add an observer only mode for the knotty UI and the XMLRPC server that will allow the UI to register a callback with a server in order to receive events. The observer-UI is able to send read-only commands to the server, and also is able to register as an event handler. Read-only commands are the commands that do not change the state of the server and have been marked as such in the command module. The observer can switch to a full client if it calls addClient at any time, and the server has no other client running. (Bitbake rev: 4de9ee21f1fa4d04937cc7430fb1fc8b7a8f61e2) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: compat/server/utils: Jettison pre python 2.7.3 workaroundsRichard Purdie2013-06-142-139/+11
| | | | | | | | | Now we've moved to require python 2.7.3, we can jettison the compatibility workarounds/hacks for older python versions. (Bitbake rev: a51c402304f2080a76720f9b31d6dfdbed393bba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-11 23:52:51 +0000