[linuxnow]

On a Raspberry Pi 5, plugin-qualify-sync --system --isolated-only measured one plugin and read isolated.no-private-server for the next 151, exit 0.

Cause. Each step starts a private jackd with the same name. A pass is synchronous, so the process never reaped the jackd it had stopped. A jackd that had a client leaves its entry in the server table, and a zombie counts as alive, so the next start exited with server already active. Starting jackd under a shell that stays as its parent made the second start work on the Pi. The existing live test ran the step only once.

Fix.

• jackd runs under a shell that waits for it, so it is reaped when it ends. The adapter pass uses the same starter.
• completeIsolated runs a not-run step again and replaces it. Before this, the record kept not-run and no pass tried again, although isolatedPass says one does.

Tests. In the first commit, the new tests are red on CI with isolated.no-private-server and expected undefined to be isolated.

• Live: the step three times in a row on the fixture.
• Unit: a not-run step is retried and replaced, and a refused one is not.
• the pass moves each pin asserted that a second pass does nothing, which was the bug. It now expects the not-run step to run again.
• cpuPercent > 0 failed on CI once at 0, so that assertion is now >= 0.

Not proven yet: a whole pass on the Pi with this build. The device is measuring. It runs once this is released.

[linuxnow]

What I measured on the Pi 5 (jackd 1.9.22~dfsg-4, plugin-qualify 0.18.2, plugin-hostd 0.15.4), with spawnedIsolatedRunner() called in a loop from a small script. No sync and no records involved.

run	jackd started by	first step	second step
no client, four start/stop rounds of startPrivateJack	node, directly	up	up every time
SAFEDistortion, then ZamDelay	node, directly	isolated	not-run after 58 ms
same, SERVER_STOP_MS raised to 30000	node, directly	isolated	not-run after 57 ms
same, jackd on PATH is a script that does exec /usr/bin/jackd "$@" >> log 2>&1	same pid as node's child	isolated	not-run; log says 'omx-qualify-<pid>-128' server already active, Failed to open server
same, jackd on PATH is a script that runs it in the background and waits (below)	a bash child of node	isolated	isolated

The script that worked:

#!/bin/bash
/usr/bin/jackd "$@" >> log 2>&1 &
p=$!
trap "kill -TERM $p" TERM
wait $p; rc=$?; wait $p 2>/dev/null; exit $rc

What this shows:

• It takes a client on the first server to trigger it. With no client, restarts under the same name work.
• It is not the stop timeout: the wait was never used up, and 30 s changes nothing.
• /dev/shm holds none of the server's files after the stop, so removing them does not help. What is left is outside them, in JACK's server table.

I ran this working script only once, with two plugins, under bash. It differs from the wrapper in this PR in three ways: it runs under bash rather than sh (dash on Debian, whichever CI uses), it has no wait inside the trap, and its stdio goes to a file rather than being ignored. I have not tried the PR's wrapper on the Pi, because the device is measuring. So I can't say which difference matters on CI, or whether the Pi and CI differ at all.

A server name unique to each start would avoid the name clash, but as far as I remember JACK's server table has few slots, and an entry that looks alive holds one. I have not checked that. If a run needs it on the Pi, tell me: it can go in between two batches.