All of lore.kernel.org
 help / color / mirror / Atom feed
From: wenzong fan <wenzong.fan@windriver.com>
To: Joshua Lock <joshua.g.lock@linux.intel.com>,
	"'Patches and discussions about the oe-core layer'"
	<openembedded-core@lists.openembedded.org>, <seebs@seebs.net>,
	Richard Purdie <richard.purdie@linuxfoundation.org>
Subject: Re: pseudo 1.8.1 doesn't work with docker & dumb-init
Date: Fri, 2 Sep 2016 09:24:19 +0800	[thread overview]
Message-ID: <73742f7e-c691-0655-16b4-c60344272755@windriver.com> (raw)
In-Reply-To: <1472656299.2904.4.camel@linux.intel.com>

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@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@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
>
>


  reply	other threads:[~2016-09-02  1:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31  9:21 pseudo 1.8.1 doesn't work with docker & dumb-init wenzong fan
2016-08-31 15:11 ` Joshua Lock
2016-09-02  1:24   ` wenzong fan [this message]
2016-08-31 15:48 ` Seebs
2016-09-02  1:33   ` wenzong fan
2016-09-02  2:10     ` Seebs
2016-09-07  6:32       ` wenzong fan
2016-09-07  6:40         ` Seebs
2016-09-14 20:46           ` Bystricky, Juro
2016-09-15  2:24             ` Randy MacLeod
2016-09-15 19:08               ` Randy MacLeod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73742f7e-c691-0655-16b4-c60344272755@windriver.com \
    --to=wenzong.fan@windriver.com \
    --cc=joshua.g.lock@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=seebs@seebs.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.