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.pur...@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.seeb...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
