2 Commits

Author	SHA1	Message	Date
Krzysztof kuhy Rudnicki	0a69d18390	check_and_enable_services: 100% coverage via a redirectable path prefix ... Follow-up to 9085a4e5, which recorded services_units.sh at 84.51% because its remaining branches sit behind [[ -f /etc/systemd/system/*.service ]] -- absolute root-owned paths that exist on this machine, so the else-branch never runs and no PATH shim can redirect it. All 87 such paths across the seven check libs now go through $SYSROOT, read from SERVICES_ROOT. The prefix is deliberately NOT defaulted. Three commands in hosts_fix_resolved run outside `run` and so are not stopped by --dry-run (chattr -i on resolved.conf.d, find -delete over its *.conf, and an append to resolved.conf); with an empty default, a test that forgot to set SERVICES_ROOT would really delete this machine's resolved.conf drop-ins. Unset is therefore a hard error and only an explicitly empty value means the real filesystem. The harness now owns PATH outright: $FAKE_BIN for shims and staged fake apps, $REAL_BIN for a curated set of symlinks to genuine coreutils. The machine's /usr/bin is deliberately absent -- a really-installed discord and chromium otherwise make the "no target apps present" branches untestable, which is exactly what happened until these tests caught it. Coverage, measured against run_all.sh because two test files jointly cover services_common.sh after the 250-cap split: common 55/55, report 27/27, units 72/72 (was 84.51%), wrappers 100/100, apps 66/66, browser 79/79 -- seven libs at 100%. services_hosts.sh reads 86.05% and services_hosts_fix.sh 97.30%, and those 14 lines are a kcov attribution artifact rather than a gap. Falsified rather than assumed: the suite prints "51 passed, 0 failed" when run under kcov, so no group is skipped, and every supposedly-uncovered line is an issues+=("...") whose string can only reach stdout through the print loop below it -- with a passing assertion matching that exact string. Two falsification checks, both re-run after the rewrite: `--status --dry-run` as root stays byte-identical to rev 6691cb26 modulo the Date: line, and the sha256sums of /etc/hosts, /etc/nsswitch.conf and /etc/systemd/resolved.conf plus the contents of resolved.conf.d are unchanged across a full suite run. The second one is what makes a missed prefix site detectable instead of a matter of inspection: the repair paths really do write. 220 assertions across 8 test files. Also fixes a bug in the harness's own lsattr shim, where printf with a leading-dash format string parsed the dashes as options and silently produced nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F3PzGc75gBcdxP3PkHXGcV	2026-08-21 14:08:11 +02:00
Krzysztof kuhy Rudnicki	9085a4e508	check_and_enable_services: split into lib/ under the 250-line cap ... 1225 lines down to 202, with the 21 functions moved into eight sourced libraries grouped by subject. The entry script now holds only the configuration, the argument parsing and the order the checks run in. check_hosts was the one function that could not move verbatim: at 260 lines it would have stayed over the cap on its own, so its repair half is now hosts_fix_nsswitch / hosts_fix_resolved / hosts_repair_all in services_hosts_fix.sh. Repair order is preserved (resolver config, then the hosts file, then the guard-lib migration), and hosts_repair_all returns non-zero under --dry-run so a dry run can no longer promote a status to "ok" on the strength of repairs that never happened. SERVICE_STATUS was a write-only global across five libs, which is a real SC2034 rather than noise: the pre-commit hook runs shellcheck with no -x and genuinely cannot see the one reader. It now goes through set_service_status / get_service_status, which also rejects a duplicate write — each check owns exactly one summary row, so a second write means two checks are fighting over it. No suppression was added anywhere. Proof the behaviour is unchanged: `--status --dry-run` run as root against this machine is byte-identical to the same command from a worktree at the pre-split revision, modulo the Date: line. verify_shell_split.sh reports check_hosts as the single expected difference; the other 20 functions hash identically. 72 assertions across three test files pass, with 100% line coverage on services_common.sh (54/54) and services_report.sh (27/27). services_units.sh measures 84.51% (60/71). The 11 uncovered lines are the else-branches of [[ -f /etc/systemd/system/*.service ]] and [[ -f /usr/local/bin/*.sh ]] probes — absolute root-owned paths that exist on this machine and that no PATH shim can redirect. Reaching them needs a root-prefix rewrite of live enforcement logic, which is not a line-count fix and would forfeit the verbatim-move proof for everything else. Found while testing, deliberately NOT fixed here: in all three unit checks the is-active branch assigns status="warning" unconditionally, overwriting the status="error" the is-enabled branch set just above it. A timer that is both disabled and inactive therefore never gets repaired, because report_and_fix only repairs on "error". It is identical in the pre-split file, so this split neither caused nor hides it. The tests pin the current behaviour and name it; fixing it changes enforcement and earns its own commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F3PzGc75gBcdxP3PkHXGcV	2026-08-21 13:47:05 +02:00