Failing u00006 leaves varnishlog processes running
Not sure if this is something varnishtest can do anything about (See also #2469) or if the test needs to be rethought.
That's because we start the leaking varnishlog as a daemon, so it exits the test's process group.
Workaround, lower the leak window:
--- bin/varnishtest/tests/u00006.vtc
+++ bin/varnishtest/tests/u00006.vtc
@@ -10,11 +10,6 @@ varnish v1 -vcl+backend {} -start
process p1 {
exec varnishlog -n ${v1_name} -g raw -k 3 -w ${tmpdir}/vlog -A
} -start
-shell {
- exec varnishlog -n ${v1_name} -D -P ${tmpdir}/vlog.pid \
- -w ${tmpdir}/vlog.bin -R 10/s \
- -i RespStatus -i ReqURL -i BereqURL
-}
shell -match "Usage: .*varnishlog <options>" \
"varnishlog -h"
@@ -124,6 +119,14 @@ shell {grep -q "0 CLI" ${tmpdir}/vlog}
shell -match "0 CLI[ ]+- Wr 200 [0-9]+ PONG" \
{varnishlog -n ${v1_name} -d -g raw -X "Wr 200 [0-9]+ [^P]"}
+shell {
+ exec varnishlog -n ${v1_name} -D -P ${tmpdir}/vlog.pid \
+ -w ${tmpdir}/vlog.bin -R 10/s \
+ -i RespStatus -i ReqURL -i BereqURL
+}
+
+delay 0.1
+
client c1 {
txreq -url /foo
rxresp
Maybe we could detect child processes daemonizing and keeping track of them per test process to act accordingly, timeout or not?
**** top shell_out| 0 Debug - "sockopt: Not setting unmodified SO_LINGER for a0=127.0.0.1:62816%00"
**** top shell_out| 0 Debug - "sockopt: Not setting unmodified SO_KEEPALIVE for a0=127.0.0.1:62816%00"
**** top shell_out| 0 Debug - "sockopt: Setting SO_SNDTIMEO for a0=127.0.0.1:62816%00"
**** top shell_status = 0x0000
** top === shell {grep -q "0 CLI" ${tmpdir}/vlog}
**** top shell_cmd|exec 2>&1 ; grep -q "0 CLI" /var/folders/rb/fsxkcbqj5gg0fr2_qqqgqsr80000gn/T//vtc.1639.253c85c4/vlog
**** dT 1.315
**** top shell_status = 0x0001
---- top shell_exit not as expected: got 0x0001 wanted 0x0000
That's why.
This was addressed in d497ec099 and later discussed on the commit mailing list.
Summary:
- the
-Acoverage becomes a no-op without the-w- should we fail a
-Aoption in the absence of-w? - should we allow
-w -for stdout?- is it already the case?
- what about daemon mode?
- restart-ability?
- should we fail a
Speaking of daemon mode, our own varnish_daemon() function is not exposed in libvarnishapi so we can change it at our leisure. The VUT API doesn't raise the noclose flag so we should probably treat -D -w - as an error in addition to -A without a -w, once we teach varnishlog -w to treat - as stdout. We could also have an internal way of telling the varnish_daemon() function to join the VTC job's process group instead of starting its own, just like we have a way to produce predictable pseudo-random numbers.
The varnishlog changes can be discussed in https://github.com/varnishcache/varnish-cache/pull/3744.
Bugwash note: @bsdphk was against the idea of keeping track of daemons with platform-specific facilities like linux namespaces.