I am creating a Lambda extension to get secret values from secret manager using as a template:
https://github.com/hariohmprasath/aws-lambda-extensions
I have zipped the files into the following structure.
extension.zip
--> extensions
--> secret-extension
--> secret-extension
--> node_modules
--> extensions-api.js
--> index.js
--> package.json
--> package-lock.json
--> secrets.js
Error:
{
"errorMessage": "RequestId: e5c06575-cf7d-46c0-b168-624e8e9cf572 Error: exit status 127",
"errorType": "Extension.Crash"
}
The Error is that /usr/bin/env: node : No such file or directory
At the top of the index.js file is the command #!/usr/bin/env node (in order to interpret the file in node)
The runtime environment is Nodejs 12 and have tried with 14 as well.(extension documentation says node 12 runtime is required)
What could be causing this issue?
- The lambda runtime is a node runtime so node should be installed.
- I have
ls
the folder and/env
folder exists. - I know node exists within the runtime as
node -v
returns v14.20.0 or v12.22.11 - I am on a windows machine
creating the extension (dont think the deployment could be causing
this because it was written on windows machine.
Any help would be appreciated.
2
Answers
So found out it has to do with a custom environment they are using for the example provided by AWS. Instead I went the route of using a runtime independent solution which has worked as expected.
Documentation
I suspect the issue you may have been encountering is the same as mine, and that issue was:
The
#!/usr/bin/env node
had the whitespace charactersrn
at the end of the line which obviously cannot be seen unless you have your editor display these, and this is how windows handles new lines (*nix systems use justn
); Now when the lambda reads the line, it is trying to interpret it as#!/usr/bin/env noder
which obviously won’t exist, and can’t run the file vianode
.The problem with the logs is when you look at the logs, it won’t render the
r
as that, it could do 1 of 2 things depending on where you look at the logs:r
as a new line character, and thereby just print the whitespace, which is not obvious in the log message; OR the other situation that can occur (which is what happened to me):: No such file or directory
because it’s interpreted ther
as a carriage return, which means it takes thecursor
to the beginning of the line, and overwrites as it prints the new characters,I am pretty confident this is your issue, and I will admit I didn’t solve this 100% on my own as a person in my team had a similar issue with whitespace characters and only after allot of head banging did I think of it, and confirmed using
hexdump -C
to confirm the issue.