summaryrefslogtreecommitdiffstats
path: root/bin/bitbake-worker
AgeCommit message (Collapse)Author
2016-01-31cooker, bitbake-worker: Fix spelling of "received"Phil Blundell
I before E, except after C... Signed-off-by: Phil Blundell <pb@pbcl.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-29bitbake: Set process names to be meaninfulRichard Purdie
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-29bitbake-worker: Guard against multiprocessing corruption of event dataRichard Purdie
In the forked child, we may use multiprocessing. There is only one event pipe to the worker controlling process and if we're unlucky, multiple processes can write to it at once corrupting the data by intermixing it. We don't see this often but when we do, its quite puzzling. I suspect it only happens in tasks which use multiprocessng (do_rootfs, do_package) and is much more likely to happen when we have long messages, usually many times PAGE_SIZE since PAGE_SIZE writes are atomic. This makes it much more likely within do_roofs, when for example a subprocess lists the contents of a rootfs. To fix this, we give each child a Lock() object and use this to serialise writes to the controlling worker. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-09bitbake-worker: Ensure pipe closure doesn't crash before killpg()Richard Purdie
If the pipe is closed, we want to ensure that we kill any child processes by triggering the sigterm handler before we exit. This code does that, hopefully avoiding the remaining process left behind issues on the autobuilder. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-09bitbake-worker: Handle SIGKILL of parent gracefullyRichard Purdie
If we SIGKILL cooker (the parent process), ensure the worker notices and shuts down gracefully. To do this: * trigger the sigterm handler if the parent exits * ensure broken pipe writes don't trigger backtraces which interfer with other exit work * notice if our command pipe is broken due to EOF and sigterm if so Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-09bitbake-worker: Simple code cleanupRichard Purdie
start/end are unused here and we can improve the code conditional blocks. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-24bitbake-worker: Fix regression with unbuffered logsJason Wessel
I noticed that I was seeing loss of the log files when hitting control-c while debugging a function in bitbake. In fact if you take a recipe and replace its compile function as shown below let it run for a few seconds and hit control-c, you will see first hand that log data is not there. do_compile () { while [ 1 ] ; do echo -n "Output date: " date sleep 1 done } It turns out there was a regression introduced by commit: d0f0e5d9e69 which created the bitbake worker. Since the bitbake worker is started in its own process space, it needs the exact same code added from commit: 88429f018b where the problem was fixed the first time around. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-08bitbake-worker: Use setsid() rather than setpgid()Richard Purdie
The bug has a long discussion of this. Basically, in some environments, the exact details of which aren't understood, a Ctrl+C signal to the UI is being transmitted to all the process children. Looking at the output of "ps ax -O tpgid", its clear the main process is still the terminal owner of these processes. stty -a on a problematic system shows: "-ignbrk brkint" and on a working system shows: "-ignbrk -brkint" The description of brkint would suggest this is the problem, setting up that terminal environment wasn't able to reproduce the problem though. It was confirmed that using setsid() caused the problem to be resolved and is probably the right thing to be doing anyway, so lets do it. [YOCTO #6949] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-20bitbake-worker: exit normally when SIGHUPRobert Yang
Fixed: 1) Run "bitbake recipe" in the terminal 2) Close the terminal while building 3) $ ps aux | grep bitbake-worker There will be many processes, and they will keep the resources (e.g., memory), and won't exit unless kill or kill -9. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-22bitbake-worker: Fix bitbake -nRichard Purdie
Without this you see: File "bitbake/bin/bitbake-worker", line 201, in fork_off_task os._exit(child()) TypeError: an integer is required Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-11siggen/runqueue/bitbake-worker: Improve siggen data transfer interfaceRichard Purdie
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-27bitbake-worker: Extra profiling data dumpRichard Purdie
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-22bitbake-worker: Improve sigterm handlerRichard Purdie
When processes terminate, we really want all of the child processes to terminate too. This was not happening for worker processes which spawned their own multiprocessing pools, leading to build hangs. This change ensures any sigterm gets passed to the whole process group. In local tests, this resolved some hanging process workloads I could generate. It does rely on signals being delivered in a timely fashion and there is a multiprocessing bug we have to work around there. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21bitbake-worker: Drop BBHASH variablesRichard Purdie
Iterating through and calling setVar on this number of variables has significant overhead in the profiling data. By not setting this, we save 3,000 calls to setVar which gives a noticeable improvement to the speed of task execution. The BBHASH variables have since been replaced by accessing that data through the siggen code and going forward, that is the preferred way work with it. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-11bitbake-worker: Ensure children have default sigterm handlerRichard Purdie
The children of the worker should have the default SIGTERM handler, else they'll try and do cleanup which should only happen in the parent leading to all kinds of bizarre build failures. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-09bitbake-worker: Gracefully handle SIGTERMRichard Purdie
Currently if bitbake-worker handles a SIGTERM, it leaves the child processes to complete or hang. It shouldn't do this so hook the SIGTERM event and gracefully shutdown any children. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-26bitbake: Share BB_TASKDEPDATA with tasksRichard Purdie
Currently tasks have no knowledge of which other tasks they depend upon. This makes it impossible to do at least two things which would be desirable/interesting: a) Have the ability to create per recipe sysroots b) Allow the aclocal files to be present only for the entries in DEPENDS (directly and indirectly) By exporting task data through this new variable, tasks can inspect their dependencies and then take actions based upon this. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-22runqueue/bitbake-worker: Fix dry run fakeroot issuesRichard Purdie
When using the dry run option (-n), bitbake would still try and fire a specific fakeroot worker. This is doomed to failure since it might well not have been built. Add in some checks to prevent the failures. [YOCTO #5367] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-06bitbake: Ensure ${DATE} and ${TIME} are consistentPeter Kjellerstedt
Due to the worker split the ${DATE} and ${TIME} variables could end up with different values for different workers. E.g., a task like do_rootfs that is run within a fakeroot environment had a slightly different view of the time than another task that was not fakerooted which made it impossible to correctly refer to the image generated by do_rootfs from the other task. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-04bitbake-worker: ensure BUILDNAME is available during executionPaul Eggleton
BUILDNAME is set from cooker by default, so since the worker split it will not be set when executing functions. In OpenEmbedded this results in /etc/version (which is populated from BUILDNAME) not having any content. Pass this variable value through to the worker explicitly to fix the issue. Fixes [YOCTO #4818]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-07-31bitbake-worker: import needed signal moduleValentin Popa
bitbake-worker makes use of the signal module but it doesn't import it. This patch fixes the issue. [YOCTO #4750] Signed-off-by: Valentin Popa <valentin.popa@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-06-12prserv: Adapt autostart to bitbake-workerRichard Purdie
With the change to bitbake-worker we need to ensure the workers know how to contact the PR service, the magic 0 port and singleton is no longer enough. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-06-12runqueue: Split runqueue to use bitbake-workerRichard Purdie
This is a pretty fundamental change to the way bitbake operates. It splits out the task execution part of runqueue into a completely separately exec'd process called bitbake-worker. This means that the separate process has to build its own datastore and that configuration needs to be passed from the cooker over to the bitbake worker process. Known issues: * Hob is broken with this patch since it writes to the configuration and that configuration isn't preserved in bitbake-worker. * We create a worker for setscene, then a new worker for the main task execution. This is wasteful but shouldn't be hard to fix. * We probably send too much data over to bitbake-worker, need to see if we can streamline it. These are issues which will be followed up in subsequent patches. This patch sets the groundwork for the removal of the double bitbake execution for psuedo which will be in a follow on patch. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>