When running fmt_pkt in parallel, before the patch, there could be
several attempts to start scapy-server. Using flock on a test case
specific file should guarantee that only one of the subshells will
actually be able to start a daemon, which is designed to be a singleton.
Now that start_scapy_server doesn't necessarily start a server (only the
first lucky subshell will do), wait for server socket file before
proceeding with ovs-appctl call.
Signed-off-by: Ihar Hrachyshka <ihrac...@redhat.com>
Acked-by: Mark Michelson <mmich...@redhat.com>
---
tests/ovn-macros.at | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tests/ovn-macros.at b/tests/ovn-macros.at
index 21c314c7c..633ef05f8 100644
--- a/tests/ovn-macros.at
+++ b/tests/ovn-macros.at
@@ -876,6 +876,7 @@ fmt_pkt() {
if [[ ! -S $ctlfile ]]; then
start_scapy_server
fi
+ while [[ ! -S $ctlfile ]]; do sleep 0.1; done
ovs-appctl -t $ctlfile payload "$1"
}
@@ -883,10 +884,11 @@ start_scapy_server() {
pidfile=$ovs_base/scapy.pid
ctlfile=$ovs_base/scapy.ctl
logfile=$ovs_base/scapy.log
+ lockfile=$ovs_base/scapy.lock
- "$top_srcdir"/tests/scapy-server.py \
- --pidfile=$pidfile --unixctl=$ctlfile --log-file=$logfile --detach
- on_exit "test -e \"$pidfile\" && ovs-appctl -t $ctlfile exit"
+ flock -n $lockfile "$top_srcdir"/tests/scapy-server.py \
+ --pidfile=$pidfile --unixctl=$ctlfile --log-file=$logfile --detach \
+ && on_exit "test -e \"$pidfile\" && ovs-appctl -t $ctlfile exit"
}
sleep_sb() {
--
2.41.0
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
