Frank.,
I am not sure what happened here. My initial triage was incorrect, or the
universe has moved (aka git pull was run by a cron pixie) since I did that.
I've just gone back to the failing machine(s) ...
For 2 of them, the current 667 version passes now.
For another, I've had to modify the test to capture more diagnostics, which
reveals:
kenj@vm07:~/src/pcp/qa$ cat 667.full
=== 1. pcp2graphite one-shot pickle ===
--- pcpgraphite stderr --
cannot send message to localhost:2004, Connection refused, continuing
cannot send message to localhost:2004, Connection refused, continuing
cannot send message to localhost:2004, Connection refused, continuing
--- nc stdout --
=== 2. pcp2graphite text, 2-second aligned ===
--- pcpgraphite stderr --
cannot send message to localhost:2003, Connection refused, continuing
cannot send message to localhost:2003, Connection refused, continuing
--- nc stdout --
This is on vm07 PCP 3.10.2 x86_64 Debian 6.0.10.
A bit more digging and it appears nc ... localhost port is not the same as
nc ... -p port localhost on this system. The test uses the former, the
latter gets much closer to the expected output. And this change works on at
least one other machine.
Back to vm07, and the last part of the failure is that the second nc
execution appears to produce only a single line of output ... the -k option
to nc here is described as "-k set keepalive option on socket" compared to
"-k Keep inbound sockets open for multiple connects" on a system where the
test passes.
Moving on to the second failing system (vm02 PCP 3.10.2 i686 openSUSE 12.1)
my -p port change does not work ... nc: cannot use -p and -l
So the prognosis for getting a working recipe using nc across all platforms
seems very poor.
And neither of the failing machines has socat installed by default.
Time for a bit more head scratching.
|