Networking test: fix silent breakage

Wow did I screw up. #10982 introduced (at my suggestion) a
new wait_for_port() helper, with the goal of eliminating a
race condition. It didn't work.

First: wait_for_port() tests by connecting to the port, which
is a Bad Idea when you have a one-shot server that exits upon
the first connection closing. We should've caught that, but:

Second: I wrote wait_for_port() for a non-BATS test framework,
and used the conventional file descriptor 3. BATS uses fd3
for internal control. Overriding that made the test silently
just disappear, no "not ok" message, no warnings, nothing
except vanishing into the ether.

Third: this was caught by my log-colorizer script, which
loudly yelled "WARNING: expected 234" (tests) at the
bottom of the log. Unfortunately, since this wasn't
my PR, I didn't actually look at the test logs.

Solution: we can't use wait_for_port() in the network port
test. Use wait_for_output() instead, triggering on the
'listening' message emitted by netcat in the container.

Also: fix wait_for_port() to use fd5 instead of 3. Although
no code currently uses wait_for_port() as of this PR, it's
a useful helper that we may want to keep.

Signed-off-by: Ed Santiago <santiago@redhat.com>

0 files changed, 0 insertions, 0 deletions