Visibility of VCL source (Was: Re: [PATCH] expand includes)

Federico Schwindt fgsch at
Tue Jul 22 17:33:36 CEST 2014

When there are multiple VCLs loaded would they all be exposed via VSM?

I think kicking off a child to do the work only when necessary would be
better and you get the auth check bonus.

On Tue, Jul 22, 2014 at 10:08 AM, Poul-Henning Kamp <phk at>

> In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=
> rZ1iTfr5EKzrR9tFyi9Hw at>
> , Dag Haavi Finstad writes:
> >As discussed on the Stockholm VDD, here's a proposal for #1457.
> >[...]
> >The VCLs are output in the same order as they appear in the VCL
> >location/profiling table in the compiled VCL (the vcl->ref stuff used
> >in the VCL_trace records), so if someone wanted to do a VCL code
> >tracer thing, that should be possible.
> I'm not at all happy with the fact that we still dlopen() VCL's for
>  That exposes the master process in ways I don't like,
> even more so now we have VMODS which pull in strange libraries.
> One way to fix it is to accept that we cannot show the source
> unless the child process is running.  I can live with that.
> If that is not acceptable, we could fork a child of master to
> dlopen() the compiled VCL (we already do that for testing) and
> pull the source out of that.
> But all in all I prefer to make the child responsible, so that
> we don't dlopen() compiled VCL's unnecessarily.
> If we go that route, we can do as now, and only exposed it via
> VCL or we can expose the counters and VCL source via VSM to
> avoid the VCL overhead.
> The latter is probably best for interactive visuals, but does
> expose the VCL source without CLI auth check.  I'm not sure
> if that is OK.
> Input ?
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the varnish-dev mailing list