From df4dd406a98105e4c36a9472970e30ab6dcbb7ce Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 1 Sep 2026 09:40:45 +0200 Subject: [PATCH] A redirected log lags; do not diagnose a stall from it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Node block-buffers stdout to a file, so a run log can sit unchanged for minutes while the run is fine. Read that way twice today — the second time straight after fixing a real stall, which is the worst version of it, because a buffering artifact then reads as the fix having failed. The machines are the source of truth and answer immediately. Written down with the two commands that settle it. --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index 43809ba..67eba59 100644 --- a/README.md +++ b/README.md @@ -165,6 +165,19 @@ If it says the daemon is not reachable, the group grant postdates the shell. `ne but a heredoc into `newgrp` runs the suite as a child of a shell that then exits — start it with `setsid nohup … &` inside the heredoc, or the run dies with the shell that launched it. +**A redirected log lags, so do not diagnose a stall from it.** Node block-buffers stdout when it +is a file rather than a terminal, so `> run.log` can sit unchanged for minutes while the run is +working normally. On 2026-09-01 that was read as a stall twice, once after a real stall had just +been fixed — the most expensive kind of false signal, because it argues the fix did not work. Ask +the machines instead: + +```sh +incus list -c ns +incus exec -registry -- systemctl is-active docker +``` + +*"I cannot see progress" is not evidence of no progress.* + ## Measured on a workstation | | one machine | two machines | two machines + a router |