Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

(aws-lambda-python) docker build is not working

See original GitHub issue

Maybe the problem is [aws-lambda-nodejs] docker build is not working · Issue #10881 · aws/aws-cdk Python version.

Reproduction Steps

new PythonFunction(this, "handler");

cdk deploy FooStack

What did you expect to happen?

docker: Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "bash": executable file not found in $PATH: unknown.

What actually happened?

deploy is successed.

Environment

CDK CLI Version : 1.85.0 (build 5f44668)
Framework Version:
Node.js Version: v15.5.1
OS : Linux strawberry 5.4.80-gentoo-r1 #3 SMP Thu Dec 3 14:57:38 JST 2020 x86_64 AMD Ryzen Threadripper 1950X 16-Core Processor AuthenticAMD GNU/Linux
Language (Version): Python

Other

This is 🐛 Bug Report

Issue Analytics

State:
Created 3 years ago
Reactions:3
Comments:28 (21 by maintainers)

Top GitHub Comments

3reactions

christophgysincommented, Jun 14, 2021

@hariseldon78

It seems that the above behavior where the root mode can’t be changed is only when using the btrfs storage driver. As a workaround, I switched to overlay2.

$ cat /etc/docker/daemon.json 
{
  "storage-driver": "overlay2"
}

2reactions

Krzysztowcommented, Aug 2, 2022

Same problem happens when building PythonLambda on Fedora 36. Error I was getting:

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown.                                                                    
/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/asset-staging.js:192
			throw fs.existsSync(bundleErrorDir) && fs.removeSync(bundleErrorDir), fs.renameSync(bundleDir, bundleErrorDir), new Error(`Failed to bundle asset ${this.node.path}, bundle output is located at ${bundleErrorDir}: ${err}`)
                                                                                                                   ^
Error: Failed to bundle asset BillFetcherStack/bill-sender/Code/Stage, bundle output is located at /home/krzysztow/projects/monthly-receipt/infra/cdk.out/asset.f3be281c94d2f053035043662b24e8aca59cc253cb06e73b7352d250d72c99f6-error: Error: docker exited with status 127
    at AssetStaging.bundle (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/asset-staging.js:192:116)
    at AssetStaging.stageByBundling (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/asset-staging.js:114:8)
    at stageThisAsset (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/asset-staging.js:46:32)
    at Cache.obtain (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/private/cache.js:1:242)
    at new AssetStaging (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/core/lib/asset-staging.js:61:42)
    at new Asset (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/aws-s3-assets/lib/asset.js:1:736)
    at AssetCode.bind (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/aws-lambda/lib/code.js:1:4628)
    at new Function (/home/krzysztow/projects/monthly-receipt/infra/node_modules/aws-cdk-lib/aws-lambda/lib/function.js:1:2803)
    at new PythonFunction (/home/krzysztow/projects/monthly-receipt/infra/node_modules/@aws-cdk/aws-lambda-python-alpha/lib/function.ts:73:5)
    at new BillFetcherStack (/home/krzysztow/projects/monthly-receipt/infra/lib/infra-stack.ts:85:32)

Changing default storage-driver in /etc/docker/daemon.json to "storage-driver": "overlay2" fixes the issue.