From varnish-bugs at varnish-cache.org Mon Nov 5 10:26:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 10:26:45 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <057.b82a7078386ae00f4359284f7cf9c313@varnish-cache.org> #1021: varnishtop -1 takes a long time to run ------------------------+--------------------- Reporter: yves | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: varnishlog | ------------------------+--------------------- Comment (by daghf): I did some testing for this, and it's not an api issue. I was able to reproduce this by first running siege in benchmark mode for a few minutes to build up a sizeable -d backlog of approx 2.5M vsl records, of which around 15% of the records were unique. I'm guessing these numbers are not entirely atypical for a live varnish server. Simple profiling using valgrind uncovered that around 99% is spent in accumulate(). Looking at the code the frequency table is built by keeping a vtailq of known unique records - this list is then scanned for every subsequent log record to see if it has already been encountered. When number of -d records is in the millions, this gets costly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 5 10:47:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 10:47:54 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <057.0531093e7a9df6987a742b647bf44ba7@varnish-cache.org> #1021: varnishtop -1 takes a long time to run ------------------------+--------------------- Reporter: yves | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: varnishlog | ------------------------+--------------------- Comment (by phk): That sounds like the rather simpleminded algorithms in varnishtop needs to be improved. It's a good and isolated task for somebody to work on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 5 11:23:11 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 11:23:11 -0000 Subject: [Varnish] #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 In-Reply-To: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> References: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> Message-ID: <062.0f243b36cbfb0b366bc181f03891c2e2@varnish-cache.org> #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 -------------------------+---------------------- Reporter: webmaster | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: critical | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: No response from submitter, closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 5 11:46:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 11:46:53 -0000 Subject: [Varnish] #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 In-Reply-To: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> References: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> Message-ID: <061.65d5dee364ddef8382c1a9d47144e560@varnish-cache.org> #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 ----------------------+----------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by kristian): Still failing using your vtc test program, though pretty consistently: {{{ *** v1 0.4 debug| Child (16548) Panic message: Assert error in VRT_IP_string(), cache/cache_vrt.c line 330:\n *** v1 0.4 debug| Condition((p = WS_Alloc(req->http->ws, len)) != 0) not true.\n *** v1 0.4 debug| thread = (cache-worker)\n *** v1 0.4 debug| ident = Linux,2.6.38-16-generic- pae,i686,-sfile,-smalloc,-hcritbit,epoll\n *** v1 0.4 debug| Backtrace:\n *** v1 0.4 debug| 0x8074e72: MPL_AssertSane+432\n *** v1 0.4 debug| 0x8083d9d: VRT_IP_string+18d\n *** v1 0.4 debug| 0xb7732c40: _end+af6664c8\n *** v1 0.4 debug| 0x80816df: VCL_recv_method+8f\n *** v1 0.4 debug| 0x80793d0: CNT_Request+a50\n *** v1 0.4 debug| 0x807173c: HTTP1_Session+47c\n *** v1 0.4 debug| 0x807cea4: RFC2616_Do_Cond+174\n *** v1 0.4 debug| 0x807e3c6: SES_pool_accept_task+1a6\n *** v1 0.4 debug| 0x8077579: Pool_Work_Thread+e9\n *** v1 0.4 debug| 0x808ac80: WRK_SumStat+130\n *** v1 0.4 debug| req = 0xad809018 {\n *** v1 0.4 debug| sp = 0xad801218, vxid = 1073742830, step = R_STP_RECV,\n *** v1 0.4 debug| handling = deliver,\n *** v1 0.4 debug| restarts = 0, esi_level = 0\n *** v1 0.4 debug| sp = 0xad801218 {\n *** v1 0.4 debug| fd = 13, vxid = 1000,\n *** v1 0.4 debug| client = 127.0.0.1 44150,\n *** v1 0.4 debug| step = S_STP_WORKING,\n *** v1 0.4 debug| },\n *** v1 0.4 debug| worker = 0xad97e1ac {\n *** v1 0.4 debug| ws = 0xad97e348 { \n *** v1 0.4 debug| id = "wrk",\n *** v1 0.4 debug| {s,f,r,e} = {0xad97d980,0xad97d980,(nil),+2048},\n *** v1 0.4 debug| },\n *** v1 0.4 debug| },\n *** v1 0.4 debug| ws = 0xad80910c { overflow\n *** v1 0.4 debug| id = "req",\n *** v1 0.4 debug| {s,f,r,e} = {0xad80a0ac,+12140,(nil),+12140},\n *** v1 0.4 debug| },\n *** v1 0.4 debug| http[req] = {\n *** v1 0.4 debug| ws = 0xad80910c[req]\n *** v1 0.4 debug| "GET",\n *** v1 0.4 debug| "/",\n *** v1 0.4 debug| "HTTP/1.1",\n *** v1 0.4 debug| "Host: localhost",\n *** v1 0.4 debug| },\n *** v1 0.4 debug| vcl = {\n *** v1 0.4 debug| srcname = {\n *** v1 0.4 debug| "input",\n *** v1 0.4 debug| "Default",\n *** v1 0.4 debug| },\n *** v1 0.4 debug| },\n *** v1 0.4 debug| },\n *** v1 0.4 debug| \n *** v1 0.4 debug| \n *** v1 0.5 debug| Child cleanup complete\n }}} This is on my 32-bit laptop, mind you... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 5 15:23:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 15:23:53 -0000 Subject: [Varnish] #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 In-Reply-To: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> References: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> Message-ID: <061.f44834f3e78060d6a7305df374ed97d4@varnish-cache.org> #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 ----------------------+----------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by Poul-Henning Kamp ): In [1a02024a9ece62d55d40deebd971e485775c5d9d]: {{{ #!CommitTicketReference repository="" revision="1a02024a9ece62d55d40deebd971e485775c5d9d" Increase the 'client_workspace' for 32bit machines to be twice the size of the 'http_req_size' so that we don't run out of WS in case of client pipelining. Fixes #1185 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 5 15:23:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Nov 2012 15:23:55 -0000 Subject: [Varnish] #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 In-Reply-To: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> References: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> Message-ID: <061.f7fb2976ed8a290ba6f15ef49d48164d@varnish-cache.org> #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 ----------------------+----------------------- Reporter: kristian | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [1a02024a9ece62d55d40deebd971e485775c5d9d]) Increase the 'client_workspace' for 32bit machines to be twice the size of the 'http_req_size' so that we don't run out of WS in case of client pipelining. Fixes #1185 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 7 13:56:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Nov 2012 13:56:27 -0000 Subject: [Varnish] #1226: Missing exit in varnishncsa init script Message-ID: <064.41e1b3c95efa7ff8c2f7986821b0d8d4@varnish-cache.org> #1226: Missing exit in varnishncsa init script ------------------------------+------------------------- Reporter: ghislain.seguy@? | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.3 | Severity: normal Keywords: | ------------------------------+------------------------- Hello, In the init script varnishncsa in the function that gives the status, if the daemon is not running varnishncsa, the return is 0. This is different from varnishd or return is the function status_of_proc. It would, in my opinion, add to the line 77 an exit $? I encountered this behavior when installing varnish using puppet. Ghislain Seguy. varnishd (varnish-3.0.3 revision 9e6a70f) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 7 20:29:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Nov 2012 20:29:45 -0000 Subject: [Varnish] #1227: Documentation of .initial default is wrong. Message-ID: <047.c6dfc3bcd2422ddc524af5f7feb99a76@varnish-cache.org> #1227: Documentation of .initial default is wrong. -----------------------+--------------------------- Reporter: perplexes | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------+--------------------------- In: [https://www.varnish- cache.org/trac/changeset/2d29ee8a53ea378e115512f4f53b74328707148b] it says that the .initial is set to .threshold by default, but in the source: [https://www.varnish- cache.org/trac/browser/bin/varnishd/cache/cache_backend_poll.c#L465] .initial is set to .threshold - 1, meaning that all backends start off as sick, and require one health check to become healthy. I have a pull-request on Github with this reflected in the documentation: [https://github.com/varnish/Varnish-Cache/pull/14], also available as a patch here: [https://gist.github.com/4034198]. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 8 06:03:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Nov 2012 06:03:29 -0000 Subject: [Varnish] #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check In-Reply-To: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> References: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> Message-ID: <072.75f028d6234b0e1cf01ce5f774dd1c2d@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+--------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: stream Gzip | -------------------------+--------------------- Comment (by jinjian.1@?): we just upgraded to varnish 3.0.3, still have such gzip error. backend we used nginx. Is there any updage. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 8 15:01:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Nov 2012 15:01:05 -0000 Subject: [Varnish] #1177: Child will not start on Solaris died signal=10 (core dumped) In-Reply-To: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> References: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> Message-ID: <059.2584630b3f739b19dda1fa81a5db8573@varnish-cache.org> #1177: Child will not start on Solaris died signal=10 (core dumped) --------------------------+-------------------- Reporter: karnak | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: 3.0.2 Severity: normal | Resolution: Keywords: Solaris | --------------------------+-------------------- Comment (by slink): Replying to [comment:4 hieubkav]: I am not actively pursuing this at the moment, we (UPLEX) do not currently have a sponsor to work on this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 8 15:02:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Nov 2012 15:02:53 -0000 Subject: [Varnish] #1177: Varnish does not yet run on SPARC - would need to respect strict memory alignment requirements (was: Child will not start on Solaris died signal=10 (core dumped)) In-Reply-To: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> References: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> Message-ID: <059.4f12e3584e19cedca2b2d792599e9c3c@varnish-cache.org> #1177: Varnish does not yet run on SPARC - would need to respect strict memory alignment requirements --------------------------+-------------------- Reporter: karnak | Owner: slink Type: enhancement | Status: new Priority: normal | Milestone: Component: port:solaris | Version: 3.0.2 Severity: normal | Resolution: Keywords: Solaris | --------------------------+-------------------- Changes (by slink): * type: defect => enhancement -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 9 10:33:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Nov 2012 10:33:41 -0000 Subject: [Varnish] #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash Message-ID: <046.71f481921ab359437f010a9058d2a66e@varnish-cache.org> #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Keywords: ----------------------+------------------- Reading req.backend.healthy in vcl_delivery, when a backend is unavailable, makes Varnish assert. Given the following VCL: {{{ # non-existing backend backend default { .host="127.0.0.1"; .port="12345"; } sub vcl_deliver { set resp.http.x-foo = req.backend.healthy; } }}} Produces the following assert on any request: {{{ Child (15080) Panic message: Assert error in VRT_r_req_backend_healthy(), cache_vrt_var.c line 539: Condition((sp->director) != NULL) not true. }}} Full backtrace added as an attachment. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:15:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:15:00 -0000 Subject: [Varnish] #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash In-Reply-To: <046.71f481921ab359437f010a9058d2a66e@varnish-cache.org> References: <046.71f481921ab359437f010a9058d2a66e@varnish-cache.org> Message-ID: <061.680e29e51e9a379e129faae5c6a8a90d@varnish-cache.org> #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [7db894f93330eed1da99336f69a3073a9629eeab]: {{{ #!CommitTicketReference repository="" revision="7db894f93330eed1da99336f69a3073a9629eeab" Return false if req.backend.health is accessed in vcl_deliver{} where this information is no longer available. Fixes #1228 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:15:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:15:01 -0000 Subject: [Varnish] #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash In-Reply-To: <046.71f481921ab359437f010a9058d2a66e@varnish-cache.org> References: <046.71f481921ab359437f010a9058d2a66e@varnish-cache.org> Message-ID: <061.a626766af03640ffc42dbeb7d2455934@varnish-cache.org> #1228: Accessing req.backend.healthy in vcl_deliver with sick backend makes varnish crash ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [7db894f93330eed1da99336f69a3073a9629eeab]) Return false if req.backend.health is accessed in vcl_deliver{} where this information is no longer available. Fixes #1228 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:18:50 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:18:50 -0000 Subject: [Varnish] #1177: Varnish does not yet run on SPARC - would need to respect strict memory alignment requirements In-Reply-To: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> References: <044.047b8252b083fc44811d5aba045edcbd@varnish-cache.org> Message-ID: <059.ace2c1d304561177e99a7f6bad0c781b@varnish-cache.org> #1177: Varnish does not yet run on SPARC - would need to respect strict memory alignment requirements --------------------------+---------------------- Reporter: karnak | Owner: slink Type: enhancement | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: 3.0.2 Severity: normal | Resolution: invalid Keywords: Solaris | --------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Closed and moved to [[Future_Feature]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:20:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:20:42 -0000 Subject: [Varnish] #1227: Documentation of .initial default is wrong. In-Reply-To: <047.c6dfc3bcd2422ddc524af5f7feb99a76@varnish-cache.org> References: <047.c6dfc3bcd2422ddc524af5f7feb99a76@varnish-cache.org> Message-ID: <062.8c8db1125d10070baf1200480abf9aca@varnish-cache.org> #1227: Documentation of .initial default is wrong. ---------------------------+-------------------- Reporter: perplexes | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by phk): * owner: => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:48:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:48:41 -0000 Subject: [Varnish] #1225: bans_req counter doesn't take into account bans loaded from persistent silos In-Reply-To: <044.c3e690e72f98e366d80cf1c56138fc63@varnish-cache.org> References: <044.c3e690e72f98e366d80cf1c56138fc63@varnish-cache.org> Message-ID: <059.1cb4f343e0851a264df8310f7f907379@varnish-cache.org> #1225: bans_req counter doesn't take into account bans loaded from persistent silos ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [a6d082e96efc047da0ce33dd663e506347fe321f]: {{{ #!CommitTicketReference repository="" revision="a6d082e96efc047da0ce33dd663e506347fe321f" Count reloaded bans in VSC::bans_req Replace some magic numbers by #defines and segregate the ban-string Base patch from: martin Fixes #1225 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 08:48:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 08:48:42 -0000 Subject: [Varnish] #1225: bans_req counter doesn't take into account bans loaded from persistent silos In-Reply-To: <044.c3e690e72f98e366d80cf1c56138fc63@varnish-cache.org> References: <044.c3e690e72f98e366d80cf1c56138fc63@varnish-cache.org> Message-ID: <059.d992a8723559bcf698811a3f953b6ea0@varnish-cache.org> #1225: bans_req counter doesn't take into account bans loaded from persistent silos ----------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [a6d082e96efc047da0ce33dd663e506347fe321f]) Count reloaded bans in VSC::bans_req Replace some magic numbers by #defines and segregate the ban-string Base patch from: martin Fixes #1225 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 11:12:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 11:12:26 -0000 Subject: [Varnish] #1227: Documentation of .initial default is wrong. In-Reply-To: <047.c6dfc3bcd2422ddc524af5f7feb99a76@varnish-cache.org> References: <047.c6dfc3bcd2422ddc524af5f7feb99a76@varnish-cache.org> Message-ID: <062.56f8522cc813df6316c16e67171eb9c0@varnish-cache.org> #1227: Documentation of .initial default is wrong. ---------------------------+-------------------- Reporter: perplexes | Owner: daghf Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by daghf): * owner: scoof => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 11:30:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 11:30:56 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <057.a30a12111e9361b580003ad41247bdec@varnish-cache.org> #1021: varnishtop -1 takes a long time to run ------------------------+---------------------- Reporter: yves | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: invalid Keywords: varnishlog | ------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This has been moved to [[Future_Performance]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 12 11:32:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Nov 2012 11:32:45 -0000 Subject: [Varnish] #1222: std.collect() doesn't work on resp.http (e.g. in vcl_deliver) In-Reply-To: <042.c9461de71037fad1dbccd1350fff076f@varnish-cache.org> References: <042.c9461de71037fad1dbccd1350fff076f@varnish-cache.org> Message-ID: <057.ab84e0aea929fa680c8c82f5beaea939@varnish-cache.org> #1222: std.collect() doesn't work on resp.http (e.g. in vcl_deliver) --------------------+-------------------- Reporter: mark | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by daghf): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 13 07:12:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Nov 2012 07:12:35 -0000 Subject: [Varnish] #1226: Missing exit in varnishncsa init script In-Reply-To: <064.41e1b3c95efa7ff8c2f7986821b0d8d4@varnish-cache.org> References: <064.41e1b3c95efa7ff8c2f7986821b0d8d4@varnish-cache.org> Message-ID: <079.9fee3c3a45d3e77329ecf0e8b5123112@varnish-cache.org> #1226: Missing exit in varnishncsa init script ------------------------------+--------------------- Reporter: ghislain.seguy@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | ------------------------------+--------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This has been fixed in the Debian packaging now. It's a fairly minor issue, so I'm not rebuilding packages for it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 13 07:34:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Nov 2012 07:34:52 -0000 Subject: [Varnish] #1208: CLANG does not like -g in link commands In-Reply-To: <041.cade3d35733de2a5964fe9739e909f60@varnish-cache.org> References: <041.cade3d35733de2a5964fe9739e909f60@varnish-cache.org> Message-ID: <056.889217df31334509fecebbce2ad65420@varnish-cache.org> #1208: CLANG does not like -g in link commands --------------------+---------------------- Reporter: phk | Owner: tollef Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: wontfix Keywords: | --------------------+---------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: Clang bug (as determined earlier) and quite tedious to fix in the auto* space. Closing, since we can't really fix it ourselves. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 20 11:31:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Nov 2012 11:31:17 -0000 Subject: [Varnish] #1229: Varnish Banlurker patch Message-ID: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> #1229: Varnish Banlurker patch ------------------------------------------------+------------------------- Reporter: celly | Type: enhancement Status: new | Priority: high Milestone: Later | Component: varnishd Version: 3.0.3 | Severity: critical Keywords: banlist, huge, performance, lurker | ------------------------------------------------+------------------------- Hi guys, we are using your proxies on our projects, that are speciffic by lots of req/s and bans/s. Last few months, we were faced a performance issues (slow response to req). We found out, that this is because huge banlist. We were using banlurker, ofcourse, but it cannot handle so much new bans in combination with a lot of cached objects. Setting up ban_lurker_sleep to a very small number didn't help, so we realised, that we should look into a code. Month ago, we found, sorry the word I used, problem and make a patch (attached). Since that time, our Varnishes works great again and have very fast responses. I made some graphs screenshots (attached) for comparision. Each graph is made in three versions: * M1 - month 1 (from 2 months ago to 1 month) * M2 - month 2 (from 1 month ago to now) * O - overview (from 2 months ago to now) Files names: * G1 - banlist size * G2 add/gone ban a. light blue - bans added per second a. green - bans marked as gone per second but remains in list * G3 - TCP connections * G4 - CPU detailed stats: a. blue - user a. yellow - sys a. green - soft * G5 - each color is a different CPU Simply said, patch clears banlist in ban_lurker_work, because ban_lurker_work can take a lots of time to finnish in our case. As I wrote, our service has quite big hitrate, so many of bans in banlist is gone by hit before ban_lurker touches it. We like your software and we will be glad, if you make this patch as a part of future releases. We can fork you on GitHub and make pull request, if you prefer this way. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 20 11:50:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Nov 2012 11:50:51 -0000 Subject: [Varnish] #1229: Varnish Banlurker patch In-Reply-To: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> References: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> Message-ID: <058.c15e315eb513be8685d547be34c4f297@varnish-cache.org> #1229: Varnish Banlurker patch ------------------------------------------------+-------------------- Reporter: celly | Owner: Type: enhancement | Status: new Priority: high | Milestone: Later Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: banlist, huge, performance, lurker | ------------------------------------------------+-------------------- Comment (by celly): I had to split the archive into parts, unpack it using {{{ cat graphs-gif.tar.bz2.0* | tar jxv }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 22 14:11:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Nov 2012 14:11:35 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.15338fe38dd823ce0cf1f081825faa2a@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Comment (by lkarsten): Commited to the documentation: https://www.varnish-cache.org/docs/3.0/tutorial/platformnotes.html https://www.varnish-cache.org/docs/trunk/installation/platformnotes.html Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 22 14:12:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Nov 2012 14:12:35 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.b465e5ca8b341206bd03a3a8e3862890@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ---------------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 22 20:26:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Nov 2012 20:26:05 -0000 Subject: [Varnish] #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc Message-ID: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc ----------------------+-------------------- Reporter: basile@? | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+-------------------- Because of the difference in how uClibc and glibc stack their header files, stdio.h indirectly brings in PTHREAD_CANCELED from pthread.h on a uClibc system, whereas it does not on a glibc system. This happens in mgt.h and mgt_main.c, and causes a (pre-)compile time failure. This patch refines the check in those files to take this fact into consideration. See the downstream bug for more details: https://bugs.gentoo.org/444294 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 23 18:17:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 23 Nov 2012 18:17:43 -0000 Subject: [Varnish] #1045: Ban lurker doesn't work anymore In-Reply-To: <042.4946905ce0b79e243e705a144d3ed1c5@varnish-cache.org> References: <042.4946905ce0b79e243e705a144d3ed1c5@varnish-cache.org> Message-ID: <057.449b5bd5ab5373ebaefe2e05a5427747@varnish-cache.org> #1045: Ban lurker doesn't work anymore ------------------------+--------------------- Reporter: Yvan | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: fixed Keywords: ban lurker | ------------------------+--------------------- Comment (by tgigli): Guys, I am using 3.0.2 version and have the same problem. When some ban {{{ root at trestles:/etc/varnish# varnishd -V varnishd (varnish-3.0.2 revision cbf1284) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS }}} It keep growing. Sometimes it seems to work cleaning 1 or 2 lines, but it takes a lot of time and the speed that it is cleaned is really slow. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 24 12:53:47 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 24 Nov 2012 12:53:47 -0000 Subject: [Varnish] #1045: Ban lurker doesn't work anymore In-Reply-To: <042.4946905ce0b79e243e705a144d3ed1c5@varnish-cache.org> References: <042.4946905ce0b79e243e705a144d3ed1c5@varnish-cache.org> Message-ID: <057.04dcd59f70125efd916daa6d3c17af51@varnish-cache.org> #1045: Ban lurker doesn't work anymore ------------------------+--------------------- Reporter: Yvan | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: fixed Keywords: ban lurker | ------------------------+--------------------- Comment (by Yvan): @tgigli: you should use the 3.0.3 release, which has the bugfix. In my comment posted 5 months ago, the 3.0.3 wasn't released yet. So use the 3.0.3, with the standard ban lurker parameters, that should work like a charm. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 25 11:45:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 25 Nov 2012 11:45:36 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <062.5c963e87bb7341985c0b6a34e3ab8da0@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) -------------------------------------------------+------------------------- Reporter: campisano | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: blocker | Resolution: Keywords: child died pushing vcls failed | #012CLI communication error (hdr) | -------------------------------------------------+------------------------- Changes (by seldaek): * status: closed => reopened * resolution: worksforme => Comment: Replying to [comment:7 phk]: > The connect_timeout has nothing to do with starting the child process. > > As I said, you can try to increase cli_timeout, if the problem is disk-i/o pileups. @phk - I believe in light of [comment:10 #10] that this should be reopened. I experienced the same yesterday, after many months of smooth execution Varnish just killed its child and failed to restart one then gave up on it entirely. I don't think it's right that *one* failure in months results in a useless server not accepting connections anymore. If it fails repeatedly I could maybe see some value in halting the process but not for one odd failure. Apologies if reopening this is out of line, but if it is the intended behavior I would like to hear a short explanation why. See this from my syslog in case it helps, but it's nothing new (and yes I now increased my cli_timeout for safety, but I still think this issue should be addressed): {{{ Nov 24 06:48:37 web varnishd[29768]: Child (26813) not responding to CLI, killing it. Nov 24 06:49:13 web varnishd[29768]: Child (26813) died signal=3 (core dumped) Nov 24 06:49:13 web varnishd[29768]: Child cleanup complete Nov 24 06:49:13 web varnishd[29768]: child (1256) Started Nov 24 06:49:24 web varnishd[29768]: Pushing vcls failed:#012CLI communication error (hdr) Nov 24 06:49:24 web varnishd[29768]: Stopping Child Nov 24 06:49:24 web varnishd[29768]: Child (1256) said Child starts Nov 24 06:49:27 web varnishd[29768]: Child (1256) said Child dies Nov 24 06:49:31 web varnishd[29768]: Child (1256) died status=1 Nov 24 06:49:31 web varnishd[29768]: Child cleanup complete }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 25 23:40:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 25 Nov 2012 23:40:39 -0000 Subject: [Varnish] #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge Message-ID: <044.4dd7edc6a25089113874a3396713384b@varnish-cache.org> #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge ----------------------+------------------- Reporter: anders | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Keywords: ----------------------+------------------- I am running Varnish 3.0.3 in FreeBSD 8.3 with the following vmods: header, curl, var, authentication, digest, paywall (custom - developed by Varnish Software) and softpurge. After running for some days and doing softpurge every so often, Varnish instantly crashes with the following logged to syslog: {{{ Nov 25 07:20:14 cache4 kernel: pid 35400 (varnishd), uid 0: exited on signal 11 (core dumped) Nov 25 07:20:18 cache4 varnishd[78804]: Child (35400) Panic message: Missing errorhandling code in vmod_softpurge(), vmod_softpurge.c line 63: Condition(spc >= sizeof *ocp) not true.thread = (cache-worker) ident = FreeBSD,8.3-RELEASE-p1,amd64,-smalloc,-smalloc,-hcritbit,kqueue Nov 25 07:20:18 cache4 varnishd[78804]: child (83564) Started Nov 25 07:20:21 cache4 varnishd[78804]: Child (83564) said Child starts }}} Backtrace: {{{ (gdb) bt #0 0x00000008009dce7f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:273 #1 0x00000008009dcebc in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:53 #2 0x000000000042f5a9 in pan_ic (func=0x80713aca5 "vmod_softpurge", file=0x80713ab8f "vmod_softpurge.c", line=63, cond=0x80713ac65 "spc >= sizeof *ocp", err=Variable "err" is not available. ) at cache_panic.c:283 #3 0x000000080713a114 in vmod_softpurge (sp=0x8251a1008) at vmod_softpurge.c:63 #4 0x0000000b5e00ba66 in VGC_function_vcl_miss (sp=0x8251a1008) at ./vcl.fy3gG5B1.c:6089 #5 0x00000000004367e8 in VCL_miss_method (sp=0x8251a1008) at vcl_returns.h:41 #6 0x0000000000415a99 in cnt_miss (sp=0x8251a1008) at cache_center.c:1212 #7 0x0000000000418abc in CNT_Session (sp=0x8251a1008) at steps.h:39 #8 0x00000000004311e4 in wrk_thread_real (qp=0x801413600, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:186 #9 0x0000000800f96511 in pthread_getprio () from /lib/libthr.so.3 #10 0x00007fffe9b50000 in ?? () Cannot access memory at address 0x7fffe9d50000 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 26 12:25:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Nov 2012 12:25:56 -0000 Subject: [Varnish] #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge In-Reply-To: <044.4dd7edc6a25089113874a3396713384b@varnish-cache.org> References: <044.4dd7edc6a25089113874a3396713384b@varnish-cache.org> Message-ID: <059.f9973b23ec8894a27a7409a96a7d8760@varnish-cache.org> #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge ----------------------+-------------------- Reporter: anders | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Martin figured this out. This was caused by lacking refcounting in the softpurge code, which made the softpurged object never to be really expired and as such filled the workspace when a later softpurge makes the list of candidate objects. Updated version on https://github.com/lkarsten/libvmod-softpurge . Closing ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 26 12:26:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Nov 2012 12:26:13 -0000 Subject: [Varnish] #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge In-Reply-To: <044.4dd7edc6a25089113874a3396713384b@varnish-cache.org> References: <044.4dd7edc6a25089113874a3396713384b@varnish-cache.org> Message-ID: <059.993f9919f478af1beae6964081bb9d6d@varnish-cache.org> #1231: Varnish 3.0.3 with panic message: Missing errorhandling code in vmod_softpurge ----------------------+--------------------- Reporter: anders | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 27 10:12:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Nov 2012 10:12:59 -0000 Subject: [Varnish] #792: Bandwidth management / rate-limiting In-Reply-To: <046.9bd97065d3ed9907de522a56e315af59@varnish-cache.org> References: <046.9bd97065d3ed9907de522a56e315af59@varnish-cache.org> Message-ID: <061.a4554208ebb1d9967573b24b59bde636@varnish-cache.org> #792: Bandwidth management / rate-limiting ----------------------------------+---------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: bandwidth rate-limit | ----------------------------------+---------------------- Comment (by ruben): Replying to [comment:3 phk]: > We revisted the oldest tickets on the bug-wash today, and finally(!) > made our mind up about this one: > > I'm closing this ticket as invalid, because it is a feature request. > > I have put a back-link to it from wiki:Future_Feature, please read long explanation there. The correct link for this is wiki:Future_VMODS#RateLimiting > > Sorry about taking so long before dealing with this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 28 13:01:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Nov 2012 13:01:33 -0000 Subject: [Varnish] #1232: vcl.load should echo something instead of a newline on success Message-ID: <045.a8ebf073c3dd7005ec41cb0e979ec4d4@varnish-cache.org> #1232: vcl.load should echo something instead of a newline on success ---------------------+------------------------- Reporter: derjohn | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: | ---------------------+------------------------- Hi, if I use vcl.load, the output of the command is a newline. Should be a "VCL activated." or such. This might make usage in scripts simpler for some people. rgds, j -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 29 12:36:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 29 Nov 2012 12:36:13 -0000 Subject: [Varnish] #1233: 404 in documentation Message-ID: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> #1233: 404 in documentation ---------------------------+------------------- Reporter: lkarsten | Owner: Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: minor | Keywords: ---------------------------+------------------- https://www.varnish-cache.org/docs/3.0/ has a link "Module Index" which points to https://www.varnish-cache.org/docs/3.0/py-modindex.html which gives 404. -- Ticket URL: Varnish The Varnish HTTP Accelerator