agmsg_sync_autostart returns silently when mktemp fails, and the #765 warning is gone with it.
Landed in #775 (5609129e). Read from the tree, not reproduced on a live machine — marked below.
What the code does
scripts/lib/sync-autostart.sh, inside the per-team loop:
tmp="$(mktemp 2>/dev/null)" || tmp=""
[ -n "$tmp" ] || return 0
Three things happen at once on that path, and none of them is announced:
- No engine is started.
- Nothing is printed — not the
started, slow, or failed block, because all three are built after the loop and this leaves before any of them gets a line.
- It is
return, not continue, so the remaining teams are abandoned too, without being attempted.
Why that costs something it did not cost before
#761/#765 put a warning in session-start.sh naming every connected team with no
engine, with a runnable remedy per team. #775 replaced that block with this call,
and says so deliberately — from tests/test_delivery.bats:
What #765 built is not discarded: its warning, its wording and its runnable
remedy are exactly what remains when the start FAILS, and that is the case
driven below.
That is the intended contract, and it holds for the failure the test drives — a
sync start that runs and refuses. It does not hold here: mktemp failing is
also a start that did not happen, and on that path the operator is told nothing
at all. Before #775 the same machine printed the #765 block.
So the state this is all about — connected, not syncing, and the person cannot
tell — is reachable again, by a different door.
What makes it reachable
Not a missing binary. mktemp is present essentially everywhere agmsg runs.
It fails at runtime: TMPDIR unset to somewhere that does not exist,
TMPDIR not writable, or the filesystem full. A full temp filesystem is the
uncomfortable one, because the same file also leaves two temp files behind on
purpose whenever a start outruns its budget:
the child is NOT killed — see the header — so its two temp files are left for
it to finish writing into.
That is a documented, accepted trade (and reasonable on its own). It does mean
the condition that silences the warning is one the feature can contribute to.
Suggested direction
Treat it as what it is — a start that failed for a nameable reason — rather than
as nothing:
tmp="$(mktemp 2>/dev/null)" || tmp=""
if [ -z "$tmp" ]; then
failed="$failed$team could not create a temporary file (is the temp filesystem full or unwritable?)"$'\n'
continue
fi
continue rather than return so one bad team does not silence the rest, and
the failed block then prints the existing bash … sync start <team> remedy,
which is exactly what #765 promised and what the quoted comment says survives.
Family
Same shape as #802 (a failure became an ordinary value with nothing recorded)
and #804 (a mktemp dependency where none was expected). Filing separately
because the thing lost here is a user-visible warning another issue was opened
to create, which neither of those covers.
agmsg_sync_autostartreturns silently whenmktempfails, and the #765 warning is gone with it.Landed in #775 (
5609129e). Read from the tree, not reproduced on a live machine — marked below.What the code does
scripts/lib/sync-autostart.sh, inside the per-team loop:Three things happen at once on that path, and none of them is announced:
started,slow, orfailedblock, because all three are built after the loop and this leaves before any of them gets a line.return, notcontinue, so the remaining teams are abandoned too, without being attempted.Why that costs something it did not cost before
#761/#765 put a warning in
session-start.shnaming every connected team with noengine, with a runnable remedy per team. #775 replaced that block with this call,
and says so deliberately — from
tests/test_delivery.bats:That is the intended contract, and it holds for the failure the test drives — a
sync startthat runs and refuses. It does not hold here:mktempfailing isalso a start that did not happen, and on that path the operator is told nothing
at all. Before #775 the same machine printed the #765 block.
So the state this is all about — connected, not syncing, and the person cannot
tell — is reachable again, by a different door.
What makes it reachable
Not a missing binary.
mktempis present essentially everywhere agmsg runs.It fails at runtime:
TMPDIRunset to somewhere that does not exist,TMPDIRnot writable, or the filesystem full. A full temp filesystem is theuncomfortable one, because the same file also leaves two temp files behind on
purpose whenever a start outruns its budget:
That is a documented, accepted trade (and reasonable on its own). It does mean
the condition that silences the warning is one the feature can contribute to.
Suggested direction
Treat it as what it is — a start that failed for a nameable reason — rather than
as nothing:
continuerather thanreturnso one bad team does not silence the rest, andthe
failedblock then prints the existingbash … sync start <team>remedy,which is exactly what #765 promised and what the quoted comment says survives.
Family
Same shape as #802 (a failure became an ordinary value with nothing recorded)
and #804 (a
mktempdependency where none was expected). Filing separatelybecause the thing lost here is a user-visible warning another issue was opened
to create, which neither of those covers.