Skip to content

How to debug "Error: Runtime exited with error: exit status 142"

0

I have a Lambda function written using NodeJS 20 and Typescript. It's too big even with lambda layers so I created a Docker image. It's triggered by a SNS Topic. After trying a bunch of things that didn't work I decided to strip the handler to just three console log statements.

export const handler: SNSHandler = async (event: SNSEvent, context) => {
  console.log("Starting !!!");
  console.log(`Event: ${JSON.stringify(event, null, 2)}`);
  console.log("Stopping !!!");

When I test with even this simple handler I get the following error:

entrypoint requires the handler name to be the first argument
INIT_REPORT Init Duration: 17.69 ms	Phase: init	Status: error	Error Type: Runtime.ExitError
entrypoint requires the handler name to be the first argument
INIT_REPORT Init Duration: 2.31 ms	Phase: invoke	Status: error	Error Type: Runtime.ExitError
START RequestId: 835d7dd3-ce97-4224-9042-faf0b42b34c4 Version: $LATEST
RequestId: 835d7dd3-ce97-4224-9042-faf0b42b34c4 Error: Runtime exited with error: exit status 142
Runtime.ExitError
END RequestId: 835d7dd3-ce97-4224-9042-faf0b42b34c4
REPORT RequestId: 835d7dd3-ce97-4224-9042-faf0b42b34c4	Duration: 4.33 ms	Billed Duration: 5 ms	Memory Size: 1024 MB	Max Memory Used: 3 MB

How do I debug this? I built the Docker image on Bitbucket.

Dockerfile

# --- Build Stage ---
FROM public.ecr.aws/lambda/nodejs:20 AS builder

# Set working directory
WORKDIR /app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies (using npm ci for clean install)
RUN npm ci

# Copy TypeScript source code
COPY src ./src
COPY tsconfig.json ./

# Install dependancies
RUN npm install

# Build the application (make sure your build script creates the "dist" folder)
RUN npm run build

# Log files AFTER the build in the builder stage
RUN echo "Files AFTER build in builder stage:" && ls -la /app/dist

# --- Final Stage (Lambda Image) ---
FROM public.ecr.aws/lambda/nodejs:20

# Set working directory
WORKDIR /var/task

# Copy package.json and package-lock.json (or npm-shrinkwrap.json)
COPY package*.json ./
COPY --from=builder /app/dist ./

# (Optional, but highly recommended) Set the handler function
ENV AWS_LAMBDA_HANDLER index.handler

# (Optional) Set NODE_OPTIONS for increased stack size if needed
ENV NODE_OPTIONS --max-old-space-size=512

asked 2 years ago930 views

2 Answers
1
Accepted Answer

Based on the error message and your Dockerfile, it seems the main issue is that the Lambda runtime is not finding the handler function correctly.

▸ Entrypoint in Dockerfile: The error clearly states that lambda runtime is unable to find the handler function and the Dockerfile doesn't explicitly set the CMD instruction for the entrypoint. So I would suggest adding this line at the end of your Dockerfile:

CMD [ "index.handler" ]

Replace "index.handler" with the actual path to your handler function.

▸ Ensure the handler is correctly specified: Ensure that your Lambda function's handler is correctly specified in the AWS Lambda console or your deployment configuration. For example, if your handler is in "index.js" and named "handler", the configuration should be "index.handler". (or whatever your entry file and function name are).

[+] https://docs.aws.amazon.com/lambda/latest/dg/nodejs-image.html

[+] https://repost.aws/knowledge-center/lambda-docker-image-error

If you continue experiencing issues, feel free to open a case with AWS Premium Support.

AWS

answered 2 years ago

EXPERT

reviewed 2 years ago

0

The error you're encountering suggests there's an issue with how your Lambda function is being invoked, specifically related to the handler configuration. Here are some steps to debug and potentially resolve the issue:

  1. Handler Configuration: Ensure that your Lambda function's handler is correctly specified in the AWS Lambda console or your deployment configuration. It should match the exported handler in your code. For example, if your handler is in "index.js" and named "handler", the configuration should be "index.handler".

  2. Entrypoint in Dockerfile: Your Dockerfile doesn't explicitly set the CMD instruction for the entrypoint. Consider adding this line at the end of your Dockerfile:

    CMD [ "index.handler" ]

    Replace "index.handler" with the actual path to your handler function.

  3. Build Process: Verify that your build process is correctly transpiling TypeScript to JavaScript and that the resulting files are in the expected location. The error suggests the runtime can't find the handler, which could be due to incorrect file paths or naming.

  4. File Structure: Double-check that your handler file (likely "index.js" after transpilation) is in the correct location within the Docker image. It should be in the /var/task directory.

  5. Node.js Version: While you're using Node.js 20, which is relatively new for Lambda, make sure all your dependencies are compatible with this version.

  6. Lambda Function Configuration: In the AWS Lambda console, verify that the handler name in the "Runtime settings" section matches your actual handler function name.

  7. Permissions: Ensure that the Lambda execution role has the necessary permissions to access any resources your function needs, including CloudWatch Logs for proper logging.

  8. Local Testing: Try running your Docker image locally to see if you can reproduce the error and get more detailed logs.

  9. CloudWatch Logs: Check the full CloudWatch Logs for your Lambda function. There might be additional error messages or stack traces that could provide more insight into the problem.

If these steps don't resolve the issue, you may need to add more detailed logging within your function and in the Dockerfile build process to pinpoint exactly where the failure is occurring.
Sources
"Runtime.ExitError" while running a lambda | AWS re:Post
Troubleshoot deployment issues in Lambda - AWS Lambda
Learn the differences between Lambda runtime version and runtime identifier | AWS re:Post

answered 2 years 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.