[ovs-git] [openvswitch/ovs] bcbc88: tests: Fixed ovsdb-monitor tests.

GitHub noreply at github.com
Mon Jun 27 20:45:53 UTC 2016

  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: bcbc886ee7fc5725afac7c8cfc56fc3b595b91fb
  Author: Paul Boca <pboca at cloudbasesolutions.com>
  Date:   2016-06-27 (Mon, 27 Jun 2016)

  Changed paths:
    M tests/ovsdb-monitor.at

  Log Message:
  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 at cloudbasesolutions.com>
Acked-by: Lance Richardson <lrichard at redhat.com>
Signed-off-by: Gurucharan Shetty <guru at ovn.org>

More information about the git mailing list