[OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init
wenzong fan
wenzong.fan at windriver.com
Fri Sep 2 01:24:19 UTC 2016
On 08/31/2016 11:11 PM, Joshua Lock wrote:
> On Wed, 2016-08-31 at 17:21 +0800, wenzong fan wrote:
>> Hi Experts,
>>
>> While I trying to build Yocto in Docker Container which using dumb-
>> init
>> as init system, I found the build always be stopped at some point
>> and
>> the container was terminated as well with below errors:
>>
>> Child process timeout after 2 seconds.
>> Child process exit status 4: lock_held
>>
>> Sometimes there's not any obvious error message.
>>
>> After some `git bisect` testing, I believe the issue was started
>> since
>> commit:
>>
>> ----------------------
>> 9df3cdf42d8c1216682f497f0b166a43ef9f4184 is the first bad commit
>> commit 9df3cdf42d8c1216682f497f0b166a43ef9f4184
>> Author: Richard Purdie <richard.purdie at linuxfoundation.org>
>> Date: Tue Jul 5 13:18:31 2016 +0100
>>
>> pseudo: Upgrade to 1.8.1
>>
>> * Drop patches where the changes exist upstream
>> * Fetch from git as no tarball is available for 1.8.1
>> * Move common code to pseudo.inc
>> * Update patchset in git recipe
>>
>> (From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
>> -----------------------
>>
>> Finally I narrowed it down to pseudo commit:
>>
>> ------------------------
>> commit 77ee254a6c974aad9bcab2c58c9ee9e0880c9718
>> Author: Peter Seebach <peter.seebach at windriver.com>
>> Date: Tue Mar 1 16:21:15 2016 -0600
>>
>> Server launch reworking.
>>
>> This is the big overhaul to have the server provide meaningful
>> exit
>> status
>> to clients.
>>
>> In the process, I discovered that the server was running with
>> signals blocked
>> if launched by a client, which is not a good thing, and
>> prevented
>> this from
>> working as intended.
>>
>> Still looking to see why more than one server spawn seems to
>> happen.
>> ------------------------
>>
>> I also created a testcase for reproducing the issue at:
>>
>> https://github.com/WenzongFan/docker-build-yocto
>
> Thanks for providing a detailed reproducer. I'm trying to configure a
> container behind my proxy here.
>
>>
>> For dumb-init please refer to:
>>
>> https://github.com/Yelp/dumb-init
>>
>> Could anyone help to fix the signal handling in pseudo?
>
> It may not actually be pseudo at fault here. I've only skimmed the
> dumb-init README but it looks like there might be a strange interaction
> between the newly fixed signal handling in pseudo and dumb-init's
> signal handling.
>
> Should dumb-init be running in single-child/non-setsid mode so that
> signals are only forwarded to the direct child rather than all child
> processes in the dumb-init session? Is this a scenario you've tested?
Yes, I had try below options, but all of them don't work:
1) Run dumb-init with the -c flag:
https://github.com/Yelp/dumb-init/issues/51 - single-child/non-setsid mode
2) Update dumb-init to latest version v1.1.3 (the release notes mention
fixes for race conditions)
3) Switch to tini which an alterative to dumb-init:
https://github.com/krallin/tini
Thanks
Wenzong
>
> Regards,
>
> Joshua
>
>
More information about the Openembedded-core
mailing list