Signature
[TTY_ORACLE:FAIL:cloexec_exec:fcntl_setfd_failed:EAGAIN]
FAIL: TTY oracle reported failure: [TTY_ORACLE:FAIL:cloexec_exec:fcntl_setfd_failed:EAGAIN]
Seen on origin/main at bdb5be90 (merge of PR #795, "fix/ttbr0-shadow-reconciliation"),
production-profile aarch64 gate, during today's #690 A/B run.
Where
- Serial:
docs/planning/green-program/aarch64-testing/serials/slice1/ab-690/main/boot-3-serial.txt
- Gate transcript:
docs/planning/green-program/aarch64-testing/serials/slice1/ab-690/main/boot-3-gate.txt
Both are in-repo on origin/main as of bdb5be90.
STEP-1 reading
arm_cloexec_exec() in userspace/programs/src/tty_oracle.rs (arm 14 of 14) opens a
fresh PTY pair, calls fcntl(slave, F_SETFD, FD_CLOEXEC) via
libbreenix::io::fcntl_setfd, then forks and execs a marker copy of itself to prove
close_cloexec() retires the child's fork-cloned slave fd during exec(). The failing
line is the very first step: the fcntl(F_SETFD) call itself returned EAGAIN before
the fork/exec ever ran.
On the kernel side, sys_fcntl (kernel/src/syscall/handlers.rs:3858) resolves the
current process by first acquiring the process-manager lock via
crate::process::try_manager() (a try-lock). If that try-lock fails to acquire, the
handler returns SyscallResult::Err(11) -- errno EAGAIN -- before ever reaching the
F_SETFD dispatch arm. The actual F_SETFD implementation,
FileDescriptorTable::set_fd_flags (kernel/src/ipc/fd.rs:630), can only fail with
EBADF (bad fd) -- it has no EAGAIN return path of its own. So this EAGAIN did not
come from the fd-flags logic; it came from try_manager() finding the process-manager
lock contended at the moment tty_oracle issued its fcntl syscall, i.e. a transient
lock-contention failure in the fcntl syscall's process-lookup path, not a cloexec/PTY
defect.
Separately: bsshd reached "listening" in this same boot (serial.txt:389,
bsshd: listening on 0.0.0.0:2222), after tty_oracle had already exited(1) at
serial.txt:325. The gate's own transcript (boot-3-gate.txt) reports
FAIL: TTY oracle reported failure and EXIT_CODE=1 despite that later bsshd-listening
line, consistent with the gate's TTY-oracle check running (and failing) before its
bsshd check is reached.
Rate context
- 1/10 boots in the
#690 A/B main arm (this boot, boot-3 of 10).
- 0/10 boots in the
#690 A/B slice-1 branch arm.
- Not seen in the slice-1 prove run (3/3 clean).
Attribution
This is a main red (not attributable to the slice-1 branch under test) and, per
R157, requires attribution rather than being folded silently into the slice-1 A/B
verdict.
Signature
Seen on origin/main at
bdb5be90(merge of PR #795, "fix/ttbr0-shadow-reconciliation"),production-profile aarch64 gate, during today's
#690A/B run.Where
docs/planning/green-program/aarch64-testing/serials/slice1/ab-690/main/boot-3-serial.txtdocs/planning/green-program/aarch64-testing/serials/slice1/ab-690/main/boot-3-gate.txtBoth are in-repo on
origin/mainas ofbdb5be90.STEP-1 reading
arm_cloexec_exec()inuserspace/programs/src/tty_oracle.rs(arm 14 of 14) opens afresh PTY pair, calls
fcntl(slave, F_SETFD, FD_CLOEXEC)vialibbreenix::io::fcntl_setfd, then forks and execs a marker copy of itself to proveclose_cloexec()retires the child's fork-cloned slave fd duringexec(). The failingline is the very first step: the
fcntl(F_SETFD)call itself returnedEAGAINbeforethe fork/exec ever ran.
On the kernel side,
sys_fcntl(kernel/src/syscall/handlers.rs:3858) resolves thecurrent process by first acquiring the process-manager lock via
crate::process::try_manager()(a try-lock). If that try-lock fails to acquire, thehandler returns
SyscallResult::Err(11)-- errnoEAGAIN-- before ever reaching theF_SETFDdispatch arm. The actualF_SETFDimplementation,FileDescriptorTable::set_fd_flags(kernel/src/ipc/fd.rs:630), can only fail withEBADF(bad fd) -- it has noEAGAINreturn path of its own. So thisEAGAINdid notcome from the fd-flags logic; it came from
try_manager()finding the process-managerlock contended at the moment
tty_oracleissued itsfcntlsyscall, i.e. a transientlock-contention failure in the fcntl syscall's process-lookup path, not a cloexec/PTY
defect.
Separately: bsshd reached "listening" in this same boot (
serial.txt:389,bsshd: listening on 0.0.0.0:2222), aftertty_oraclehad already exited(1) atserial.txt:325. The gate's own transcript (boot-3-gate.txt) reportsFAIL: TTY oracle reported failureandEXIT_CODE=1despite that later bsshd-listeningline, consistent with the gate's TTY-oracle check running (and failing) before its
bsshd check is reached.
Rate context
#690A/B main arm (this boot, boot-3 of 10).#690A/B slice-1 branch arm.Attribution
This is a main red (not attributable to the slice-1 branch under test) and, per
R157, requires attribution rather than being folded silently into the slice-1 A/B
verdict.