go 所有：偶尔在linux-s390x构建器上出现"资源暂时不可用"的故障

ki0zmccv 于 2个月前发布在 Go

关注(0)|答案(9)|浏览(36)

这是否与 CL 177599 和 #32205 有关，对我来说还不清楚。
来自 https://build.golang.org/log/8842ba4fe354ba0d2a48ea5918280b3a2a202dcb 的信息：

##### ../misc/cgo/errors
removing /data/golang/workdir/tmp/TestPointerChecks471752625
--- FAIL: TestPointerChecks (0.98s)
    --- FAIL: TestPointerChecks/exportok (0.00s)
        ptr_test.go:596: 
        ptr_test.go:597: failed unexpectedly: fork/exec /data/golang/workdir/tmp/TestPointerChecks471752625/src/ptrtest/ptrtest.exe: resource temporarily unavailable
FAIL

CC @ianlancetaylor@rsc

来源：https://github.com/golang/go/issues/32328

9条答案

按热度按时间

3z6pesqy1#

以下是在同一构建器上的runtime测试中看似相关的失败：

--- FAIL: TestPanicTraceback (0.00s)
    crash_test.go:67: starting testprog PanicTraceback: fork/exec /data/golang/workdir/tmp/go-build726730629/testprog.exe: resource temporarily unavailable
FAIL

( https://build.golang.org/log/e518ab1802ac73754f4f3a51d7fb3cba86868b4e )
因此，它可能不仅限于misc/cgo/errors测试。

赞(0）回复(0）举报 2个月前

gkn4icbw2#

CC @mundaym

赞(0）回复(0）举报 2个月前

gajydyqb3#

https://golang.org/cl/179603提到了这个问题：misc/cgo/errors: limit number of parallel executions

赞(0）回复(0）举报 2个月前

bmvo0sr54#

我没有再次看到 misc/cgo/errors 的故障，但这仍然在其他测试中偶尔发生：
https://build.golang.org/log/75ddd2b8e6749643c9150bf8846ed69f5afdcddf
https://build.golang.org/log/7028d294ba985b9bd6e5cb2024af1fa2a07f7b37
https://build.golang.org/log/2cc3638b3235b7a7b63a474df5991ec468dc404d
我认为这可能需要在我们 fork/exec Package 器中进行更深入的修复。

赞(0）回复(0）举报 2个月前

eni9jsuy5#

我已经做了一些调查(systemd 对我来说并不十分熟悉),我认为这可能是由于 SLES 12 中的默认 systemd TasksMax 设置导致的。它只有512个线程，包括 stage0、构建器以及它们生成的所有内容...
我不知道如果 fork/exec Package 器遇到这样的限制，是否还能做很多事情，我认为重试不一定能解决这个问题。
我已经在 buildlet 服务中添加了以下几行：

TasksMax=65536
LimitNOFILE=65536
LimitNPROC=65536

希望这能让未来的 s390x 构建器更加稳定...

赞(0）回复(0）举报 2个月前

ezykj2lf6#

有人知道是否有办法检查当前cgroup的资源限制吗？也许我们可以让构建器打印一些它们。

赞(0）回复(0）举报 2个月前

kokeuurv7#

@bradfitz 和 @dmitshur:对于构建小工具的systemd任务设置，你们有什么想法吗？

赞(0）回复(0）举报 2个月前

a11xaf1n8#

关于我们应该为buildlets使用的systemd任务设置，有什么想法吗？
对于Go相关的事物，我一直只使用默认设置。但也许默认设置已经改变，或者你的发行版有更低的限制，或者s390x出于某种原因创建了更多的线程？
有人知道是否有办法检查当前cgroup的资源限制吗？也许我们可以让buildlet打印一些它们。
我不知道。但这是一个好主意。

赞(0）回复(0）举报 2个月前

j8yoct9x9#

但是也许默认值已经改变了，或者你的发行版有更低的限制，或者s390x出于某种原因创建了更多的线程？
我认为这是一个发行版默认设置的问题。Ubuntu 18.04默认为4915个任务，这提供了很多余地。

赞(0）回复(0）举报 2个月前