varnish tracking tkt

[eyberg]

when ran in foreground mode varnish still wants to fork - not sure what it actually is doing as I haven't looked

 ops run -d -c config.json -p 8080 varnishd
cat config.json
{
  "Dirs": ["usr"],
  "Args": ["./varnishd", "-F", "-b", ":8080"]
}

1 clone: flags 1200011, child_stack 0x0000000000000000, ptid 0x0000000000000000, ctid 0x000000019679b450, newtls 0
1 attempted to fork by passing null child stack, aborting.
1 direct return: -38, rsp 0x7ff3ba60

also - I've noticed some behavior I saw in clickchouse where tens of thousands of fds seem to be opened and closed

fchown needs to be stubbed

#1193

[francescolavra]

It looks like there is no way to prevent varnishd from trying to fork: it forks (regardless of the -F option) whenever it wants to run the VCL compiler, by calling the mgt_vcl_startup() function. The value of the -b command line option that identifies the backend server is translated into a VCL statement, which then needs to be compiled, and that's where it fails.
Regarding the tens of thousands of file descriptors, it actually doesn't open them, it just tries to close them: at https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishd/mgt/mgt_main.c there is this comment: "Start out by closing all unwanted file descriptors we might have inherited from sloppy process control daemons", and since VSUB_closefrom() at https://github.com/varnishcache/varnish-cache/blob/master/lib/libvarnish/vsub.c tries to get all open file descriptors from the /proc/self/fd directory (which we don't have) and failing that falls back to getting the maximum file descriptor number via sysconf(_SC_OPEN_MAX) (which in Nanos returns 65536), the application ends up calling close() on all file descriptors from 65536 to 3.