0

A question about lambda container images and how to debug them.

The problem: We need to run a legacy binary to process data in a serverless fashion. It is being run in a container image on lambda with a wrapper in nodejs. However, it is crashing with EACCES (errno -13) as the error. Meaning it cannot access something. Everything works locally. My first thought was to try to strace it but the lamdba environment doesn't have permission.

Does anyone have suggestion on how to either better replicate the lambda environment locally or something similar to strace to help debugging what file the legacy binary is try to access on lambda?

We have tried debugging it by running the container locally. We are simulating the lambda environment as much as possible.

  • Image is built from public.ecr.aws/lambda/nodejs:14-x86_64
  • And for running locally: docker run --read-only --rm --tmpfs /tmp -p 9000:8080 test-image
    • I.e., only the /tmp is writable and the rest of the files system readonly like on lambda
  • The legacy binary does need to write to /tmp but, from what I can see of the source code, it doesn't try to write anywhere else. However, the source is very legacy.
    • Everything works correctly when run locally. However fails when run on lambda.
    • From running an strace in a locally run image, all files it tries to access (for read or readwrite) should be accessible already. Only files under /tmp are opened for write.
  • Is that the full error message you see? Isn't there a proper stack trace? – Paolo Nov 04 '22 at 11:19
  • @Paolo No, there isn't a stack trace. The binary is being spawned using `spawnSync`. The JS wrapper executes fine. When spawning the binary on lambda it returns an EACCES error with nothing in `stdout` or `stderr`. – Shawn MacIntyre Nov 06 '22 at 03:51

0 Answers0