mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-05 11:08:25 +00:00
Johnathan Corgan
25daa4de1a
The deb-install suite started fips-dns.service with no timeout. That unit is Type=oneshot with Requires=fips.service, so when the daemon cannot execute -- a broken package, a bad config, a missing capability -- systemd restarts it every five seconds for ever, the oneshot start job is never dispatched, and systemctl start never returns. The suite then produced no FAIL line, no Results line and no exit status at all. Observed at 21 minutes against a package whose binaries could not load. That is the whole class of fault this suite exists to find, so the suite stopped reporting at exactly the point it was most needed. It also matters beyond one test: a hang here blocks the local run that gates artifact publication. Queue that one unit rather than waiting on it, and wait for it to become active before reading /run/fips/dns-backend. RemainAfterExit=yes makes is-active a correct readiness test for the oneshot, and the wait carries a timeout and dumps the journal on failure, so the verdict lands on an assertion instead of on a stalled call. Keep every other start blocking, because the call returning is what synchronises the checks after it -- fips-gateway.service waits up to thirty seconds for fips0 in ExecStartPre, and a caller that does not wait races it. What those calls lacked was a bound, not the wait, so they get one. Bound the whole suite from ci-local.sh as a backstop, and say so explicitly when it fires: a timeout means no assertion was reached, which is not the same as an assertion failing. Verified by breaking what it guards. Against the released 0.5.0 package, whose binaries require a newer glibc than Debian 12 provides, the suite now reds in 36 seconds with the loader error in the journal dump. Against a working package it passes 38 checks across debian12 and ubuntu26, covering both resolver backends.