By using AWS re:Post, you agree to the Terms of Use
/Exit 254 lambda error with no extra explanations/

Exit 254 lambda error with no extra explanations

0

I have a Lambda function running a docker container. The docker container runs without issue localy but on AWS lambda all I get is a "Error: Runtime exited with error: exit status 254" message without any other output. I can mention that I am coding on a Mac with M1 architecture, the docker image is based off node:18-buster-slim with aws-lambda-ric baked into it and chromium installed. I am deploying in SAM with x86 as target architecture since was lambda on arm64 doesn't have the option to deploy chromium yet.

Edit: I am building with the platform=linux/amd64 flag

Edit2: Migrated whole code to fedora:36 running on arm 64 and I am getting same error

START RequestId: 983e9126-a091-460f-9a7b-72b00f29a34f Version: $LATEST
END RequestId: 983e9126-a091-460f-9a7b-72b00f29a34f
REPORT RequestId: 983e9126-a091-460f-9a7b-72b00f29a34f	Duration: 573.49 ms	Billed Duration: 574 ms	Memory Size: 4000 MB	Max Memory Used: 31 MB	
RequestId: 983e9126-a091-460f-9a7b-72b00f29a34f Error: Runtime exited with error: exit status 254
Runtime.ExitError
asked 2 months ago330 views
4 Answers
0
Accepted Answer

After playing around I realised what the issue was. I still do not know what error 254 means but the issue was strictly nodejs 18 lts. Seems like was does not really like it. I was getting error 254 even after building everything for arm (not just x86). After switching to nodes 16 LTS it just worked. Maybe in future nodes 18 will be supported but right now I assume the aws-lambda-ric component does not have the support for it and due to some internal reason the process exits with that error. I am writing this in case anyone else runs in this error in the future. Most likely nodejs 18 might be supported at some point but if you run into this error make sure it is not from using a node version incompatible with was lambda rip yet.

answered a month ago
0

Your Docker image must be built on the same CPU architecture as the architecture you configure for your Lambda function. Building a Docker image on a Mac with an M1 CPU usually produces an image for the Linux/arm64 architecture, so your Lambda function must be configured for the arm64 architecture as well.

If you're using Docker Desktop on an M1 Mac, you can also produce x86 images using docker buildx build that can be deployed onto Lambda using the x86 architecture. You'll want to pass the --platform=linux/amd64 argument to this command.

By the way, we have successfully tested running Chromium on Lambda on Graviton. If you start with the fedora:36 or fedora:35 base images, you can install prebuilt Chromium RPMs from the Fedora package repository. See, e.g., https://fedora.pkgs.org/36/fedora-aarch64/chromium-99.0.4844.51-1.fc36.aarch64.rpm.html

EXPERT
answered 2 months ago
  • I did compile with he linux/amd64 flag and same result. When I am testing the build locally it does show in Docker Desktop that I am running emu emulation of amd64

  • but I will attempt using the fedora bistro, that is a great tip since we want to migrate to arm anyway

  • Tips Fedora

  • @Michael_F as a later update, I migrated the full code to to fedora:36 and arm64. And I am getting the same error: 254. Is there any documentation for said exit code?

0

Yes you could append the host platform on it. But the issue is a difference between where you build the image and the Architecture setting on the lambda.

Example: if you build the image on an m1 mac push to ECR and set the Architecture setting to x86_64 then you will get this error.

You can either change the setting in lambda or if you are working with multiple people on different systems Id suggest using CodePipeline with a CodeBuild step and you can define the system the pipeline builds on so every-time the build is consistent with a buildspec.yaml like this.

version: 0.2 
 
phases: 
  install: 
    runtime-versions: 
      docker: 18 
  pre_build: 
    commands: 
      - echo Logging in to Amazon ECR... 
      - aws --version 
      - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email) 
      - REPOSITORY_URI=$EcrRepo
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build: 
    commands: 
      - echo Build started on `date` 
      - echo Building the Docker image... 
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - aws lambda update-function-code --function-name [YOUR_FUNCTION_NAME] --image-uri $REPOSITORY_URI:$IMAGE_TAG
answered a month ago
  • Solved issue. Was totally unrelated to architecture. After downgrading to node 16 both x86 and arm64 builds worked without a any issues. I was not getting any error for building x86 since I was strictly building for x86 as target architecture. There are still AWS regions that do not support arm but only x86.

  • Keep in mind I was also getting 254 error after migrating everything to arm.

0

In case it helps someone else looking at this... I had an identical issue pop up last week using a node:16 image, which had recently been updated to node:16.15.1. I rolled back to node:16.14.2 to get it working again.

answered 22 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions