health check path doesn't change after VCL reload (2.0.6)

[Ken Brownfield]

I also recently confirmed that the backend specs aren't reset with a VCL reload.  We had a backend timeout that was too short, but we had to do a hard restart of all instances to pick up the change.  Not the end of the world; worst case this might belong on the wiki.

The code to modify or respawn backend threads might be somewhat complicated, but it's probably worth it, IMHO.
-- 
Ken

On Feb 24, 2010, at 1:25 PM, John Norman wrote:

> No, only the former / old path.
> 
> I'm not super-troubled right now because a Varnish restart did pick up the new path (but at the cost of my cache) -- but I'm a bit worried about the next time I have to change it.
> 
> I will be changing the probe interval soon, so that will give me a chance to reproduce the problem, if it even exists.
> 
> As a bit of background:
> 
> I automate the VCL update to multiple servers, when/if the VCL file has changed.
> 
> Before the update, I also remove all of the inactive/old VCL's that are sitting there.
> 
> Then I add the new one and "use" it.
> 
> When I observed in my backend logs the probes going to the old URLs, I did check the "active" VCL on all systems, and they all showed the new path.
> 
> In any case, I will try to reproduce and will send the results.
> 
> One last thing: During the restart on one system, I observed the issue reported here: http://zarathustrashallspeak.com/2009/11/28/varnish-startup-issue/
> 
> John
> 
> On Wed, Feb 24, 2010 at 4:18 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7 at mail.gmail.com>, John N
> orman writes:
> 
> >Still, the VCL indicated as "active" had a different path for the health
> >check.
> 
> Hopefully both got probed ?
> 
> --
> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20100728/e23a9249/attachment-0003.html>