[OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[Joshua Lock]

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?

Regards,

Joshua