When vtest starts haproxy process, it loops until the moment, when haproxy
pidfile is created. When pidfile is created, vtest considers that haproxy
process is ready and it starts to perform test commands, in particular, it
connects to CLI. It's not very reliable approach to base the check of the
process readiness on the PID file. After master-worker architecture
refactoring pidfile is created in the early init stage, but master and worker
are not yet finished its initialization routines. So, all mcli tests and some
tests where we sent commands to CLI start to fail regularly.
In vtest at the moment there is no any other approach to check that the
process is really ready. So let's add a delay 0.1s before connecting to CLI in
all mcli tests and in acl_cli_spaces test.
} -run
haproxy h1 -cli {
+ delay 0.1
send "add acl ${testdir}/agents.acl Mon\\ User\\ Agent\\;"
expect ~ .*
haproxy h1 -cli {
+ delay 0.1
send "del acl ${testdir}/agents.acl Mon\\ User\\ Agent\\;"
expect ~ .*
# Try it with the master CLI
haproxy h1 -mcli {
+ delay 0.1
send "@1 add acl ${testdir}/agents.acl Mon\\ User\\ Agent\\;;@1 show acl ${testdir}/agents.acl"
expect ~ ".*Mon User Agent;.*"
}
} -start
haproxy h1 -mcli {
+ delay 0.1
send "@1; expert-mode on; debug dev log Victory"
expect ~ ".*"
} -wait
} -start
haproxy h1 -mcli {
+ delay 0.1
send "@1 show info"
expect ~ ".*\nProcess_num: 1\n.*"
} -wait
} -start
haproxy h1 -mcli {
+ delay 0.1
send "show proc"
expect ~ ".*foo.*\n.*bar.*\n"
} -wait