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.
Update
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:
AWSTemplateFormatVersion: "2010-09-09"
Parameters:
LambdaBuildZipFile:
Type: String
VpcSecurityGroupIds:
Type: String
VpcSubnetIds:
Type: String
LambdaSourceBucketName:
Type: String
PostgresLibpqLayerArn:
Type: String
Resources:
LambdaFunctionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
- arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole
- arn:aws:iam::aws:policy/AWSCodeCommitFullAccess
- arn:aws:iam::aws:policy/AmazonRoute53FullAccess
- arn:aws:iam::aws:policy/AmazonRDSFullAccess
Lambda:
Type: AWS::Lambda::Function
Properties:
Handler: main
Runtime: provided.al2
Role: !GetAtt LambdaFunctionRole.Arn
Timeout: 300
VpcConfig:
SecurityGroupIds: !Split
- ","
- !Ref VpcSecurityGroupIds
SubnetIds: !Split
- ","
- !Ref VpcSubnetIds
Layers:
- !Ref PostgresLibpqLayerArn
Code:
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.
Is the
/tmp
directory 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/