[earakely-scale]

What changes

Every release since v0.9.1522 has failed to publish at the same step: the disk form agentenv-ubuntu-24.04-disk's "Check that it boots" timed out after 900 s on GitHub's arm64 runner, and the amd64 job was cancelled with it. Nothing has reached PyPI since 0.9.1521.

The guest boots fine. The check couldn't see it:

• The check reads the console. It waits for an "entered RUNNING" line for every program the base declares. Before feat(computers): a ubuntu-24.04 computer in a multi env follows its gateway's clock (FD-5476) #649 the session's supervisord was the computer's first process, so its lines (xvfb, dbus, desktop) reached the console.
• Since feat(computers): a ubuntu-24.04 computer in a multi env follows its gateway's clock (FD-5476) #649, root's supervisord runs the session's supervisord as a program, and wrote its output to /var/log/agentenv-root/session.log. The console showed root's three programs alone (clock, egress, session), exactly as the failed runs' logs show.
• A disk guest also had no /dev/stdout. The disk's init mounts devtmpfs, which has no /dev/fd, /dev/stdin, /dev/stdout or /dev/stderr: a container runtime or udev makes those links. So pointing the session's output at /dev/stdout alone wrote it to a plain file of that name.

The fix:

• root.conf sends the session's supervisord's output to the console (stdout_logfile=/dev/stdout), as when it was the first process. Nothing read session.log.
• The disk's init makes the four standard links before it starts the computer, as a container runtime would. A shell's <(...) in the guest gets /dev/fd too.
• The boot check (infra_build.py _boots) waits for root's programs as well as the session's.
• A unit test pins root.conf's console logging and the init's /dev/stdout link to what the check reads.

The slow tier's disk race (folded in from #668)

This PR changes the disk, so CI builds it fresh, and its integration-local-slow (3/12) failed twice on a race that also fails main now and then (eac7660, and #580's merge): launcher_test.py's three tests, KeyError: 'image'.

• Why: a slow shard's two pytest workers both compose the shared desktop. When its disk's key is new, neither finds it stored, so both build it under localhost:5000/agentenv-computers:<key> with different bytes. The second moves the tag off the image the first pinned by digest, and the first's boot (--mount type=image, which Docker doesn't pull for) fails with "No such image". On the rerun, their two pushes of the tag collided instead (the registry answered 500).
• The composer: a Linux disk is now looked up, made and pushed holding a lock of its key (linux-disk:<key>), as Windows and Omarchy disks already are, so a second compose of it waits and reuses the first's. A unit test checks each arch's disk is looked up, made and pushed holding it, and fails without the change.
• The integration tier: agent-env keeps its locks in the state root, and each integration test has one of its own, so the composer's lock alone didn't span the two workers. A new tst/integration/conftest.py keeps the locks that guard this machine's Docker and registry (composes, disks, disk exports, image builds, pulls and saves) in one folder for the run, as one user's processes share theirs. Two processes with separate state roots then take turns on linux-disk:<key>, which I checked locally.
• Docker itself is consistent: on a Docker 28 daemon on the containerd image store, docker image inspect and --mount type=image agree on a pinned name every time; once the tag moves to a rebuilt image, the first image's pinned name is gone for both.

Testing

On an agent-environments-admin Graviton host with no KVM, so arm64 under TCG as on GitHub's arm64 runner. I took the base image v0.9.1529 published (agentenv-ubuntu-24.04:src-f3e72c92…-arm64) with only this branch's root.conf swapped in, built its disk with this branch's recipe, and ran the release's own check (infra_build.py smoke agentenv-ubuntu-24.04-disk … --launcher …):

Disk	Result
root.conf fix alone (d2331f7)	the console still showed only clock, egress and session: the guest had no /dev/stdout
Both fixes (05d4f08)	"booted to its desktop under TCG" in 2½ minutes, all six programs running

Unit: test_infra_build_script.py (63) plus the base's clock, egress and shipped-computer tests pass.

The amd64 disk wasn't booted separately: it takes the same init and root.conf, under KVM on the x64 runner.

After merge

The next tag publishes the new base and disk images and everything since 0.9.1521 to PyPI; the bot then opens the pin bump.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no actionable new issues were found.

Summary

Restores session startup messages on disk consoles and makes the boot check wait for both supervisors' programs.

• Disk boot checks now see starts from both supervisors.
• Linux disk builds wait their turn when keys match.

No actionable new issues were found. Tests were inspected, not run.

_{Reviews (4) · Last reviewed commit: "test: the integration tier's workers sha..." · Reviewed by Greptile}