执行 aws-lambda 函数时出现错误“fork/exec /var/task/main：没有这样的文件或目录”答案

【问题标题】：error "fork/exec /var/task/main: no such file or directory" while executing aws-lambda function执行 aws-lambda 函数时出现错误“fork/exec /var/task/main：没有这样的文件或目录”
【发布时间】：2020-01-27 16:45:54
【问题描述】：

在执行 lambda 函数时获取error fork/exec /var/task/main: no such file or directory。

我正在使用 Windows 平台在 Go 中运行和构建代码。

我已完成以下步骤来部署 go aws-lambda 处理程序：

在windows平台用VSCode用go语言编写代码
使用以下命令构建项目：go build main.go
将 main.exe 转换为 main.zip
使用 aws 控制台帐户上传了带有处理程序名称 main aws-lambda 函数的 main.zip
创建了测试事件来测试 lambda 函数
出现错误“fork/exec /var/task/main: no such file or directory while execution lambda function”

package main

import (
    "fmt"

    "github.com/aws/aws-lambda-go/lambda"
)

// Request represents the requested object
type Request struct {
    ID    int    `json:"ID"`
    Value string `json:"Value"`
}

// Response represents the Response object
type Response struct {
    Message string `json:"Message"`
    Ok      bool   `json:"Ok"`
}

// Handler represents the Handler of lambda
func Handler(request Request) (Response, error) {
    return Response{
        Message: fmt.Sprint("Process Request Id %f", request.ID),
        Ok:      true,
    }, nil
}

func main() {
    lambda.Start(Handler)
}

构建命令

go build main.go

AWS 控制台中的详细错误

{
  "errorMessage": "fork/exec /var/task/main: no such file or directory",
  "errorType": "PathError"
}

AWS 控制台中的日志输出

START RequestId: 9ef206ed-5538-407a-acf0-06673bacf2d7 Version: $LATEST
fork/exec /var/task/main: no such file or directory: PathError
null
END RequestId: 9ef206ed-5538-407a-acf0-06673bacf2d7
REPORT RequestId: 9ef206ed-5538-407a-acf0-06673bacf2d7  Duration: 0.64 ms   Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 31 MB  Init Duration: 1.49 ms

【问题讨论】：

标签： go amazon-s3 aws-lambda handler

【解决方案1】：

在命令提示符下运行以下命令

set GOOS=linux
set GOARCH=amd64
set CGO_ENABLED=0

在此之后，构建您的项目并将 zip 文件上传到 aws 控制台 lambda

喜欢这个

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o main main.go

参考链接：https://github.com/aws/aws-lambda-go

【讨论】：

虽然在这个例子中这不是问题，但我认为值得指出的是，可执行文件必须被称为“main”，而不仅仅是代码中的函数。按照上面的说明，我发现这一点很困难。
是的，你是对的，可执行文件必须被称为“main”，而不仅仅是代码中的函数。
在第一步之后，我只需要执行“go build -o main main.go”，压缩出现的主文件并上传到 AWS。这至少解决了我的问题
是的，可执行文件的名称是关键 - 但名称并不一定是main。可以将 AWS 端的 Handler 名称更改为另一个可执行名称。

【解决方案2】：

可能发生的原因有两个：

你没有在 go build 中使用 GOOS=linux GOARCH=amd64，所以试试：

GOOS=linux GOARCH=amd64 go build -o main main.go
您曾经使用 golang-alpine 基础镜像构建此程序的一些 CI 功能，因此请尝试使用完整的 golang 镜像。

【讨论】：

使用标准的无服务器框架锅炉代码，这样就解决了错误

【解决方案3】：

在我的情况下，问题是默认设置的处理程序为 'hello' 函数。

需要通过 AWS Lambda 视图面板 -> 基本设置 -> 编辑将其更改为“main”。

【讨论】：

现在可以在“运行时设置”下找到
为什么在 F 中，新 Lambda 函数的默认处理程序设置为“hello”？即使是基本教程，您也将所有内容命名为“主要”！

【解决方案4】：

最近我遇到了类似的问题，我解决了。正如错误所说，它正在查找具有句柄名称的可执行文件，因此您应该将可执行文件命名为与处理程序相同。

按照这些步骤，您不会收到此错误，我正在使用 PowerShell

> go.exe get -u github.com/aws/aws-lambda-go/cmd/build-lambda-zip # If you do not this have utility earlier
> $env:GOOS = "linux"
> $env:GOARCH = "amd64"
> $env:CGO_ENABLED = "0"
> go build -o .\Handler .\main.go # considering your are in the same directory where your main.go or handler code is present
> ~\Go\Bin\build-lambda-zip.exe -o .\Handler.zip .\Handler

上传此代码，并将处理程序名称更改为 Handler（您在上面创建的可执行文件的名称）

如果这有帮助，请告诉我。

【讨论】：

在 AWS lambda 函数“处理程序”中命名处理程序是一个重要的步骤，一旦执行了上述步骤。

【解决方案5】：

就我而言，这与我的 Go 设置有关。

当我使用 Go 版本管理器时，我必须在编译我的项目之前运行以下命令来指定正确的 Go 路径。

gvm use go1.x.x

继续编译然后部署。

【讨论】：

【解决方案6】：

我的案子很奇怪，但我会把它留在这里以备不时之需。

我在 Docker 容器中构建了我的可执行文件，然后使用 Docker cp 将文件放在本地目录中。然后我压缩了可执行文件并部署它。

显然，Docker cp 创建了一个类似符号链接的文件，而不是一个实际的文件，所以它不起作用。

我的解决方案是使用 sudo cp 并将可执行文件复制为另一个文件，这会创建一个物理文件，然后部署它。

【讨论】：

【解决方案7】：

在我尴尬的情况下，我从外部压缩文件夹，所以我上传的 zip 中的路径是“文件夹/主”

【讨论】：

【解决方案8】：

此错误与程序无关；这是一个配置问题。请尝试在 lambda 控制台中的 Go Runtime 设置下给出编译好的 go 文件名 -

在我的情况下，我的 go lambda 编译文件是测试，因此将处理程序配置为测试，它对我有用。

Example Configuration

【讨论】：

【解决方案9】：

就我而言，解决方案非常简单。

我的命令构建有误。我所做的是go build . 而不是go build main.go

压缩文件应该是main.zip。

控制台 AWS 中的处理程序信息部分应命名为 main。不是handler，因为 lambda 先调用主函数

【讨论】：

你已经尽力了，但这并不依赖于添加其他答案中没有的任何内容
请在您的回答中提供更多详细信息。正如目前所写的那样，很难理解您的解决方案。

【解决方案10】：

如果使用 SAM cli 部署，请确保在“sam deploy”之前运行“sam build”

【讨论】：

【解决方案11】：

就我而言，这与我用来构建 go 二进制文件的图像有关。我从使用alpine切换到使用amazon linux 2，问题解决了。

【讨论】：