Flaky release-test: iperf3 Cannot allocate memory in Single VPC Suite / No restrictions

[pau-hedgehog]

https://github.com/githedgehog/fabricator/actions/runs/25784034313/job/75733788636

07:37:03 ERR Test connectivity failed ping=0 iperf=1 curl=0 took=2m0.292606171s errors="iperf server-01 -> server-03: client: unable to receive results: Cannot allocate memory, server: running command: cancelled: context canceled: "
07:37:03 ERR FAIL test="No restrictions" error="iperf server-01 -> server-03: client: unable to receive results: Cannot allocate memory, server: running command: cancelled: context canceled: "
07:42:59 ERR FAIL test="No restrictions" error="iperf server-01 -> server-03: client: unable to receive results: Cannot allocate memory, server: running command: cancelled: context canceled: "
07:55:29 ERR FAIL test="No restrictions" error="iperf server-01 -> server-03: client: unable to receive results: Cannot allocate memory, server: running command: cancelled: context canceled: "

[pau-hedgehog]

iperf3 from server-01 to server-03 (bidir, -P 4 -t 10) aborted at ~3.00s with Cannot allocate memory on the client. Server-side iperf3 JSON output (parse-failed on the framework side because of a leading warning: Failed to read JSON data size - read returned 0; errno=2) closes with:

"error": "error - unable to receive results: Bad file descriptor"

This is the consequence of the client process dying mid-test (control socket closed), not an independent server fault.

Two iperf3 server took longer than usual to start warnings cluster on server-03 within ~50 seconds (normal start is sub-ms):

07:35:18 DBG iperf3 server took longer than usual to start from=server-01 to=server-03 waitTime=1.19150006s
07:36:05 DBG iperf3 server took longer than usual to start from=server-03 to=server-04 waitTime=1.081895031s

server-03 was both target then source. Strong hint that VM was thrashing.

Hypothesis

VLAB server VMs are 768 MB Flatcar. Each per-test iperf3 invocation:

1. SSH to the destination
2. toolbox -E LD_PRELOAD=... iperf3 -s -1: containerd spawns a fresh container for the toolbox wrapper (memory hit at fork)
3. iperf3 -c ... -P 4 -t 10 --bidir: 4 streams in bidir mode roughly doubles per-invocation footprint vs unidir (buffers + result aggregation)
4. Tear down the toolbox container

Under contention this exhausts the small VM, malloc inside iperf3 client returns ENOMEM at result aggregation, client exits, server reports EBADF.

This appears to be the first scheduled master CI run with bidir+toolbox in concert at scale.

#1702 (branch pau/iperf-daemon, commit 73a9215) replaces the per-test exec with a long-lived systemd-managed iperf3 daemon installed via setup-vpcs. That removes:

• the toolbox container spawn per invocation
• the per-test malloc spike on the server VM
• the listener-readiness ss -ltn poll (also a flake source)
• the toolbox mutex on the destination

[pau-hedgehog]

#1702 (merged 2026-05-15) added a long-lived iperf3.service systemd unit on every VLAB server VM, removing the per-test toolbox iperf3 -s -1 spawn on the server side. The client side still does the per-test spawn:

pkg/hhfab/testing.go:3087
cmd := fmt.Sprintf("toolbox -E LD_PRELOAD=/lib/x86_64-linux-gnu/libgcc_s.so.1 -q timeout %d iperf3 -P 4 -J -c %s -t %d", opts.IPerfsSeconds+25, toIP.String(), opts.IPerfsSeconds)

Every test pair invocation forks a fresh docker container via toolbox on the client VM. The client is also where JSON result aggregation happens (-J -P 4, doubling to 8 streams in --bidir). Server VM is 768 MB (pkg/hhfab/vlabconfig.go:201), and after Flatcar baseline (~150 MB), docker (~50-100 MB), and the always-on iperf3.service container (~30 MB), the headroom is ~500 MB. The per-test toolbox spawn plus an 8-stream JSON buffer at result-aggregation time can plausibly hit ENOMEM.

Recent confirmation (PR #1763, run 26357732238)

Same failure mode on a different pair: iperf server-02 -> server-10: client: unable to receive results: Cannot allocate memory. 4 occurrences clustered on one pair in a ~30 minute window, all client-side, while bidir=true and -P 4 were active across the suite. Other RT jobs in the same run passed. Same shape as the original case server-01 → server-03.

Retries do not help: pkg/hhfab/testing.go:3052-3062 only retries when every failure was send-speed-too-low. ENOMEM returns immediately.

Proposed fix shape

Replace the client command with docker exec into the already-running iperf3.service container:

# current
toolbox -E LD_PRELOAD=... timeout N iperf3 -P 4 -J -c <ip> -t N [--bidir]

# proposed
docker exec iperf3 timeout N iperf3 -P 4 -J -c <ip> -t N [--bidir]

The daemon container (pkg/hhfab/vlab_server_butane.tmpl.yaml:71) is --network=host and has the iperf3 binary, so docker exec works directly. docker exec into an existing container is essentially free (no new namespace creation, just an extra exec process inside), dropping the per-test memory hit from ~50-100 MB to ~10 MB (just iperf3 client process + JSON buffer).

Will open a follow-up PR with the change.

[pau-hedgehog]

Still firing after PR #1764.

New occurrence: run 27864187017 / job 82465669199 (v-iso-l3vni-rt, master @ 74e3a7e, 2026-06-20). The docker-exec fix is confirmed present in that build. Error is identical: single pair server-02 → server-03, ping=0 curl=0 iperf=1.

The fix removed the container-fork overhead but not the client's own allocation. The iperf3 client running via docker exec into the daemon container and the daemon itself share the same 768 MB cgroup. With -P 4 -J --bidir the client's iperf_recv_results() malloc still fails.

Tests are sequential (IPerfsParallel=1), so this is a single-test memory pressure problem, not concurrent load.

Missing diagnostics that would confirm whether it's the daemon crashing on server-03 (closing the results socket abnormally, causing the ENOMEM on the client side) vs the client process itself OOMing on server-02: free -m, dmesg | grep -i oom, and docker logs iperf3 from both nodes at failure time. PR #1630 adds these to the server show-tech.