@millerresearch, can something be done to prevent this builder from getting wedged?

I've reconfigured the plan9-arm cluster with a filesystem version which I hope is more stable.

Looking at the local log for the most recent of these failures, I see it ends this way:

2022/05/03 17:40:28 [0x10e9e4d0] Running /boot/workdir/go/bin/go with args ["/boot/workdir/go/bin/go" "tool" "dist" "test" "--no-rebuild" "--banner=XXXBANNERXXX:" "go_test:errors" "go_test:expvar" "go_test:flag"] and env ["home=/usr/glenda" "path=/boot/workdir/go/bin\x00.\x00/bin" "type=host-plan9-arm-0intro" "GOARM=7" "GO_BUILD_KEY_DELETE_AFTER_READ=false" "status=" "GO_TEST_TIMEOUT_SCALE=6" "fs=aoe" "GOCACHE=/boot/cache" "GOROOT_BOOTSTRAP=/boot/workdir/go1.4" "sysname=pi4h" "workdir=/boot/workdir" "objtype=arm" "*=aoe" "WORKDIR=/boot/workdir" "GO_BUILDER_NAME=plan9-arm" "GOROOT=/boot/workdir/go" "GOPATH=/boot/workdir/gopath" "GOPROXY=http://gk3-services-nap-1pnbo1ui-1f1ba50a-97gm.c.symbolic-datum-552.internal:30157" "GOPROXY=off" "GOROOT_BOOTSTRAP=/sys/lib/go1.17"] in dir /boot/workdir
2022/05/03 17:40:54 [0x10e9e4d0] Run = ok, after 25.937931117s
2022/05/03 17:40:54 [0x10e68d10] Running /boot/workdir/go/bin/go with args ["/boot/workdir/go/bin/go" "tool" "dist" "test" "--no-rebuild" "--banner=XXXBANNERXXX:" "go_test:fmt" "go_test:go/ast" "go_test:go/build"] and env ["home=/usr/glenda" "path=/boot/workdir/go/bin\x00.\x00/bin" "type=host-plan9-arm-0intro" "GOARM=7" "GO_BUILD_KEY_DELETE_AFTER_READ=false" "status=" "GO_TEST_TIMEOUT_SCALE=6" "fs=aoe" "GOCACHE=/boot/cache" "GOROOT_BOOTSTRAP=/boot/workdir/go1.4" "sysname=pi4h" "workdir=/boot/workdir" "objtype=arm" "*=aoe" "WORKDIR=/boot/workdir" "GO_BUILDER_NAME=plan9-arm" "GOROOT=/boot/workdir/go" "GOPATH=/boot/workdir/gopath" "GOPROXY=http://gk3-services-nap-1pnbo1ui-1f1ba50a-97gm.c.symbolic-datum-552.internal:30157" "GOPROXY=off" "GOROOT_BOOTSTRAP=/sys/lib/go1.17"] in dir /boot/workdir
2022/05/03 18:00:54 Halting in 1 second.
2022/05/03 18:00:54 buildlet reverse mode exiting.

It seems that a dist test has timed out after 20 minutes, and the buildlet has then exited without sending an error status back to the coordinator. The builder machine will then have rebooted, breaking the TCP connection, and the coordinator sees a "communication error".

Wouldn't it be better if the buildlet sent back an explicit error to the coordinator in such cases, so the test run could be retried?

It seems that a dist test has timed out after 20 minutes, and the buildlet has then exited without sending an error status back to the coordinator. The builder machine will then have rebooted, breaking the TCP connection, and the coordinator sees a "communication error".

Hrm. Is there a way to set that timeout to something longer?

Wouldn't it be better if the buildlet sent back an explicit error to the coordinator in such cases, so the test run could be retried?

IMO it would not be appropriate to retry the test — if it times out on one run, what's to stop it from timing out on the next one? And, moreover, if we do 20 minutes of work and then time out and retry, we've just wasted 20 minutes of builder time that could have been put to more productive use. (#42699 is closely related.)

Hrm. Is there a way to set that timeout to something longer?

Bad idea, I think. The test of {fmt, go/ast, go/build} on plan9-arm normally takes about 50 seconds. If it's timing out after 20 minutes, that's not just slow, it's stalled. Lengthening the timeout would just waste more time.

IMO it would not be appropriate to retry the test — if it times out on one run, what's to stop it from timing out on the next one?

Whenever I do a manual retry using the retrybuilds command after a communication error failure, the next attempt always succeeds. My strong hunch is that it's something in the underlying platform that's stalling non-deterministically, not within the go code.

I will set up a process on my local builders to monitor progress on the log output file. If nothing is emitted for say 15 minutes, it will send an alert so I can go in with the debugger and try to find out what's stalled.

greplogs -l -e '\Aplan9-arm.*(\n.*)*communication error to buildlet' --since=2022-05-04
2022-05-10T18:37:58-508cb32/plan9-arm

I've found a likely cause: an assertion failure in the Plan 9 filesystem. While working on diagnosing that, I can try making it retry instead of halting, so it won't stall the builder.

Is the retry in place? The builder seems a little more stable, but there's still a recent one of these.

greplogs -l -e '\Aplan9-arm.*(\n.*)*communication error to buildlet' --since=2022-05-11
2022-05-17T19:57:24-88c5324/plan9-arm

There was another failure mode: one of the raspberry pi builders had only 1GB of RAM and no swap configured. I've added some swap space so it should be more stable now.

One more of these after the swap change:
greplogs --dashboard -md -l -e '(?ms)\Aplan9-arm.*communication error to buildlet' --since=2022-05-18
2022-06-06T18:37:38-fc97075/plan9-arm

I'd like to propose excusing the plan9-arm builders from the repeatedCommunicationError check. The commit introducing this check was labelled "don't let plan9 buildlets retry forever", to solve an issue where repeated retries on plan9-386 virtual machines would "waste our resources" (issue #31261).

But the plan9-arm builders don't run on a virtual resource, but on real hardware. That hardware is not particularly enterprise-quality: a cluster of Raspberry Pi boards sharing a power supply. Sometimes a glitch of the hardware or the Plan 9 filesystem causes a builder to crash or reboot, leading to this "communication error" failure. In my experience, retrying a test after such a failure will invariably succeed. Therefore this check is not saving resources by preventing a "retry forever", but just acting as a nuisance preventing a successful automatic retry.

If this is acceptable, I'll submit a CL to x/build/cmd/coordinator to remove plan9-arm from this check.

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

---
Installed Go for plan9/arm in /boot/workdir/go
Installed commands in /boot/workdir/go/bin
*** You need to bind /boot/workdir/go/bin before /bin.

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

Change https://go.dev/cl/470355 mentions this issue: x/build/cmd/coordinator: exempt plan9-arm from repeatedCommunicationError

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

This is probably pending a redeploy of cmd/coordinator.

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

---
Installed Go for plan9/arm in /boot/workdir/go
Installed commands in /boot/workdir/go/bin
*** You need to bind /boot/workdir/go/bin before /bin.

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

Has the cmd/coordinator been updated yet?

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "plan9-arm" && `communication error to buildlet`

communication error to buildlet (promoted to terminal error): network error promoted to terminal error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain

— watchflakes

Has the cmd/coordinator been updated yet?

I think so, yes.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)