On Thu, Jan 14, 2021 at 12:13:17PM +0100, William Dauchy wrote: > On Thu, Jan 14, 2021 at 11:21 AM William Lallemand > <[email protected]> wrote: > > VTest is not really suited to test the process management, for example > > the tests doing a reload have timing issues because VTest is not able to > > know when HAProxy is ready. > > > > Could you share what you tried to do? I'm not sure what is the problem > > you are mentionning with -expectexit. > > here it is: > > varnishtest "strict-limits test" > > #REQUIRE_VERSION=2.1 > > feature ignore_unknown_macro > > server s1 { > rxreq > txresp > } -repeat 2 -start > > haproxy h1 -conf { > global > strict-limits > maxconn 1000000 > > defaults > mode http > timeout connect 1s > timeout client 1s > timeout server 1s > > frontend fe > bind "fd@${fe}" > default_backend be > > backend be > server s1 ${s1_addr}:${s1_port} > } -start -expectexit 42 > > # give it some time to start and detect failure > shell { > sleep 1 > } > > client c1 -connect ${h1_fe_sock} { > txreq -url "/" > } -run > > - first, the sleep 1 really depends of the process init time, like you > mentioned in your previous message, it is not possible to detect when > process should be ready. So it remains very ugly. > - the client triggers the `wait4` which is correctly ending with this error: > * h1 Expected exit: 0x2a signal: 0 core: 0 > ---- h1 Bad exit status: 0x0100 exit 0x1 signal 0 core 0 > > - if I switch to no strict-limits, the process won't exit by itself; > it does not trigger the `wait4` error, quite unclear why for now.
If I remember correctly the wait() is only done after a timeout of 10 seconds letting VTest run even if HAProxy exit immediatly. So I presume HAProxy is still present as a zombie process during this time. I don't know why it's done this way but this is a common problem I have when starting VTest with an invalid haproxy configuration. -- William Lallemand
