summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/runqueue.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: Convert to python 3 megacommit This needs breaking up into ↵Richard Purdie2016-05-161-61/+56
| | | | | | | | smaller changes. (Bitbake rev: cf51f19aed208a75d38c14cd585d9b9f115e3ba3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: always emit bb.event.DepTreeGeneratedPatrick Ohly2016-05-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The data included in the event is useful for implementing a pre-build check that warns about unexpected components, for example because of an incorrect configuration or changed dependencies. Such a check can be done in a .bbclass that gets inherited globally. But in contrast to a UI, such a class cannot request that the event shall be emitted, and thus the event has to be emitted whether there is a consumer or not. This was done conditionally earlier out of concerns about the performance impact. But now events are handled more efficiently, so that concern no longer seems valid: in some simple testing (admittedly on a fast build workstation), the two lines (generating the data and emitting the event with it) only took about 0.05 seconds (measured with timeit). That was for a build with roughly 500 recipes (from pn-buildlist aka depgraph['pn']), triggered via the command line. That was even with a consumer of the data active and doing some work, so it should be even faster when there is no consumer. (Bitbake rev: 5ddaf5b7ed1001d2dd3f67e7a6d704afa85479d2) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve timestamp comparisonsRichard Purdie2016-05-131-1/+5
| | | | | | | | | | python3 cares more about invalid type comparisons. Add break statements and better tests to make the code paths clearer and avoid type issues in python3. No code functionality change. (Bitbake rev: 2c39ebdd2762d027f007a6a769fdf023cdf3da2b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix missing fakeworker under dry runRichard Purdie2016-05-111-1/+1
| | | | | | | | | We shouldn't try and use fakeworker when performing a dry_run. This makes the core match the other fakeworker execution points. (Bitbake rev: 49bea821a2edad5e19c3a566d1a80c23718dede9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update logger.warn() -> logger.warning()Richard Purdie2016-05-111-2/+2
| | | | | | | | | | python deprecated logger.warn() in favour of logger.warning(). This is only used in bitbake code so we may as well just translate everything to avoid warnings under python 3. Its safe for python 2.7. (Bitbake rev: 676a5f592e8507e81b8f748d58acfea7572f8796) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve 'mulitiple .bb files are due to be built' messageRichard Purdie2016-04-121-2/+70
| | | | | | | | | | | | | | | | | | | | | | | | | When multiple recipes which both provide something are being built, bitbake informs us that most likely one of them provides something the other doesn't, which is usually correct, but unfortunately it's rather painful to figure out exactly what that is. This patch dumps two sets of information, one is the provides information for each recipe, filtered so only common components are removed. The other is a list of dependees on the recipe, since sometimes this can easily identify why something is being built. Its not straightforward for bitbake to obtain the information but since the warning/error code path isn't the normal one, we can afford to go through some less than optimal processing to aid debugging. Also provide the same information even if we're showing a warning since its still useful. [YOCTO #8032] (Bitbake rev: 96fc889b8e62ba4463c71158c4b7286c48d68cd8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb/runqueue: save task file dependency cache onto diskMarkus Lehtonen2016-02-181-0/+1
| | | | | | | | | | | | Before this patch the usage of cache was quite useless as the file checksums were not actually cached on disk but re-calculated every time. This patch utilises the new writeout_file_checksum_cache() method of the SignatureGenerator class to do the job. (Bitbake rev: 5ac9cbf405841ed3f65e6f99a3cee032567fb182) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Set process names to be meaninfulRichard Purdie2016-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Revert "runqueue.py: Ensure one setscene function doesn't mask out ↵Richard Purdie2016-01-191-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | another which needs to run" This reverts commit b22592af8145a8c7c4ada2fa7c1dee2e753eca46. That commit isn't entirely clear about why this change is needed but I do have a usecase where this breaks things. If for example you run "bitbake X -c packagedata" and that packagedata is in sstate, you'd expect this to work. If sstate doesn't contain a do_populate_sysroot for a dependency, you would still expect the command above to succeed and you would not expect it to rebuild that dependency. With the current code, this isn't what happens. The code finds the sstate for do_populate_sysroot missing, this makes the task "uncovered" and this in turn makes it unskippable. The example I found with this was avahi-ui, where it would trigger a build of libdaemon to obtain its populate_sysroot. Since this behaviour seems completely incorrect, revert the older patch and we'll address any issues that crop up as a result. (Bitbake rev: 36a9840a5da17cc14561881fdd6a4f2cb0a75e49) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix setscene task dependenciesRichard Purdie2016-01-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Debugging suggests that setscene tasks are being a little greedy about their dependencies, for example, lsof is insisting that gcc-runtime's do_package is installed. If it isn't, its requiring gcc to rebuild. If gcc-runtime do_package_write_xxx and do_packagedata is available, there is no reason do_package should be needed. The reason this is happening appears to be from the batching up of task dependencies code, rather than setscene tasks stopping when passing over a setscene task, they were being carried forward. This patch fixes it so the data is 'zeroed' when passing over a setscene task boundary, which gives the dependency graph that is expected. After this patch, lsof will rebuild quite happily without gcc-runtime:do_package being present, as expected. This should lead to less dependencies being installed for builds from sstate and generally better performance in general. (Bitbake rev: f8bcb0a1e3b008b71c9a7cd21f76d0906f2d8068) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskdata: refactor get_providermapEd Bartosh2016-01-111-1/+1
| | | | | | | | | | | | | | | Added optional parameter 'prefix' to filter out names that don't start with specified prefix. Changed existing call of get_providermap according to changed API. Optimized the code: got rid of extra loop and temporary list variable virts. (Bitbake rev: df5a1392d6f91ccb44a99721c7d847da242121bb) 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: main/runqueue: Add --setscene-only option to bitbakeRichard Purdie2016-01-111-3/+6
| | | | | | | | | | | | | Its turning out that we really need a way to have bitbake just run the setscene tasks but not any real tasks, particularly for SDK operations. Add an option for this since its pretty straight forward. This allows various nasty workarounds in OE-Core to be removed. (Bitbake rev: e4a2aafa1650a227a04d92a8a0b31efaed2c310e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add support for <task>- syntaxRichard Purdie2015-12-181-8/+18
| | | | | | | | | | | It can be useful to run all tasks up to but not including a specific task. The main reason this was never added was the lack of a good syntax. This patch uses the syntax <taskname>- to denote this behaviour which is simple, not invasive and fits what we need from good syntax IMO, hence we can add this. (Bitbake rev: 99ccfd411ab3f7baa111f9f3d50fae68816a9a83) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add handling of virtual/xxx provider mappingsRichard Purdie2015-10-011-0/+9
| | | | | | | | | | | | This firstly prints debug messages which show how bitbake decided to resolve the virtual/xxx providers which is useful for debugging. If the siggen has a tasks_resolved() method, it calls this, passing in the mappings, allowing that to do things with the resolved names. (Bitbake rev: d473fc84acddfd69a7207affcd89f65ea2ecf730) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/runqueue: Allow bitbake commands starting with do_Alex Franco2015-09-041-1/+3
| | | | | | | | | | | | | | | The output of "bitbake, -c listtasks pkg" lists tasks with their real names (starting with "do_"), but then "bitbake -c do_task" fails, as "do_" always gets unconditionally prepended to task names. This patch handles this error by checking whether a task starts with "do_" prior to prepending it with it when the task runlist is being constructed (and a few other corner cases). [YOCTO #7818] (Bitbake rev: dd3050ceef37ac556546e940aa596ce96ef6c8df) Signed-off-by: Alex Franco <alejandro.franco@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Add provides to taskdepdataMariano Lopez2015-08-101-1/+2
| | | | | | | | | | | | | | | Currently bitbake is the only one that knows the relation between PN and PROVIDES. In some cases it is needed to have this relation in the data store (the bootloader it's a good case). This adds the PROVIDES to the taskdata, so it would be in the data store as one field of BB_TASKDEPDATA. (Bitbake rev: a660787311d2961c66c0443bf0e2e094c9baef1b) Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Sanity check BB_NUMBER_THREADSRichard Purdie2015-06-231-0/+3
| | | | | | | | | | | | Bitbake does really weird things with negative or zero numbers of threads which is confusing to the user. Add a sanity check for this. When you have code doing arithmetic on the values and a VM reconfigures to only a single thread, negative numbers are easier than you'd think. (Bitbake rev: 32166ac3c85ff3c04081580ae76bd63590d6ff3e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Handle BBHandledException correctlyRichard Purdie2015-06-231-0/+7
| | | | | | | | | | | | If we see a BBHandledException in runqueue, 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: 29d28e22ce431c3d3aabdb88ff4d8cca67a1cfad) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve handling of fakeworker failing to startRichard Purdie2015-06-231-1/+6
| | | | | | | | | | | Currently if the fakeworker failes to start the output from bitbake is confusing. Improve the error handling to give a clear indication of what failed. Patch from Chris Larson. (Bitbake rev: ad286d6fed7a580bec36a92c7b7e205322ac407b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Handle cases where siginfo is now a parameter to the ↵Richard Purdie2015-05-151-2/+7
| | | | | | | | | | | | | | hashvadlidate function In some cases we need to check specifically for siginfo files, in some cases we need to check for the actual sstate objects themselves. Therefore make this a parameter to the function. A fallback to the previous function style is maintained for now. (Bitbake rev: 18d3a03e1b07c98b2dce46eb94f30de1a2b4320b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: pass finalized metadata to scenequeue callbacksChristopher Larson2015-04-081-4/+4
| | | | | | | | | | | | This ensures that _append, _prepend, overrides, etc are functional when used on sstate variables (e.g. SSTATE_DIR). [YOCTO #7564] (Bitbake rev: 2e683c25b856b431198573f7f352d841587275e6) Signed-off-by: Christopher Larson <kergoth@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix 100% cpu use after keyboard interruptRichard Purdie2014-12-091-5/+4
| | | | | | | | | | After Ctrl+C is pressed to interrupt bitbake, it loops continually, running at 100% cpu. This patch selects on the correct file descriptors resolving the excess cpu usage. (Bitbake rev: 497404e8484b7ca7c11e459bf0845642156eb677) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Make printed 'runqueue' be consistently capitalizedGary Thomas2014-11-061-1/+1
| | | | | | | | | | | | | This has always bothered me: NOTE: Preparing runqueue NOTE: Executing RunQueue Tasks This patch changes the messages to be consistent. (Bitbake rev: 72ac9f9227fbfb4dc8b933b357d21aa0e4060959) Signed-off-by: Gary Thomas <gary@mlbassoc.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen/runqueue/bitbake-worker: Improve siggen data transfer interfaceRichard Purdie2014-09-111-3/+1
| | | | | | | | | | | | | We need to transfer some of the siggen data from the core/cooker into the worker instances. There was a partial API created for this but its ugly and its not possible to extend it from the siggen class. This patch completes the interface/abstraction for the data and means the class can extend/customise it in any siggen class. (Bitbake rev: cf2d642052979d236185c5b8ca2c5478c06e62ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-worker: Extra profiling data dumpRichard Purdie2014-08-281-2/+5
| | | | | | | | | | | | | | Currently we get no profiling oversight into either the main bitbake worker process, or the overall parsing before task execution. This adds in extra profiling hooks so we can truly capture all parts of bitbake's execution into the profile data. To do this we modify the 'magic' value passed to bitbake-worker to trigger the profiling, before the configuration data is sent over to the worker. (Bitbake rev: 446e490bf485b712e5cee733dab5805254cdcad0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix setscene tasks not runningRichard Purdie2014-08-281-0/+4
| | | | | | | | | | | | | | | | | | | | Currently, if you have hard dependencies between setscene tasks (like avahi on base-passwd through useradd.bbclass), other dependencies may not be installed even if these exist in sstate. For example, avahi -> expat -> pigz-native (and avahi -> base-passwd) yet if you cleansstate base-passwd: bitbake gzip-native:do_clean avahi:do_clean expat:do_clean pigz-native:do_clean base-passwd:do_cleansstate bitbake avahi | tee you will currently see pigz-native being rebuilt even though it was in sstate. The fix for this is to continue to iterate dependency chains around hard blocked dependencies as per this patch. After this patch is applied, you will see pigz-native installed from sstate. (Bitbake rev: f787957a224e8c2682a19e5c4a4d9c86bdce52ba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Fix typoes/grammar in comments.Robert P. J. Day2014-08-191-6/+6
| | | | | | | (Bitbake rev: 000fa81013205dd9bc907ff7a61f06f57637212d) Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Correct several misspellings of "notifing".Robert P. J. Day2014-08-191-7/+7
| | | | | | | (Bitbake rev: 4e9aef14d747c37444a4fc683f9641906906afe9) Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add sceneQueueComplete eventRichard Purdie2014-08-031-0/+12
| | | | | | | | | | Its useful to have an event emitted when all of the sceneQueue tasks have completed since the metadata can hook this for processing. Therefore add such an event. (Bitbake rev: 38d4f65bf1cbcdd5a2d60dff0e1d2859c34ed62e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command/runqueue: Fix shutdown logicRichard Purdie2014-07-211-1/+2
| | | | | | | | | | | | | | If you hit Ctrl+C at the right point, the system processes the request but merrily continues building. It turns out finish_runqueue() is called but this doesn't stop the later generation and execution of the runqueue. This patch adjusts some of the conditionals to ensure the build really does stop. (Bitbake rev: 39b08c604ba713100e174c136f81f18eca6ef33d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Do not write out stamp files in dry_run modeRichard Purdie2014-04-231-1/+2
| | | | | | | | | In dry run mode, stamps for noexec tasks are being written out which is incorrect. Avoid this. (Bitbake rev: aa6448a0552ba2947ac262b8b5314a593d1058d3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix task weighting algorithmRichard Purdie2014-04-231-2/+2
| | | | | | | | | | | | | | | When looking at a list of tasks, do_patch and do_unpack were being given equal priority when one clearly depends on another. The reason for this was the default task weights of 0 being to tasks. This is therefore changed to 1 to allow correct weighting of dependencies which means the scheduler has better information available to it about tasks. Weight endpoints differently (10) for clearer debugging of priorities. (Bitbake rev: 12dc1d17fac3e8ec420fcafb06186d32fd847d89) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix handling of zero priority taskRichard Purdie2014-04-231-1/+1
| | | | | | | | | | | | | The zero priority task should be run first but was being confused with the None value the priority field defaulted to. Check for None explicitly to avoid this error. In the real world this doesn't change much but it confused the debug output from the schedulers. (Bitbake rev: 49c9d8c9400f74c804c2f36462639236e0841ff0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Address issues with incomplete sstate setsRichard Purdie2014-04-011-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first part of the sstate code checks en-mass whether given checksums are available. The next part of the code then either triggers those setscene tasks either running them or skipping them if they've been covered by others. The problems was that this second part would always skip a task if it was unavailable in the first part, even if it would have otherwise been covered by other tasks. This mean the mere presence of an artefact (or lack of presence) could cause a different build failure. The issue reproduces if you run a build and populate an sstate feed, then run a second build off that feed, then run a third build off the sstate feed of the second build (which is reduced in size). The fix is rather than immediately skipping tasks if the checksum is unavailable, create a list of missing tasks, then, if that task cannot be covered by others we can skip it later. The deferral makes the behaviour the same even when the cache is "incomplete". [YOCTO #6081] (Bitbake rev: 5edb1a3e3f454ba6e65551174d86229db2f99636) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix sstate task dependency problemsRichard Purdie2014-04-011-0/+4
| | | | | | | | | | | | | If a setscene task has [depends], its possible they may still get executed out of order. The issue is that the dependencies are set to set() for all tasks involved. This patch adds back in explict dependencies within these chains to avoid the setscene task failures. [YOCTO #6069] (Bitbake rev: 724c889eed3b03d3199810c185086d3973af826c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue/siggen: Pass in commandline options to dump_sigs()Richard Purdie2014-03-271-3/+3
| | | | | | | | | This allows the commandline options to be processed in the dump signature code. (Bitbake rev: ef8537a2e9b48f4fe065a165c102935aee2c9029) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Force -S option to take a parameterRichard Purdie2014-03-271-3/+6
| | | | | | | | | | | | | There is no easy way to make this change. We really need parameters for the -S (dump signatures) handling code. Such a parameter can then be used within the codebase to handle the signatures in different ways. For now, "none" is the recommended default and "printdiff" will execute the new (and more expensive) comparison algorithms. (Bitbake rev: b9873588696507dfb6aade6821f6f75cb9a19e0a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix sceneQueueEvent to use the correct hashesRichard Purdie2014-03-251-1/+1
| | | | | | | | | | The runqueue should be using the "realtask" ID to lookup the task hash, not the "task" ID. This patch resolves corruption issues where incorrect task hashes were displayed within toaster. (Bitbake rev: 84be1a27f89d1bf63c21f06d831df0a66a5db860) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Remove use of waitpid on worker processesRichard Purdie2014-03-191-16/+12
| | | | | | | | | | | | | Use of waitpid on the worker processes is a bad idea since it conflicts directly with subprocess internals. Instead use the poll() method and returncode to determine if the process has exitted, if it has, we can shut down the system. This should resolve the hangs once and for all, famous last words. (Bitbake rev: 60969cd62e21e7d4af161bf8504b7643a879c73f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Revert child signal handler for nowRichard Purdie2014-03-191-28/+17
| | | | | | | | | | | | | | | | | | | | | | | | | We're running into processes using 100% cpu. It appears theses are locked in a subprocess.poll() type loop where the process has exited but the code is looping as its not handling the ECHILD error. http://bugs.python.org/issue14396 http://bugs.python.org/issue15756 This is likely due to one or both of the above bugs. The question is what actually grabbed the child exit code as it wasn't this code. Its likely there is therefore some other code racing and taking that code, it may be some kind of race like: http://hg.python.org/cpython/rev/767420808a62/ where the fix effectively catches the childs codes in a different part of the system. We could try and get everyone onto python 2.7.4 where the above bugs are fixed however for now its safer to admit defeat and go back to polling explictly for our worker exit codes. (Bitbake rev: 5b9a099ec2a1dc954b614e12a306595f55b6a99e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Don't catch all child return codesRichard Purdie2014-03-191-3/+4
| | | | | | | | | | Catching all child exit status values is a bad idea. Setting an http sstate mirror is a great way to view that spectacularly break things. The previous change did have good code changes so don't revert those parts. (Bitbake rev: fa7ffb62d510ac1124ae7e08fa4d190a710f5b54) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Really fix sigchld handlingRichard Purdie2014-03-181-14/+14
| | | | | | | | | | | | | | | | | | | There are several problems. Firstly, a return value of "None" can mean there is a C signal handler installed so we need to better handle that case. signal.SIG_DFL is 0 which equates to false so we also need to handle that by testing explicitly for None. Finally, the signal handler *must* call waitpid on all child processes else it will just get called repeatedly, leading to the hanging behaviour we've been seeing. The solution is to only error for the worker children, we warn about any other stray children which we'll have to figure out the sources of in due course. Hopefully this patch gets things working again properly though. (Bitbake rev: 973876c706f08735c1b68c791a5a137e5f083dd2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure handler does not recurseRichard Purdie2014-03-181-1/+1
| | | | | | | | | Failures on the autobuilder look like this handler is recursing. That shouldn't be possible but it doesn't hurt to code as such. (Bitbake rev: e39e85803cbe1ef9413a118868c19087c0546d01) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: More carefully handle the sigchld handlerRichard Purdie2014-03-181-2/+4
| | | | | | | | | | | | We've noticed hanging processes which appear to be looping around waitpid. Its possible multiple calls to teardown are causing problem or in theory multiple registrations (although the code should not allow that). Regardless, put better guards around signal handler registration. (Bitbake rev: 79acfb0853aa3215215cee89a945f8e97b0a8fae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Don't error if we never setup workersRichard Purdie2014-03-171-1/+2
| | | | | | | | | | If we didn't setup any workers (such as bitbake -S), this would error since we're trying to set a signal handler to None. This patch avoids that problem. (Bitbake rev: ce17478c8197abf178c00774f5bbe23fd4375ee2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve sigchld handlerRichard Purdie2014-03-121-5/+10
| | | | | | | | | | | | | | | | | | | The sigchld handler was reaping any processes and this was leading to confusion with any other process handling code that could be active. This patch: a) Ensures we only read any process results for the worker processes we want to monitor b) Ensures we pass the event to any other sigchld handler if it isn't an event we're interested in so the functions are properly chained. Together this should resolve some of the reports of unknown processes people have been reporting. (Bitbake rev: fe8baaa2f533db7a1b7203476c675588923d8d45) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Use SIGCHLD instead of polling waitpidRichard Purdie2014-03-101-14/+19
| | | | | | | | | Instead of a significant number of calls to waitpid, register a SIGCHLD handler instead. (Bitbake rev: 76029d08ad56a0a264ff9738a0336971a455b7f5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: providers/runqueue/taskdata: Optimise logger.debug callsRichard Purdie2014-03-101-1/+1
| | | | | | | | | | | | | A run of "bitbake bash -c unpack" when the task has already been completed resulted in about 9000 calls to logger.debug(). With this patch which comments out some noisy/less usefull logging and moves other logging calls outside loops, this number is reduced to 1000 calls. This results in cleaner logs and gives a small but measurable 0.15s speedup. The log size dropped from 900kb to 160kb. (Bitbake rev: d2677f084fe1d8846db77d89ef5e6ffb18dc171a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Gracefully handle a missing worker processRichard Purdie2014-03-101-7/+14
| | | | | | | | | | If the worker has already gone missing (e.g. SIGTERM), we should gracefully handle the write failures at exit time rather than throwing ugly tracebacks. (Bitbake rev: 1b1672e1ceff17fc4ff8eb7aa46f59fce3593873) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Handle worker disappearing gracefullyRichard Purdie2014-03-101-5/+22
| | | | | | | | | | | If the worker (or fakeworker) process disappears for some reason, the system doesn't currently even notice. To fix this, we call waitpid periodically, looking for exit events of our children. If these occur, we can gracefully shutdown the server. (Bitbake rev: ee28ddadaa7ef91e4d4b7d22fc267382aaad6d01) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-20 06:44:42 +0000