Files
fips/testing/dns-resolver
Johnathan Corgan 856055db76 Stop the dns-resolver harness discarding the cause of its own failures
Build and container-start output went to /dev/null, so a failing
scenario printed that it had failed and nothing about why. The
ubuntu:26.04 e2e failure has been undiagnosable since July for exactly
that reason.

Output is now captured and emitted only when the command fails, naming
which command it was, so a passing run stays as quiet as before. The
systemd readiness wait, which is the check that actually times out, dumps
the container state, the failed units and the journal when it gives up.

This also fixes a defect the change uncovered. The script runs under
pipefail, and systemctl is-system-running exits non-zero when the system
is degraded, so the pipeline testing for 'running|degraded' failed even
when grep matched. The degraded branch was dead, and since systemd inside
a container always settles at degraded, every scenario burned the full
30-second boot timeout and emitted a spurious warning about a container
that had booted correctly. The readiness poll now matches on the captured
state instead of piping into grep.

The original ubuntu:26.04 failure does not reproduce on this host, so
that half stays open. What changes is that the next occurrence will say
why.
2026-08-22 09:09:28 +01:00
..