[earakely-scale]

What and why

Every release since v0.9.1522 has failed to publish, v0.9.1522 to v0.9.1529, so nothing merged since Nov 12 23:40Z is on PyPI.

• What fails: the release's disk boot check (infra_build.py smoke) on the ubuntu-24.04 disk. It boots the disk and waits, on its console, for every program in the base's supervisord.conf to log entered RUNNING, for up to 15 minutes.
• Why: since feat(computers): a ubuntu-24.04 computer in a multi env follows its gateway's clock (FD-5476) #649, root's supervisord (root.conf) runs the session's supervisord as the session user. It wrote the session supervisord's output to /var/log/agentenv-root/session.log, so the console showed only root's own programs (clock, egress, session) and the check timed out.
• The image itself was fine: booted on a VM, the session's supervisord had dbus, xvfb and desktop running and the XFCE panel up within two seconds.

What changes

• root.conf's session program logs to /proc/self/fd/1 (stdout_logfile_maxbytes=0), as the session's supervisord did when init ran it before feat(computers): a ubuntu-24.04 computer in a multi env follows its gateway's clock (FD-5476) #649. That's root supervisord's own output: the console in a disk, the container's log in a container.
• Not /dev/stdout, the first commit's choice. A disk's /dev is the kernel's devtmpfs, which has no /dev/stdout and no /dev/fd, so supervisord made /dev/stdout a regular file in memory, 870 bytes of the session's output at 45 seconds, growing for the computer's life. The console still showed nothing.
• Still the same: the session user still can't read root's own logs or reach root's socket, and the session's supervisord keeps its own log in /var/log/agentenv/supervisord.log.

v0.9.1528 also failed two local-backends tests, page_driver_test's one-second bound and computer_app_test's WebSocket deploy. Both passed on the merge commit before it and on v0.9.1529's bump, so this PR leaves them alone.

How it was tested

The disk boot check runs only at release time, so it was run on an agent-environments-admin VM: a c8i.4xlarge with nested virtualization, so KVM, as on the release's runner, amd64. The disks were built with the release's own Dockerfile and arguments, from the rootfs v0.9.1529 published (src-f3e72c92…) with only root.conf replaced, and checked with infra_build.py smoke itself.

Check	main's root.conf	/dev/stdout (first commit)	/proc/self/fd/1 (this PR)
Disk boot check	Timed out at 900 s	Timed out at 900 s	Booted to its desktop with KVM
Container console: dbus, xvfb, desktop running	None shown	All shown	All shown
/dev/stdout in the disk	Not checked	A regular 870-byte file	Not opened

The change is the same on arm64, the platform each release failed on first; it wasn't booted there. The VM is torn down.

🤖 Generated with Claude Code

[earakely-scale]

Closing in favor of #666, which has this root.conf change plus what it needs to work in a disk guest: the disk's init had no /dev/stdout (devtmpfs has none; a container runtime or udev makes it), so with this change alone the session's output went to a plain file of that name and the console still showed only clock, egress and session. #666 adds the four standard links to the init and widens the boot check to root's programs; the release's own check passed on the v0.9.1529 arm64 base with it, under TCG on a Graviton host. If a VM test for this PR is still running, it can be stopped.