summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/server
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* bitbake: xmlrpc: removes the event servers controllerAlexandru DAMIAN2013-06-141-59/+0
| | | | | | | | | | | | | XMLRPC API ran a XMLRPC server at port+2 in order to provide endpoints to register an event server in which to dump the events. This is no longer used, so we remove it. (Bitbake rev: e171a363913a86e56266f4c9d107110c7f5221e3) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: Allow server to remain memory residentAlexandru DAMIAN2013-06-071-11/+9
| | | | | | | | | | | | | | | | This patch enables the XMLRPC server to remain resident in memory after a task is run, and to accept a new controlling client. To check the server after task completion, do lsof bitbake.lock in the build directory. Kill the server with kill. (Bitbake rev: e823e1f0675ff3794eb39ef0b4df2d7a220f4013) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake server: create common server infrastructureAlexandru DAMIAN2013-06-073-72/+141
| | | | | | | | | | | | | | | | | | | In an attempt to minimize code duplication, create clear interfaces, and maximize code reuse through OOP, bb.server adds base classes for the BitBakeServer, BitBakeServerConnection and actual server implementations instructed in particular server types. These classes document the minimum interfaces that the derived classes must implement, and provide boilerplate code. Changes to None, Process and XMLRPC servers as to use the common server infrastructure. (Bitbake rev: 6db4a64cef20f8d0aba804db4c4e1eec7b112b46) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: xmlrpc remote serverAlexandru DAMIAN2013-05-301-6/+200
| | | | | | | | | | | | | | | | Added code in XMLRPC server that creates a stub local server for a client-only connection and is able to connect to a remote server, and receive events from the remote server. Added the option to start a client with a remote server in bitbake. Original code by Bogdan Marinescu <bogdan.a.marinescu@intel.com> (Bitbake rev: 25b2af76104d5aaf6435de8c158e0407512f97ce) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: xmlrpc transport has identification tokenAlexandru DAMIAN2013-05-301-66/+100
| | | | | | | | | | | | | | | In order to be able to identify different clients over a stateless XMLRPC connection, we add a custom header named Bitbake-token, which identifies each client. We refactor the rest of the code to use the new transport. Based on a patch by Bogdan Marinescu <bogdan.a.marinescu@intel.com> (Bitbake rev: a00c2186bffe848a7cedf31969b904f8f7322ae6) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/bitbake: Remove launchUI methodRichard Purdie2013-05-302-9/+0
| | | | | | | | | With the removal of the none server type, we can remove the launchUI method and simplify the code slightly. (Bitbake rev: 9bef2f2dd0bcaa59528ebcb3c1ce053b7dff1ec6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server: Remove none serverRichard Purdie2013-05-301-203/+0
| | | | | | | | | | | | The process server backend has been serving well as the default for a long time now and the UI model is much better thought out that it used to be. With the move to make bitbake a memory resident process, the none server is now looking rather pointless and complicates the code needlessly. Lets therefore now remove it. (Bitbake rev: 9af03a89605e3db9bce3cea1e0f2d0b6cfaa6fe1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: print is a function in moderm python, covert remaining usersRichard Purdie2013-05-091-1/+1
| | | | | | (Bitbake rev: d0b180d868390a464b6799ad90db6bbe0350e158) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Always use separate process for PR ServiceRichard Purdie2013-02-061-1/+1
| | | | | | | | | | | | | | | Using the threading module interacts badly with multiprocessing used elsewhere in bitbake under certain machine loads. This was leading to bitbake hanging on Ctrl+C when the PR Server was being used. This patch converts it to always use the daemonize code which then means the threading code isn't required. [YOCTO #3742] (Bitbake rev: 2d0bbd9398ab839bd2d1e29e50b25d52efb1ce2a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: Unbreak the transport by adding a missing logfile nameRichard Purdie2012-12-041-1/+1
| | | | | | | | | I appreciate a fixed value is suboptimal but this is better than not working at all! (Bitbake rev: d338a1ad14680af41d218772decd03e98eb2cad5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process.py: Change timeout error handlingRichard Purdie2012-11-211-2/+2
| | | | | | | | | | | | | | | | | | | In normal usage, we never hit the timeout issue. If we do, it becomes obvious that the current error handling is not good enough. The request may have made it to the server and the answer will get queued. This means the next command may get the return value from the previous command with suitably puzzling results. Without rewriting large sections of code, its not possible to avoid this problem. It is better to increase the timeout to several seconds giving the server a chance to respond and if it does timeout, hard exit since recovery is not possible with the code base today. I'd be happy to see the structure of this code improved but this quick fix at least stops corrupted builds from happening which has to be a good thing. (Bitbake rev: 410c11dd10736873f2dc587fbe9119c38831e693) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: add error to return of runCommandChristopher Larson2012-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, command.py can return an error message from runCommand, due to being unable to run the command, yet few of our UIs (just hob) can handle it today. This can result in seeing a TypeError with traceback in certain rare circumstances. To resolve this, we need a clean way to get errors back from runCommand, without having to isinstance() the return value. This implements such a thing by making runCommand also return an error (or None if no error occurred). As runCommand now has a method of returning errors, we can also alter the getCmdLineAction bits such that the returned value is just the action, not an additional message. If a sync command wants to return an error, it raises CommandError(message), and the message will be passed to the caller appropriately. Example Usage: result, error = server.runCommand(...) if error: log.error('Unable to run command: %s' % error) return 1 (Bitbake rev: 717831b8315cb3904d9b590e633000bc897e8fb6) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-13 19:39:24 +0000