mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-05-30 09:47:00 -04:00
bc63ea82f2
The OpenBSD job runs inside a nested VM. At -j8 the --use-tcp run starts many concurrent loopback daemons, and under that resource pressure the daemon connection handshake occasionally loses a timing race and one test hangs to the 300s runner timeout. It is an environment artifact, not an rsync defect: the daemon handshake writes-then-reads with unbuffered early I/O (no flush/mutual-wait deadlock), the indefinite wait is the documented no-timeout daemon behaviour, and it does not reproduce off OpenBSD even with the full suite pinned to a single CPU at -j8. Drop just this job's --use-tcp parallelism to -j2 so the nested VM stops over-subscribing; the pipe `make check` and every other platform are unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>