Read an INFO reply the way Redis writes it, and print the log when it fails

[marcos-mendez]

Found by the first build of this component, on the build host, in its own conf script:

FATAL [unit-redis conf]: no Redis answered INFO on [::1]:6379 after 30 tries

The server was up, listening on both loopback families, and answering.

Redis speaks CRLF

Every line of an INFO reply ends \r\n, redis-cli prints the reply as it came, and the check was anchored with a dollar. Measured in the chroot of the failed build:

redis-cli INFO server | grep tcp_port | od -c
t c p _ p o r t : 6 3 7 9 \r \n

grep -q "^tcp_port:6379$"                no match
tr -d '\r' | grep -qx "tcp_port:6379"    match

The reply now goes through tr in one function both the wait and the per address check call. The stub in tests/conf.bats answers in CRLF now, so every test in that file covers the real shape rather than a convenient one; one test says so by name and asserts both halves.

Two things the same failure showed about the script

• The log went with the directory. The check runs the server in a scratch directory and removes it on the way out, which took the server's own log with it: the build that failed could not be diagnosed from its own output, and the log had to be reproduced by hand in the tree fab left behind. The fatal path prints its last twenty lines first now, with a test.
• The message sent the reading the wrong way. "after 30 tries" belonged to the wait on [::1]; the check that failed had made one attempt against one address. Two facts, printed as two facts.

Nothing the image gets changes. version goes to 1.0.1 because the pin a recipe clones has to move.

Coverage

100 percent on all three measured files, 126 of 126 lines, 67 bats tests (was 123/123 over 65).

Test plan

• COVERAGE_THRESHOLD=100 tests/coverage.sh: 100/100/100
• The fix proved against the real redis-server 8.0.2 in the chroot of the failed build before this was written
• tests / coverage green here
• The build that failed, run again and green