linux/poky.git/bitbake/bin/bitbake-worker, branch krogoth-15.0.2

bitbake: cooker, bitbake-worker: Fix spelling of "received"

2016-02-01T11:20:42+00:00

I before E, except after C... (Bitbake rev: 14c9593265f7469cb8a205a46f845ac7491246df) Signed-off-by: Phil Blundell Signed-off-by: Richard Purdie

bitbake: bitbake: Set process names to be meaninful

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

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

bitbake: bitbake-worker: Guard against multiprocessing corruption of event data

2015-10-01T06:43:38+00:00

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. (Bitbake rev: 3cb55bdf06148943960e438291f9a562857340a3) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Ensure pipe closure doesn't crash before killpg()

2015-09-12T21:50:14+00:00

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. (Bitbake rev: 60f6c2818f38c4d9c2d9aaa42acf3071636f4a3b) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Handle SIGKILL of parent gracefully

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

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 (Bitbake rev: c43d6a8d711db8d3bd9a1976b9f8e3efdb4cb4ae) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Simple code cleanup

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

start/end are unused here and we can improve the code conditional blocks. (Bitbake rev: 68f53dd77fe0bbfa044bd037a9484e0e1c9088b4) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Fix regression with unbuffered logs

2015-05-26T09:33:06+00:00

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. (Bitbake rev: 8d1748f75763b4a66516cc46d5457ee6404b1b68) Signed-off-by: Jason Wessel Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Use setsid() rather than setpgid()

2015-01-08T09:46:58+00:00

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] (Bitbake rev: 461aa73fff0ab616032d28c4fd0322eb88838be6) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: exit normally when SIGHUP

2014-11-20T14:15:32+00:00

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. (Bitbake rev: 40d2ae0723de2bf5fee343faafb4afda40546839) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Fix bitbake -n

2014-09-22T14:54:40+00:00

Without this you see: File "bitbake/bin/bitbake-worker", line 201, in fork_off_task os._exit(child()) TypeError: an integer is required (Bitbake rev: cd477b5e77ab0373248b8a8fa30e1c7b8ea984fd) Signed-off-by: Richard Purdie