summaryrefslogtreecommitdiff
path: root/datapath-windows/ovsext/Stt.c
diff options
context:
space:
mode:
authorPaul Boca <pboca@cloudbasesolutions.com>2016-06-24 16:51:49 +0000
committerGurucharan Shetty <guru@ovn.org>2016-06-27 13:43:17 -0700
commitbcbc886ee7fc5725afac7c8cfc56fc3b595b91fb (patch)
treebc15bc43d726ea305a203b1d71da79b6a324ce96 /datapath-windows/ovsext/Stt.c
parent13a1d366d99910e0c96c74aed472157a2a0f68b1 (diff)
downloadopenvswitch-bcbc886ee7fc5725afac7c8cfc56fc3b595b91fb.tar.gz
tests: Fixed ovsdb-monitor tests.
Redirect ovsdb-client stderr to /dev/null. This fixes the series of tests that use OVSDB_CHECK_MONITOR macro. The theory behind the fix was explained by Ben Pfaff as follows: "I suspect I understand what's happening here. To execute the following command, Autotest internally redirects stdout and stderr to files named "stdout" and "stderr": > ./ovsdb-monitor.at:47: ovsdb-client -vjsonrpc \ --pidfile="`pwd`"/client-pid -d json monitor --format=csv \ unix:socket ordinals ordinals > output & > stderr: > stdout: Ordinarily, after the command exits it would close the file, but & means that it holds the file open. While the next few ovsdb-client commands run, it queues up some output in stdio buffers but doesn't bother to actually flush it[*]. [*] There's either a hole in my theory here or Windows is not fully ANSI C conformant since ANSI C says that "As initially opened, the standard error stream is not fully buffered; ..." which means that it'd probably be line buffered, so that each line of the log is flushed separately. On Unix-like OSes, the following Autotest commands don't really care about this open file, since the OS will happily delete and replace the "stderr" file and allow the previous file with that name to remain open. On Windows, the OS won't permit that, so I guess the shell is actually just opening the existing file. Later, "ovs-appctl --target=`pwd`/unixctl exit" causes ovsdb-server to exit. It flushes its accumulated stderr buffer to the OS, and therefore it shows up in the "stderr" output as part of ovs-appctl's output since ovs-appctl and ovsdb-server both had their output sent to the same file. Probably, adding 2>/dev/null to the ovsdb-server command would solve the problem. To get better output for debugging failures, also add --log-file and AT_CAPTURE_FILE([ovsdb-server.log])." Signed-off-by: Paul-Daniel Boca <pboca@cloudbasesolutions.com> Acked-by: Lance Richardson <lrichard@redhat.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Diffstat (limited to 'datapath-windows/ovsext/Stt.c')
0 files changed, 0 insertions, 0 deletions