While running in the
provided.al2 runtime, my lambda, which is written in Rust, is giving the following error:
failed to stat /tmp/myrepo/.git
I'm using the
git2 crate to clone a git repository (which is empty) into the
/tmp directory. The clone process seems to be succeeding. The files are created on the filesystem from what I can tell, but when trying to verify the clone,
stat isn't able to see the files or get information about them.
I suspect this is because
/tmp may actually be a shared directory under the hood, which may be the source of the problem.
While troubleshooting, I also tried attaching an EFS share, which produced the same results. I was able to clone the repository, write the files to disk (in this case an empty repository with
.git folder), but cannot call
stat on them.
I'm almost to the point of changing my approach, but wanted to see if my suspicions could be confirmed and/or if there's a way to resolve this without rewriting the application.
To deploy the lambda, I've zipped the
bootstrap binary, uploaded to S3, and deployed via CloudFormation template. Below is the CloudFormation template I've used:
- Effect: Allow
Role: !GetAtt LambdaFunctionRole.Arn
- !Ref VpcSecurityGroupIds
- !Ref VpcSubnetIds
- !Ref PostgresLibpqLayerArn
S3Bucket: !Ref LambdaSourceBucketName
S3Key: !Ref LambdaBuildZipFile
The lambda is deployed and is running fine. It's zipped, uploaded to S3, then deployed via CloudFormation. I've included the CloudFormation as an update to the original question.
The code in the lambda is fetching a git repository from CodeCommit, cloning it to the local filesystem. This is where I'm having an issue - it seems that my application is able to write to the filesystem, but it doesn't seem that it is able to do other operations wiith the filesystem, like stat, which is trying to collect information about the files on the system.
/tmpdirectory a shared volume?
I will recommend reading this https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html to understand more about how the lambda life-cycle works.
Yes it is possible that the same lambda microVM is used for multiple invocations of the lambda function and the /tmp folder will be re-used across all those functions. Please look at the Temporary Storage with /tmp section in this blog - https://aws.amazon.com/blogs/compute/choosing-between-aws-lambda-data-storage-options-in-web-apps/