varnish-cache icon indicating copy to clipboard operation
varnish-cache copied to clipboard

Failing u00006 leaves varnishlog processes running

Open bsdphk opened this issue 4 years ago • 5 comments

Not sure if this is something varnishtest can do anything about (See also #2469) or if the test needs to be rethought.

bsdphk avatar Nov 18 '21 10:11 bsdphk

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?

dridi avatar Nov 19 '21 16:11 dridi

**** 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.

dridi avatar Nov 19 '21 16:11 dridi

This was addressed in d497ec099 and later discussed on the commit mailing list.

Summary:

  • the -A coverage becomes a no-op without the -w
    • should we fail a -A option in the absence of -w?
    • should we allow -w - for stdout?
      • is it already the case?
      • what about daemon mode?
      • restart-ability?

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.

dridi avatar Nov 22 '21 08:11 dridi

The varnishlog changes can be discussed in https://github.com/varnishcache/varnish-cache/pull/3744.

dridi avatar Nov 23 '21 14:11 dridi

Bugwash note: @bsdphk was against the idea of keeping track of daemons with platform-specific facilities like linux namespaces.

dridi avatar Nov 23 '21 14:11 dridi