From varnish-bugs at varnish-cache.org Fri Oct 1 10:35:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Oct 2010 10:35:44 -0000 Subject: [Varnish] #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header Message-ID: <044.4fe3c5012561f4c28cb0188d665957e2@varnish-cache.org> #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header ---------------------+------------------------------------------------------ Reporter: matthew | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ RFC2616 14.44 states: "A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation." and "A Vary field value of "*" signals that unspecified parameters not limited to the request- headers (e.g., the network address of the client), play a role in the selection of the response representation." However, varnish caches pages sent with "Vary: *" and e.g. "Cache-Control: max-age=600". Looking at cache_vary.c it doesn't appear to have any special handling for "*" at all, so must be treating it as a normal header, and indeed if you send a "*: Foo" header within the request, varnish will use the content of that header to determine whether to serve cached content or not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 2 12:22:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Oct 2010 12:22:08 -0000 Subject: [Varnish] #611: Websockets support In-Reply-To: <044.e857926f03d1cd58dcb558810a7e0704@varnish-cache.org> References: <044.e857926f03d1cd58dcb558810a7e0704@varnish-cache.org> Message-ID: <053.d14c0097860389237255bfb3684fe013@varnish-cache.org> #611: Websockets support -------------------------+-------------------------------------------------- Reporter: wesnoth | Owner: phk Type: enhancement | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by wesnoth): * status: closed => reopened * resolution: invalid => Comment: I can now confirm that Varnish does definitely not support HTML5 Websockets. I have tested pywebsocket (http://code.google.com/p/pywebsocket/) using Varnish as a proxy, and it doesn't work, reporting "Header Upgrade is not defined". I would really like to see support for HTML5 Websockets in Varnish. This is a feature which will be more and more common, when Firefox 4, Safari and Google Chrome all support Websockets. This is the error message reported by pywebsocket: ERROR:mod_pywebsocket.handshake:Handshake error: Header Upgrade is not defined [2010-10-02 14:10:19,698] [ERROR] mod_pywebsocket.handshake: Handshake error: Header Upgrade is not defined -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 2 18:38:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Oct 2010 18:38:33 -0000 Subject: [Varnish] #611: Websockets support In-Reply-To: <044.e857926f03d1cd58dcb558810a7e0704@varnish-cache.org> References: <044.e857926f03d1cd58dcb558810a7e0704@varnish-cache.org> Message-ID: <053.355073a32eb0dcb8566f92cd8e5596f4@varnish-cache.org> #611: Websockets support -------------------------+-------------------------------------------------- Reporter: wesnoth | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => invalid Comment: This is still a feature request, we do not use tickets for those, please update the PostTwoShoppingList as necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:09:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:09:56 -0000 Subject: [Varnish] #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header In-Reply-To: <044.4fe3c5012561f4c28cb0188d665957e2@varnish-cache.org> References: <044.4fe3c5012561f4c28cb0188d665957e2@varnish-cache.org> Message-ID: <053.719a627b7168dabc54fb4cd84668390a@varnish-cache.org> #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header ---------------------+------------------------------------------------------ Reporter: matthew | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:10:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:10:19 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux In-Reply-To: <043.d5f8ad4b2261de27db3676c54dc9fe24@varnish-cache.org> References: <043.d5f8ad4b2261de27db3676c54dc9fe24@varnish-cache.org> Message-ID: <052.20ac12ddaf5732fc56c34563d8b04570@varnish-cache.org> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: martin Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:10:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:10:57 -0000 Subject: [Varnish] #411: restart not available in vcl_deliver In-Reply-To: <043.41ab1c9ec6f0837bc7df7c634c3f382d@varnish-cache.org> References: <043.41ab1c9ec6f0837bc7df7c634c3f382d@varnish-cache.org> Message-ID: <052.15020a72322be00606b98d76d3feb85c@varnish-cache.org> #411: restart not available in vcl_deliver ----------------------+----------------------------------------------------- Reporter: hajile | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * owner: phk => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:21:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:21:22 -0000 Subject: [Varnish] #483: Varnishstat should show the number of healthy / sick backends In-Reply-To: <040.3557b7dd197c1ad4aa2a592bf8a96d3d@varnish-cache.org> References: <040.3557b7dd197c1ad4aa2a592bf8a96d3d@varnish-cache.org> Message-ID: <049.34a301ebc1539fb3b1c3cfe07a219fcd@varnish-cache.org> #483: Varnishstat should show the number of healthy / sick backends ---------------------+------------------------------------------------------ Reporter: rts | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: This works in -trunk now, you get detailed reporting of backend probing in varnishstat {{{ 003fffffff Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:22:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:22:27 -0000 Subject: [Varnish] #485: Virtualhost logging for varnishncsa In-Reply-To: <043.fde65ce041c93ef9119ae5492b077e39@varnish-cache.org> References: <043.fde65ce041c93ef9119ae5492b077e39@varnish-cache.org> Message-ID: <052.e381797973ab26159e9473065cab2b71@varnish-cache.org> #485: Virtualhost logging for varnishncsa -------------------------+-------------------------------------------------- Reporter: rhalff | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: varnishncsa, virtual hosts, apache, logging -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:36:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:36:34 -0000 Subject: [Varnish] #575: Python Tools Enhancement In-Reply-To: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> References: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> Message-ID: <055.307ff9a672d82c1e338dd3eda7fc5908@varnish-cache.org> #575: Python Tools Enhancement -------------------------+-------------------------------------------------- Reporter: justquick | Owner: kristian Type: enhancement | Status: new Priority: low | Milestone: Component: varnishadm | Version: trunk Severity: minor | Keywords: python enhancement -------------------------+-------------------------------------------------- Changes (by phk): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:37:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:37:26 -0000 Subject: [Varnish] #597: Update VCLExampleRemovingSomeCookies In-Reply-To: <045.2868d464cd5545ef62cf0c08f0019fc9@varnish-cache.org> References: <045.2868d464cd5545ef62cf0c08f0019fc9@varnish-cache.org> Message-ID: <054.dc57f2685ce77e2add09e39bea86917e@varnish-cache.org> #597: Update VCLExampleRemovingSomeCookies -----------------------+---------------------------------------------------- Reporter: zviratko | Type: documentation Status: closed | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This has been fixed independently in the meantime, so closing this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:47:12 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:47:12 -0000 Subject: [Varnish] #676: keeping varnishstat open will bring down server In-Reply-To: <045.d350afaccc03fe08044ff0b0b51085a6@varnish-cache.org> References: <045.d350afaccc03fe08044ff0b0b51085a6@varnish-cache.org> Message-ID: <054.0917848834c3a3340ca708e1abc1f1f2@varnish-cache.org> #676: keeping varnishstat open will bring down server -------------------------+-------------------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishstat | Version: trunk Severity: minor | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I have given the shared memory handling a significant rework, but I have no idea if it addresses this issue. If it happens again, try to get a strace/ktrace of the process or attach a debugger so we can see what it spins on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 11:55:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 11:55:34 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.2b342531ff609e357769b1790f28b498@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" -------------------------+-------------------------------------------------- Reporter: stefansinn | Type: defect Status: closed | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Resolution: fixed | Keywords: Redirect User-Agent -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Seems like this was resolved. Otherwise please reopen with more detailed description -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 15:24:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 15:24:34 -0000 Subject: [Varnish] #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header In-Reply-To: <044.4fe3c5012561f4c28cb0188d665957e2@varnish-cache.org> References: <044.4fe3c5012561f4c28cb0188d665957e2@varnish-cache.org> Message-ID: <053.8a51a929caeba7f308f13444b7b27ea8@varnish-cache.org> #787: Varnish incorrectly treats "Vary: *" as if "*" is just a normal header ---------------------+------------------------------------------------------ Reporter: matthew | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5399]) Handle "Vary: *" headers by sending the object to pass, there really isn't anything else we can do sensibly. Fixes: #787 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 20:20:54 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 20:20:54 -0000 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request Message-ID: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request -----------------------------------------------+---------------------------- Reporter: jim.robinson | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: http_range_support byte range set | -----------------------------------------------+---------------------------- Varnish 2.1.3 byte range support fails to work when handed a set of ranges. The HTTP 1.1 specification, section "14.35.1 Byte Ranges" specifies that {{{ "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity." }}} Given a simple VCL of: {{{ backend default { .host = "127.0.0.1"; .port = "80"; } }}} where the backend is an Apache 2.2.14 server, we can start up varnishd on port 4040 and activate range support: {{{ $ sudo /usr/local/varnish/2.1.3/sbin/varnishd -d -P /var/run/varnish.pid -a localhost:4040 -f /usr/local/varnish/2.1.3/etc/varnish/test.vcl -u nobody -g nobody -s malloc,10M storage_malloc: max size 10 MB. Using old SHMFILE Varnish on Darwin,9.8.0,i386,-smalloc,-hcritbit 200 193 ----------------------------- Varnish HTTP accelerator CLI. ----------------------------- Type 'help' for command list. Type 'quit' to close CLI session. Type 'start' to launch worker process. start child (69026) Started 200 0 param.set http_range_support on 200 0 }}} In another window we first issue a curl request to our apache server and ask for the first four bytes as a set of 1-byte ranges: {{{ $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 http://127.0.0.1/test.pdf HTTP/1.1 206 Partial Content Date: Mon, 04 Oct 2010 19:46:25 GMT Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Accept-Ranges: bytes Content-Length: 389 Content-Type: multipart/byteranges; boundary=491cfccba1f8e35b9 --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 0-0/1149246 % --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 1-1/1149246 P --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 2-2/1149246 D --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 3-3/1149246 F --491cfccba1f8e35b9-- }}} Now while we can issue a single range request to varnish and get back the right thing: {{{ $ curl -s -i -HRange:bytes=1-1 http://localhost:4040/test.pdf ; echo HTTP/1.1 206 Partial Content Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Content-Type: application/pdf Accept-Ranges: bytes Date: Mon, 04 Oct 2010 19:46:33 GMT X-Varnish: 716983327 716983316 Age: 189 Via: 1.1 varnish Connection: keep-alive Content-Range: bytes 1-1/1149246 Content-Length: 1 P }}} But we cannot issue a set of ranges: {{{ $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 http://localhost:4040/test.pdf | strings | head -51param.set http_range_support on HTTP/1.1 200 OK Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Content-Type: application/pdf Content-Length: 1149246 Accept-Ranges: bytes Date: Mon, 04 Oct 2010 19:46:46 GMT X-Varnish: 716983328 716983316 Age: 203 Via: 1.1 varnish Connection: keep-alive %PDF-1.4 45 0 obj ... rest of the entire PDF elided... }}} The problem appears to be that cache_response.c has an assumption built into the logic that byte range requests aren't multi-sequence: {{{ 278 if (sp->disable_esi || sp->esis == 0) { 279 /* For none ESI and non ESI-included objects, try Range */ 280 if (params->http_range_support && 281 (sp->disable_esi || sp->esis == 0) && 282 sp->obj->response == 200 && 283 sp->wantbody && 284 http_GetHdr(sp->http, H_Range, &r)) 285 res_dorange(sp, r, &low, &high); 286 287 sp->acct_tmp.hdrbytes += http_Write(sp->wrk, sp->wrk->resp, 1); }}} The res_dorange request that calculates the range and the subsequent call to http_Write assume only a single range, not a set of ranges. Jim -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 4 21:01:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Oct 2010 21:01:38 -0000 Subject: [Varnish] #789: v2.1.3 w/ http_range_support on strips Content-Range on pass Message-ID: <049.fed33db428dab02e8bee5fad46a1664b@varnish-cache.org> #789: v2.1.3 w/ http_range_support on strips Content-Range on pass ------------------------------------------------------------------+--------- Reporter: jim.robinson | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: http_range_support byte range content-range stripped | ------------------------------------------------------------------+--------- Varnish 2.1.3 with http_range_support on strips the backend Content-Range on "pass" The HTTP 1.1 specification, section "10.2.7 206 Partial Content" states in part that {{{ The response MUST include the following header fields: - Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body. }}} While newer version of Apache, in the 2.x series, appear to return Content-Type, older versions, in the 1.3.x series, appear to use Content- Range. Given the VCL: {{{ backend default { .host = "127.0.0.1"; .port = "80"; } sub vcl_recv { if (req.http.X-Test ~ "pass") { return (pass); } if (req.http.X-Test ~ "pipe") { return (pipe); } return (lookup); } }}} Where 127.0.0.1:80 is an Apache *1.3* server, a Byte Range request is handled by returning a Content-Range header instead of using a multipart/bytes Content-Type. {{{ $ curl -s -i -HX-Test:pass -HRange:bytes=1-1 http://localhost/test.mp3; echo HTTP/1.1 206 Partial Content Date: Mon, 04 Oct 2010 20:43:38 GMT Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT ETag: "1a8fe2-1361723-4c8fea8a" Accept-Ranges: bytes Content-Length: 1 Content-Range: bytes 1-1/20322083 Connection: close Content-Type: audio/mpeg D }}} When going through varnish, the "pass" operation filters out Content- Range: {{{ $ curl -s -i -HX-Test:pass -HRange:bytes=1-1 http://localhost:4040/test.mp3; echo HTTP/1.1 206 Partial Content Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT ETag: "1a8fe2-1361723-4c8fea8a" Content-Type: audio/mpeg Content-Length: 1 Accept-Ranges: bytes Date: Mon, 04 Oct 2010 20:44:31 GMT X-Varnish: 2073488282 Age: 0 Via: 1.1 varnish Connection: keep-alive D }}} While "pipe" and "lookup" do not: {{{ $ curl -s -i -HX-Test:pipe -HRange:bytes=1-1 http://localhost:4040/test.mp3; echo HTTP/1.1 206 Partial Content Date: Mon, 04 Oct 2010 20:44:58 GMT Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT ETag: "1a8fe2-1361723-4c8fea8a" Accept-Ranges: bytes Content-Length: 1 Content-Range: bytes 1-1/20322083 Connection: close Content-Type: audio/mpeg D $ curl -s -i -HX-Test:lookup -HRange:bytes=1-1 http://localhost:4040/test.mp3; echo HTTP/1.1 206 Partial Content Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT ETag: "1a8fe2-1361723-4c8fea8a" Content-Type: audio/mpeg Accept-Ranges: bytes Date: Mon, 04 Oct 2010 20:45:09 GMT X-Varnish: 2073488284 Age: 7 Via: 1.1 varnish Connection: keep-alive Content-Range: bytes 1-1/20322083 Content-Length: 1 D }}} Here's the varnishlog dump from the faulty "pass" request: {{{ 10 SessionOpen c 127.0.0.1 50307 localhost:4040 10 ReqStart c 127.0.0.1 50307 2073488290 10 RxRequest c GET 10 RxURL c /test.mp3 10 RxProtocol c HTTP/1.1 10 RxHeader c User-Agent: curl/7.19.4 (i386-apple-darwin9.6.2) libcurl/7.19.4 zlib/1.2.5 10 RxHeader c Host: localhost:4040 10 RxHeader c Accept: */* 10 RxHeader c X-Test:pass 10 RxHeader c Range:bytes=1-1 10 VCL_call c recv 10 VCL_return c pass 10 VCL_call c hash 10 VCL_return c hash 10 VCL_call c pass 10 VCL_return c pass 11 BackendOpen b default 127.0.0.1 50308 171.67.112.155 80 10 Backend c 11 default default 11 TxRequest b GET 11 TxURL b /test.mp3 11 TxProtocol b HTTP/1.1 11 TxHeader b User-Agent: curl/7.19.4 (i386-apple-darwin9.6.2) libcurl/7.19.4 zlib/1.2.5 11 TxHeader b Host: localhost:4040 11 TxHeader b Accept: */* 11 TxHeader b X-Test:pass 11 TxHeader b Range:bytes=1-1 11 TxHeader b X-Varnish: 2073488290 11 RxProtocol b HTTP/1.1 11 RxStatus b 206 11 RxResponse b Partial Content 11 RxHeader b Date: Mon, 04 Oct 2010 20:55:59 GMT 11 RxHeader b Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 11 RxHeader b Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT 11 RxHeader b ETag: "1a8fe2-1361723-4c8fea8a" 11 RxHeader b Accept-Ranges: bytes 11 RxHeader b Content-Length: 1 11 RxHeader b Content-Range: bytes 1-1/20322083 11 RxHeader b Connection: close 11 RxHeader b Content-Type: audio/mpeg 10 TTL c 2073488290 RFC 120 1286225759 0 0 0 0 10 VCL_call c fetch 10 VCL_return c pass 10 ObjProtocol c HTTP/1.1 10 ObjStatus c 206 10 ObjResponse c Partial Content 10 ObjHeader c Date: Mon, 04 Oct 2010 20:55:59 GMT 10 ObjHeader c Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 10 ObjHeader c Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT 10 ObjHeader c ETag: "1a8fe2-1361723-4c8fea8a" 10 ObjHeader c Content-Type: audio/mpeg 11 Length b 1 11 BackendClose b default 10 VCL_call c deliver 10 VCL_return c deliver 10 TxProtocol c HTTP/1.1 10 TxStatus c 206 10 TxResponse c Partial Content 10 TxHeader c Server: Apache/1.3.26 (Unix) DAV/1.0.3 ApacheJServ/1.1.2 10 TxHeader c Last-Modified: Tue, 14 Sep 2010 21:35:06 GMT 10 TxHeader c ETag: "1a8fe2-1361723-4c8fea8a" 10 TxHeader c Content-Type: audio/mpeg 10 TxHeader c Content-Length: 1 10 TxHeader c Accept-Ranges: bytes 10 TxHeader c Date: Mon, 04 Oct 2010 20:55:59 GMT 10 TxHeader c X-Varnish: 2073488290 10 TxHeader c Age: 0 10 TxHeader c Via: 1.1 varnish 10 TxHeader c Connection: keep-alive 10 Length c 1 10 ReqEnd c 2073488290 1286225759.180437088 1286225759.250189066 0.000094175 0.069691896 0.000060081 10 SessionClose c EOF 10 StatSess c 127.0.0.1 50307 0 1 1 0 1 1 346 1 }}} I had sent an original query about this to varnish-misc, it discusses the real scenario we were having trouble with: [http://lists.varnish-cache.org/pipermail/varnish- misc/2010-September/004687.html] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 5 06:00:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Oct 2010 06:00:22 -0000 Subject: [Varnish] #541: Suggested VCL for cross domain XMLHttpRequest using Varnish In-Reply-To: <042.971dc842a30aaa111e5621d2efb81ab3@varnish-cache.org> References: <042.971dc842a30aaa111e5621d2efb81ab3@varnish-cache.org> Message-ID: <051.792e5d5d91030372efa044ea16d70890@varnish-cache.org> #541: Suggested VCL for cross domain XMLHttpRequest using Varnish ----------------------------------+----------------------------------------- Reporter: ned14 | Type: enhancement Status: closed | Priority: low Milestone: Varnish 2.1 release | Component: documentation Version: trunk | Severity: minor Resolution: fixed | Keywords: ----------------------------------+----------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks, fixed on http://www.varnish- cache.org/trac/wiki/VCLExampleXMLHTTPRequest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 5 06:47:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Oct 2010 06:47:18 -0000 Subject: [Varnish] #710: check_varnish.c fails to compile against varnish 2.1.x In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org> References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org> Message-ID: <052.1209cb765867b6b59cab687aec5ea5ef@varnish-cache.org> #710: check_varnish.c fails to compile against varnish 2.1.x --------------------+------------------------------------------------------- Reporter: netmax | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: nagios | Version: 2.1.2 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This is mostly (sans the linking of libvarnish/libvarnishcompat) fixed in the 2.1 branch now, so closing this bug. The linking bits are really bugs in libvarnishapi, not the nagios plugin. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 5 12:06:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Oct 2010 12:06:21 -0000 Subject: [Varnish] #790: v00030.vtc coredumps VCC compiler Message-ID: <040.cc9619d2d4093705d953278da068f63f@varnish-cache.org> #790: v00030.vtc coredumps VCC compiler ----------------------+----------------------------------------------------- Reporter: phk | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- The v00030.vtc testcase ends with a "badvcl" test, which succeeds because the VCC hits an assert and coredumps. The offending bit seems to be: {{{ director directorname dns { .list = { "192.168.16.255"/24; } } }}} Which triggers the assert in line 156 of vcc_dir_dns.c: {{{ assert (ip4 == (ip4 & mask)); }}} Please replace this assert with proper error handling and reporting. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 5 13:02:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Oct 2010 13:02:39 -0000 Subject: [Varnish] #790: v00030.vtc coredumps VCC compiler In-Reply-To: <040.cc9619d2d4093705d953278da068f63f@varnish-cache.org> References: <040.cc9619d2d4093705d953278da068f63f@varnish-cache.org> Message-ID: <049.340a013dfa07dead601d8076f0586efe@varnish-cache.org> #790: v00030.vtc coredumps VCC compiler ----------------------+----------------------------------------------------- Reporter: phk | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): On closer inspection, it seems that pretty much all the -badvcl tests results in core dumps. Please Fix. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 5 19:39:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Oct 2010 19:39:58 -0000 Subject: [Varnish] #791: GeoIP Plugin does not have licensing information Message-ID: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> #791: GeoIP Plugin does not have licensing information --------------------+------------------------------------------------------- Reporter: apgwoz | Type: documentation Status: new | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: normal Keywords: plugin | --------------------+------------------------------------------------------- I'd like to modify and republish some modifications to the code posted here: http://www.varnish-cache.org/trac/wiki/GeoipUsingInlineC, however there is no licensing information provided with it. Mithrandir on irc mentioned that it's most likely BSD and told me to create a ticket so he could take care of it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From thebog at gmail.com Tue Oct 5 22:24:22 2010 From: thebog at gmail.com (thebog) Date: Wed, 6 Oct 2010 00:24:22 +0200 Subject: [Varnish] #791: GeoIP Plugin does not have licensing information In-Reply-To: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> References: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> Message-ID: It's LGPL (http://www.maxmind.com/app/c), but there is a BSD version of it also :) http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/GeoIP/ Ab On Tue, Oct 5, 2010 at 9:39 PM, Varnish wrote: > #791: GeoIP Plugin does not have licensing information > --------------------+------------------------------------------------------- > ?Reporter: ?apgwoz ?| ? ? ? ?Type: ?documentation > ? Status: ?new ? ? | ? ?Priority: ?normal > Milestone: ? ? ? ? ?| ? Component: ?packaging > ?Version: ?trunk ? | ? ?Severity: ?normal > ?Keywords: ?plugin ?| > --------------------+------------------------------------------------------- > ?I'd like to modify and republish some modifications to the code posted > ?here: http://www.varnish-cache.org/trac/wiki/GeoipUsingInlineC, however > ?there is no licensing information provided with it. Mithrandir on irc > ?mentioned that it's most likely BSD and told me to create a ticket so he > ?could take care of it. > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at varnish-cache.org > http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > From varnish-bugs at varnish-cache.org Thu Oct 7 09:21:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Oct 2010 09:21:32 -0000 Subject: [Varnish] #792: Bandwidth management / rate-limiting Message-ID: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> #792: Bandwidth management / rate-limiting -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: bandwidth rate-limit -------------------------+-------------------------------------------------- Hi, Here is a patch to allow for rate-limiting on specific objects / url / etc. It uses vmod and looks like this in the VCL : {{{ sub vcl_recv { if ( req.url ~ "^/bigone.ts$" ) { std.set_bandwidth(20000); } } }}} This will limit the delivery at 20000 bytes/sec. The idea behind this (eh, who would like to slow down delivery with a web- accelerator ?) is the following : mobile users watching a video usually watch the first N seconds and stop. But as they start watching, the device downloads at full speed in order to fill up its cache. The result is that a lot of downloaded data are never used, so why wouldn't we limit the download rate to the rate at which the video is encoded ? This allows to decrease the overall data transfer, which is not a bad idea on mobile networks. Note that this is just a "testcase" patch : the "sleep(1)" would better be something more precise but that's the main idea. All remarks welcome. Thanks, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 7 11:29:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Oct 2010 11:29:10 -0000 Subject: [Varnish] #792: Bandwidth management / rate-limiting In-Reply-To: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> References: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> Message-ID: <054.63d9862a26d1acf7bf2ac9d97edc7725@varnish-cache.org> #792: Bandwidth management / rate-limiting -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: bandwidth rate-limit -------------------------+-------------------------------------------------- Comment(by tmagnien): After rereading, I think I should use TIM_real() to get timestamp before and after write operation to take into account the time used for sending data, e.g. : sleep(1 - write_duration). This would allow for a more precise bandwidth management. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 7 15:46:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Oct 2010 15:46:27 -0000 Subject: [Varnish] #790: v00030.vtc coredumps VCC compiler In-Reply-To: <040.cc9619d2d4093705d953278da068f63f@varnish-cache.org> References: <040.cc9619d2d4093705d953278da068f63f@varnish-cache.org> Message-ID: <049.3f3ca7c7a3e007218bda7752321ae8a2@varnish-cache.org> #790: v00030.vtc coredumps VCC compiler ----------------------+----------------------------------------------------- Reporter: phk | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => fixed Comment: r5418 should fix this. There's still room for improvement, but this should take care of the assert() bits. -- Ticket URL: Varnish The Varnish HTTP Accelerator From thebog at gmail.com Thu Oct 7 18:25:14 2010 From: thebog at gmail.com (thebog) Date: Thu, 7 Oct 2010 20:25:14 +0200 Subject: [Varnish] #792: Bandwidth management / rate-limiting In-Reply-To: <054.63d9862a26d1acf7bf2ac9d97edc7725@varnish-cache.org> References: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> <054.63d9862a26d1acf7bf2ac9d97edc7725@varnish-cache.org> Message-ID: Another, equally important, use for this is protecting against "attacks". I remember once we had a proxy against our site that did prefetch (yes, somebody has written such a bad boy, and yes, they are called M$). They used 100 Mbit/s filling thousands of articles that their cache thought might get read again :) Ab On Thu, Oct 7, 2010 at 1:29 PM, Varnish wrote: > #792: Bandwidth management / rate-limiting > -------------------------+-------------------------------------------------- > ?Reporter: ?tmagnien ? ? | ? ? ? Owner: ?phk > ? ? Type: ?enhancement ?| ? ? ?Status: ?new > ?Priority: ?normal ? ? ? | ? Milestone: > Component: ?varnishd ? ? | ? ? Version: ?trunk > ?Severity: ?normal ? ? ? | ? ?Keywords: ?bandwidth rate-limit > -------------------------+-------------------------------------------------- > > Comment(by tmagnien): > > ?After rereading, I think I should use TIM_real() to get timestamp before > ?and after write operation to take into account the time used for sending > ?data, e.g. : sleep(1 - write_duration). This would allow for a more > ?precise bandwidth management. > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at varnish-cache.org > http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > From varnish-bugs at varnish-cache.org Fri Oct 8 10:21:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 08 Oct 2010 10:21:31 -0000 Subject: [Varnish] #793: TTL randomizing Message-ID: <045.92a918fbaa559f5fca5ca30578f3f03f@varnish-cache.org> #793: TTL randomizing -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: expiry randomization ttl -------------------------+-------------------------------------------------- Hi, Here is a vmod patch to allow TTL randomization. This can be used to avoid the "lemming effect" described [http://www.varnish- cache.org/trac/wiki/PostTwoShoppingList#Expiryrandomization here]. Use in VCL : {{{ sub vcl_fetch { set beresp.ttl = std.randomize_ttl_by(beresp.ttl, 50); } }}} Will randomize all TTLs by 50%. Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 11 11:57:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Oct 2010 11:57:00 -0000 Subject: [Varnish] #793: TTL randomizing In-Reply-To: <045.92a918fbaa559f5fca5ca30578f3f03f@varnish-cache.org> References: <045.92a918fbaa559f5fca5ca30578f3f03f@varnish-cache.org> Message-ID: <054.43ab888116e8ce5498710ee4fb4b415d@varnish-cache.org> #793: TTL randomizing --------------------------------------+------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: expiry randomization ttl | --------------------------------------+------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5421]) Add REAL std.random(REAL low, REAL high) with associated testcase. Example usage: sub vcl_fetch { /* Spread TTLs -10%..+5% because CMS timestamps whole minutes */ set beresp.ttl = beresp.ttl * random(0.90, 1.05); } This usage was one of the very first VCL examples we ever wrote on a whiteboard, we just never got a round tuit until now. Fixes: #793 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 11 12:10:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Oct 2010 12:10:23 -0000 Subject: [Varnish] #575: Python Tools Enhancement In-Reply-To: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> References: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> Message-ID: <055.8411635ed3b3f98744958dbf05dfecdc@varnish-cache.org> #575: Python Tools Enhancement -------------------------+-------------------------------------------------- Reporter: justquick | Owner: kristian Type: enhancement | Status: new Priority: low | Milestone: Component: varnishadm | Version: trunk Severity: minor | Keywords: python enhancement -------------------------+-------------------------------------------------- Comment(by kristian): I've cloned your repo and I'm planning on doing some minor tweaks. Since I've not had time to use this (but I'm about to), the only obvious issues I have with it are stylistic. All in all I think Magnus' version is somewhat easier to deal with in it's current state. There are features in your variant that are interesting, but I'm curious if the interface isn't a bit messy (ie: I see three classes and a run function, as opposed to a single class). I also thought Thread was deprecated in favor of Threading? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 11 16:33:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Oct 2010 16:33:18 -0000 Subject: [Varnish] #575: Python Tools Enhancement In-Reply-To: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> References: <046.5210ab7b206b72ad6f44e21df9bdd803@varnish-cache.org> Message-ID: <055.20359f497cc42df608e0c854d6bcaf8b@varnish-cache.org> #575: Python Tools Enhancement -------------------------+-------------------------------------------------- Reporter: justquick | Owner: kristian Type: enhancement | Status: new Priority: low | Milestone: Component: varnishadm | Version: trunk Severity: minor | Keywords: python enhancement -------------------------+-------------------------------------------------- Comment(by justquick): I look forward to seeing your changes to python-varnish! I separated the work among several classes so that the same process can be run in parallel across multiple varnish instances. The core VarnishHandler class is the only thing that actually does the work on talking to the varnish instance and can be instantiated just by itself for single instance use. The other classes implement run methods which are wrappers and only useful for multi-instance handling and threading. If you can think of a better way to organize it, I am open to changing the layout. threading.Thread has been deprecated (in py2.6) in favor of multiprocessing.Process because it avoids threads and uses subprocesses to completely eliminate the use of the GIL. It is very handy for thread/process intensive applications because GIL switching among threads can drastically impact performance. Thread performance in this application is not a concern of mine since there is only one thread per varnish instance and there shouldnt be a whole lot of switching unless you run a whole mess of commands at once. Implementing multiprocessing in this application would introduce the python>=2.6 dependency which i also dont like. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 13 06:36:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Oct 2010 06:36:16 -0000 Subject: [Varnish] #791: GeoIP Plugin does not have licensing information In-Reply-To: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> References: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> Message-ID: <052.bc87b075597fb847a0ee85e930daed04@varnish-cache.org> #791: GeoIP Plugin does not have licensing information ---------------------------+------------------------------------------------ Reporter: apgwoz | Owner: tfheen Type: documentation | Status: new Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Keywords: plugin ---------------------------+------------------------------------------------ Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 14 13:25:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Oct 2010 13:25:23 -0000 Subject: [Varnish] #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing In-Reply-To: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> References: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> Message-ID: <051.178df2e4b8055b516d9ccd4db4c6daeb@varnish-cache.org> #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by slink): I've reviewed the patch again, updated it for the current trunk r5430 and added some more comments. It this point I think that the implementation won't need any more more sophistication. A good scheduler will always re-schedule warm threads, and because we're using qp->idle as a stack, we will prefer warm threads. Ideally, we will have one pool per cpu (as configured by the admin), but nailing them down would probably be counter-productive. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 14 15:11:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Oct 2010 15:11:05 -0000 Subject: [Varnish] #794: varnishsizes : Say what sizes it show in desc / manpage Message-ID: <044.7f4426446242b5edf8778fed4e31dbf3@varnish-cache.org> #794: varnishsizes : Say what sizes it show in desc / manpage ---------------------------------+------------------------------------------ Reporter: mandark | Type: documentation Status: new | Priority: low Milestone: Varnish 2.1 release | Component: documentation Version: trunk | Severity: trivial Keywords: varnishsizes | ---------------------------------+------------------------------------------ The only information about what is displayed in varnishsizes is : It's a size, "updated histogram showing the distribution of the last N requests by their processing", and "The horizontal scale is logarithmic." But i don'k now how to fix it cause i don't know which size is monitored and in which unit... -- Ticket URL: Varnish The Varnish HTTP Accelerator From thebog at gmail.com Thu Oct 14 20:07:57 2010 From: thebog at gmail.com (thebog) Date: Thu, 14 Oct 2010 22:07:57 +0200 Subject: [Varnish] #794: varnishsizes : Say what sizes it show in desc / manpage In-Reply-To: <044.7f4426446242b5edf8778fed4e31dbf3@varnish-cache.org> References: <044.7f4426446242b5edf8778fed4e31dbf3@varnish-cache.org> Message-ID: Not being to sure about this response, but I am still gonna share it :) I think there is no point to know the size. The tool is build for giving you a sense of what is happening trafficwise, and not hard numbers. Hard numbers you find elsewhere with other tools that do the job much better (Since they are accurate by nature). By being logarithmic I guess you eliminate the possibility that you will reach a "roof" (lets say the top of your screen) with visuals. Since you can't really guess beforehand what kind of traffic to expect, and therefore don't wanna restrict your tool. Some are looking for detail in small numbers, while others wanna watch trends with huge numbers. Take a look at varnishstat and the other tools, and see if that can provide you with what you may be looking for. YS Anders Berg On Thu, Oct 14, 2010 at 5:11 PM, Varnish wrote: > #794: varnishsizes : Say what sizes it show in desc / manpage > ---------------------------------+------------------------------------------ > ?Reporter: ?mandark ? ? ? ? ? ? ?| ? ? ? ?Type: ?documentation > ? Status: ?new ? ? ? ? ? ? ? ? ?| ? ?Priority: ?low > Milestone: ?Varnish 2.1 release ?| ? Component: ?documentation > ?Version: ?trunk ? ? ? ? ? ? ? ?| ? ?Severity: ?trivial > ?Keywords: ?varnishsizes ? ? ? ? | > ---------------------------------+------------------------------------------ > ?The only information about what is displayed in varnishsizes is : > ?It's a size, "updated histogram showing the distribution of the last N > ?requests by their processing", and "The horizontal scale is logarithmic." > > ?But i don'k now how to fix it cause i don't know which size is monitored > ?and in which unit... > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at varnish-cache.org > http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > From varnish-bugs at varnish-cache.org Fri Oct 15 21:05:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Oct 2010 21:05:02 -0000 Subject: [Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set Message-ID: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> #795: Conditional GETs based on modification time are not honored if Last- Modified was not explicitly set ------------------+--------------------------------------------------------- Reporter: runa | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | ------------------+--------------------------------------------------------- Varnish should add a last-modified (or at least set sp->obj->last_modified) of/to now if it doesn't get one from the backend. {{{ > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8n zlib/1.2.3.3 libidn/1.15 > Host: www.x.com > Accept: */* > If-Modified-Since: Fri, 15 Oct 2010 20:09:12 GMT < HTTP/1.1 200 OK < Server: nginx/0.7.65 < Date: Fri, 15 Oct 2010 20:08:24 GMT < Content-Type: text/html; charset=utf-8 < Connection: keep-alive < Status: 200 OK < X-Runtime: 37 < ETag: "735c2070da36d7ee8c24e57f4b0dbc88" < Content-Length: 8356 < Cache-Control: max-age=86400, s-maxage=3600 < X-Varnish: 1825324525 1825143446 < Age: 31573 < Via: 1.1 varnish < X-Cache: HIT }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 16 00:02:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 16 Oct 2010 00:02:27 -0000 Subject: [Varnish] #796: ban lurker deadlock in varnish 2.1.3 Message-ID: <047.daacaf2481cbc4cc522f124139b268c4@varnish-cache.org> #796: ban lurker deadlock in varnish 2.1.3 ------------------------+--------------------------------------------------- Reporter: ryan.krebs | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: ban lurker deadlock ------------------------+--------------------------------------------------- On CentOS 5.5, Linux 2.6.18, varnishd occasionally (about once a week on any one of three production servers) hangs in what looks like a deadlock between the ban lurker and a worker thread doing a cache lookup. If the ban lurker happens to start processing an object at the same time that a request is looking up that object from the cache, the two can get stuck trying to lock ban_mtx and oh->mtx. Attaching a full backtrace, but the relevant threads appear to be:[[BR]] {{{ the ban lurker thread, which would already have ban_mtx locked at this point: #0 0x000000390a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000390a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000390a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000421a69 in Lck__Lock () #4 0x000000000041afea in HSH_FindBan () #5 0x0000000000410b43 in ban_lurker () #6 0x0000000000424429 in wrk_bgthread () #7 0x000000390a80673d in start_thread () from /lib64/libpthread.so.0 #8 0x000000390a0d3d1d in clone () from /lib64/libc.so.6 }}} and {{{ a large number of other threads, which have locked their respective oh->mtxs and are trying to lock ban_mtx: #0 0x000000390a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000390a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000390a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000421a69 in Lck__Lock () #4 0x000000000040f926 in ban_check_object () #5 0x000000000041c42f in HSH_Lookup () #6 0x0000000000411810 in cnt_lookup () #7 0x0000000000413ce4 in CNT_Session () #8 0x0000000000424668 in wrk_do_cnt_sess () #9 0x000000000042396e in wrk_thread_real () #10 0x000000390a80673d in start_thread () from /lib64/libpthread.so.0 #11 0x000000390a0d3d1d in clone () from /lib64/libc.so.6 }}} ban_lurker_sleep is currently set to 0.0005. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 07:32:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 07:32:48 -0000 Subject: [Varnish] #797: VCL error on non existing DNS backend Message-ID: <047.26a8532e5f422e1ab4ef45d018943e08@varnish-cache.org> #797: VCL error on non existing DNS backend ------------------------+--------------------------------------------------- Reporter: gdelacroix | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: vcl backend DNS name ------------------------+--------------------------------------------------- Hi! I've found that Varnish is sending a VCL error when a backend leads to a DNS name that doesn't exists. Example : Here is a DNS name that doesn't exists : {{{ backend= { .host = "www.fu.bar"; .port = "80"; } }}} Here is the error I get : {{{ Message from VCC-compiler: Backend host '"www.fu.bar"': Name or service not known (input Line 113 Pos 17) .host = "www.fu.bar"; ----------------############- In backend host specification starting at: (input Line 112 Pos 17) .backend= { ----------------# }}} I think it's a big behavior issue because it is possible to compile, and run in production, a VCL config leading to an existing DNS name, that could disappear in the future, and then cause Varnish being unable to restart because of VCL error. I think the only viable behavior would be removing DNS check (knowing that there's no IP check for IP backends). I'm running Varnish 2.0.6 (and not able to switch to 2.1 because of backend handling removal in varnishncsa). Best regards. Gauthier Delacroix Pictime -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 11:16:11 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 11:16:11 -0000 Subject: [Varnish] #797: VCL error on non existing DNS backend In-Reply-To: <047.26a8532e5f422e1ab4ef45d018943e08@varnish-cache.org> References: <047.26a8532e5f422e1ab4ef45d018943e08@varnish-cache.org> Message-ID: <056.c4f60060eab48458fb8d325afee9a9dc@varnish-cache.org> #797: VCL error on non existing DNS backend ----------------------------------+----------------------------------------- Reporter: gdelacroix | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: wontfix Keywords: vcl backend DNS name | ----------------------------------+----------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: We do not do runtime lookups of DNS names, so this is not going to change. Don't put DNS names you don't control into your VCL as this can cause errors as you've seen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 11:21:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 11:21:31 -0000 Subject: [Varnish] #794: varnishsizes : Say what sizes it show in desc / manpage In-Reply-To: <044.7f4426446242b5edf8778fed4e31dbf3@varnish-cache.org> References: <044.7f4426446242b5edf8778fed4e31dbf3@varnish-cache.org> Message-ID: <053.2d0c04516d14b2648c1d5fd9973593ab@varnish-cache.org> #794: varnishsizes : Say what sizes it show in desc / manpage ---------------------------+------------------------------------------------ Reporter: mandark | Owner: kristian Type: documentation | Status: new Priority: low | Milestone: Varnish 2.1 release Component: documentation | Version: trunk Severity: trivial | Keywords: varnishsizes ---------------------------+------------------------------------------------ Changes (by tfheen): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 15:13:12 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 15:13:12 -0000 Subject: [Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set In-Reply-To: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> References: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> Message-ID: <050.15cedc4cdd718c5cb984dcc7e32182e7@varnish-cache.org> #795: Conditional GETs based on modification time are not honored if Last- Modified was not explicitly set ----------------------+----------------------------------------------------- Reporter: runa | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Resolution: wontfix | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: I can see why you would want to do that, but I am not comfortable synthesizing a L-M header in Varnish by default. RFC2616 is quite clear that the only valid reasons for a backend to not offer a L-M header is A) Can't, or B) Won't. You are probably talking about the A) case, where the backend does not produce a L-M header for whatever deficient excuses it might have. I'm worried about the B) case, where the backend deliberately does not want a L-M header in order to maintain tight control of the semantic integrity of the object. In that case a synthetic L-M header may lead to wrong caching assumptions/decisions down-stream, (See p88 of RFC2616 for some legal but weird assumptions based on L-M headers) which conflict with the way the backend manages the object (purges ?). But that should not leave you stranded: If you synthesize a L-M header in VCL, I belive things will work as you expect: {{{ sub vcl_fetch { if (!beresp.http.last-modified) { set beresp.http.last-modified = beresp.http.date; } } }}} Please report back on this, so we can document this corner-case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 15:23:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 15:23:39 -0000 Subject: [Varnish] #796: ban lurker deadlock in varnish 2.1.3 In-Reply-To: <047.daacaf2481cbc4cc522f124139b268c4@varnish-cache.org> References: <047.daacaf2481cbc4cc522f124139b268c4@varnish-cache.org> Message-ID: <056.74c1e02068aef5c525c97e4d419d99c2@varnish-cache.org> #796: ban lurker deadlock in varnish 2.1.3 ---------------------------------+------------------------------------------ Reporter: ryan.krebs | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: ban lurker deadlock | ---------------------------------+------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5432]) There is a potential lock-order inversion between a worker thread and the ban-lurker and there is nothing we can do about it: They come from opposite ends of the world. Resolve this by using a TryLock in the ban-lurker and abandon the attempt if we fail to get the lock. Fixes: #796 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 18 15:25:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Oct 2010 15:25:56 -0000 Subject: [Varnish] #721: hash and client director docs. In-Reply-To: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org> References: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org> Message-ID: <051.08374559c7f431b6bbcf0b7f107ca6d6@varnish-cache.org> #721: hash and client director docs. ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: perbu | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: Forgot to close this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 21 21:33:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 21 Oct 2010 21:33:20 -0000 Subject: [Varnish] #798: backport changeset 5429 to 2.1 branch Message-ID: <044.48b0acedc14cf71a71316753f01ebf19@varnish-cache.org> #798: backport changeset 5429 to 2.1 branch ---------------------+------------------------------------------------------ Reporter: bangert | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ on Gentoo rst2man is also rst2man.py changeset #5429 to trunk fixes this http://www.varnish-cache.org/trac/changeset/5429 this also applies to 2.1.4, but no such version can be choosen from the drop down field. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 22 07:31:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Oct 2010 07:31:38 -0000 Subject: [Varnish] #798: backport changeset 5429 to 2.1 branch In-Reply-To: <044.48b0acedc14cf71a71316753f01ebf19@varnish-cache.org> References: <044.48b0acedc14cf71a71316753f01ebf19@varnish-cache.org> Message-ID: <053.4b38e8cafa72f59492c951e8de9904f6@varnish-cache.org> #798: backport changeset 5429 to 2.1 branch ----------------------+----------------------------------------------------- Reporter: bangert | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [5455]) Merge r5429: Look also for rst2man.py (for FreeBSD) Fixes #798 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 22 07:44:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Oct 2010 07:44:47 -0000 Subject: [Varnish] #791: GeoIP Plugin does not have licensing information In-Reply-To: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> References: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> Message-ID: <052.8628c17021902906b909934a7f2c94fa@varnish-cache.org> #791: GeoIP Plugin does not have licensing information ---------------------------+------------------------------------------------ Reporter: apgwoz | Owner: tfheen Type: documentation | Status: closed Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Resolution: fixed Keywords: plugin | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I've added a version with copyright and licence information to http://www .varnish-cache.org/trac/attachment/wiki/GeoipUsingInlineC/GeoIP- plugin-2.tar.gz now. If you want to port this to a vmod (for trunk), that'd be great, and we'd be happy to accept it into the source tree proper. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 22 10:58:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Oct 2010 10:58:26 -0000 Subject: [Varnish] #791: GeoIP Plugin does not have licensing information In-Reply-To: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> References: <043.c9502d89a41fe82c3d732cc437c66d90@varnish-cache.org> Message-ID: <052.b8b045f80ff499808c99d7e72fb1b4fa@varnish-cache.org> #791: GeoIP Plugin does not have licensing information ---------------------------+------------------------------------------------ Reporter: apgwoz | Owner: tfheen Type: documentation | Status: closed Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Resolution: fixed Keywords: plugin | ---------------------------+------------------------------------------------ Comment(by apgwoz): Thanks! I'll look into how to make this a vmod. I ended up building my own "module" conventions (for now), but certainly vmod is the way to go. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 22 11:33:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Oct 2010 11:33:20 -0000 Subject: [Varnish] #799: beresp.ttl = 10s * std.random(..) ==> segfaulting vcc Message-ID: <045.1a9cf3ecbf416d623b389bdac479f390@varnish-cache.org> #799: beresp.ttl = 10s * std.random(..) ==> segfaulting vcc ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Trunk, as of Oct 21. {{{ $ /opt/varnish/sbin/varnishd -f /etc/varnish/default.vcl -a :8133 -s malloc,1G -w 100,2000 -T localhost:8134 -C SMA.s0: max size 1024 MB. Running VCC-compiler failed, signal 11 }}} bt: {{{ (gdb) thread apply all bt full Thread 1 (Thread 10556): #0 0x00007f310f255513 in vcc_expr_mul (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:666 e2 = 0x0 f2 = REAL f3 = DURATION tk = 0x7f310e05a7c0 __func__ = "vcc_expr_mul" #1 0x00007f310f255625 in vcc_expr_add (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:689 e2 = 0x7f31fbad8001 f2 = 32561 tk = 0x7f310e66f5c2 __func__ = "vcc_expr_add" #2 0x00007f310f255bb5 in vcc_expr_cmp (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:803 e2 = 0x7fffe76ac8c0 cp = 0x3000000028 buf = "\000\310j\347\377\177\000\000\000\000\000\000\000\000\000\000\n\000\000\000\n\000\000\000\300\246\005\016\061\177\000\000\377\377\377\377\377\177\000\000\214yg\017\061\177\000\000\353\341%\017\061\177\000\000\300\357\227\016\061\177\000\000\000\000\000\000\000\000\000\000\300\310j\347\377\177\000\000\000\310j\347\377\177\000\000\000P\005\016\000\000\000\000\270\261\251\017\061\177\000\000`V\005\016\061\177\000\000\006\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\352\341%\017\061\177\000\000\001\001\001\001\000\000\000\000\211\223\004\016\061\177\000\000\260\310j\347\377\177\000\000\360\242@\000\000\000\000\000\200\360j\347\377\177\000\000\000\000\000\000\000\000\000\000\205wg\017\061\177\000\000\240\310j\347\377\177\000\000\340\310j\347\377\177\000\000\n\321%\017\061\177\000\000 \353\001\016\061\177\000\000 \000\000\000\060\000\000\000\320\311j\347\377\177\000\000\000\311j\347\377\177\000\000\300\246\005\016\025\000\000" re = 0x0 not = 0x7f310f250000 "" tk = 0x7fffe76ac7e0 __func__ = "vcc_expr_cmp" #3 0x00007f310f2564f8 in vcc_expr_not (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:901 e2 = 0x7f310e01f540 tk = 0x7fffe76ac900 #4 0x00007f310f256615 in vcc_expr_cand (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:931 e2 = 0x40425f5244 tk = 0x7f310f25d0e4 #5 0x00007f310f2567e0 in vcc_expr0 (tl=0x7f310e01f540, e=0x7fffe76ac9a8, fmt=DURATION) at vcc_expr.c:966 e2 = 0x7f310f25a707 tk = 0x7fffe76ac9c0 #6 0x00007f310f2569e8 in vcc_Expr (tl=0x7f310e01f540, fmt=DURATION) at vcc_expr.c:1004 e = 0x7f310e056250 t1 = 0x7f310e05a740 __func__ = "vcc_Expr" #7 0x00007f310f249e9b in parse_set (tl=0x7f310e01f540) at vcc_action.c:152 vp = 0x7f310f467928 ap = 0x7f310f25d0c0 fmt = DURATION __func__ = "parse_set" #8 0x00007f310f24ae2f in vcc_ParseAction (tl=0x7f310e01f540) at vcc_action.c:446 at = 0x7f310e05a680 ---Type to continue, or q to quit--- atp = 0x7f310f4684d0 sym = 0x7f310e02f000 __func__ = "vcc_ParseAction" #9 0x00007f310f2571ab in vcc_Compound (tl=0x7f310e01f540) at vcc_parse.c:174 i = 1 #10 0x00007f310f257579 in vcc_Function (tl=0x7f310e01f540) at vcc_parse.c:230 m = 6 __func__ = "vcc_Function" #11 0x00007f310f25770e in vcc_Parse (tl=0x7f310e01f540) at vcc_parse.c:287 tp = 0x7f310f468610 #12 0x00007f310f250602 in vcc_CompileSource (tl0=0x7f310e01f380, sb=0x7f310e01e910, sp=0x7f310e05aa00) at vcc_compile.c:608 tl = 0x7f310e01f540 sym = 0x7f310e04ea80 v = 0x7f310f467d50 of = 0x7f310f25e97d "input" i = 32561 __func__ = "vcc_CompileSource" #13 0x00007f310f250a86 in VCC_Compile (tl=0x7f310e01f380, sb=0x7f310e01e910, b=0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"...) at vcc_compile.c:686 sp = 0x7f310e01b8c0 r = 0x101010101010101
#14 0x0000000000446b62 in run_vcc (priv=0x7fffe76acd40) at mgt_vcc.c:149 csrc = 0x1
sb = 0x7f310e01e910 vp = 0x7fffe76acd40 fd = 0 i = 10553 l = 0 __func__ = "run_vcc" #15 0x00007f310f6705a9 in SUB_run (sb=0x7f310e01e8e0, func=0x446aac , priv=0x7fffe76acd40, name=0x4709bf "VCC-compiler", maxlines=-1) at subproc.c:104 rv = 0 p = {3, 4} sfd = 100 status = 32561 pid = 0 vlu = 0x0 sp = {name = 0x4709bf "VCC-compiler", sb = 0x7f310e01e8e0, lines = 0, maxlines = -1} __func__ = "SUB_run" #16 0x0000000000446f4c in mgt_run_cc ( vcl=0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"..., sb=0x7f310e01e8e0, C_flag=1) at mgt_vcc.c:251 csrc = 0x4
cmdsb = 0x10 sf = "./vcl.1P9zoqAU.c" of = "\270\261\251\017\061\177\000\000u\364j\347\377\177\000\000\300", ---Type to continue, or q to quit--- retval = 0x20
sfd = 3 i = 234910192 vp = {sf = 0x7fffe76acd90 "./vcl.1P9zoqAU.c", vcl = 0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"...} __func__ = "mgt_run_cc" #17 0x00000000004471c7 in mgt_VccCompile (sb=0x7fffe76ace50, b=0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"..., C_flag=1) at mgt_vcc.c:301 vf = 0x7f310e004460 "/opt/varnish/var/varnish/luke/" __func__ = "mgt_VccCompile" #18 0x00000000004475e1 in mgt_vcc_default (b_arg=0x0, f_arg=0x7fffe76af475 "/etc/varnish/default.vcl", vcl=0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"..., C_flag=1) at mgt_vcc.c:391 vf = 0x0 sb = 0x7f310e01e8e0 vp = 0x7fffe76aef08 buf = "boot\000varnish/var/varnish/luke/\000ons\000\000t\000\000pages\000\000ve\000\000\000t\000\000\000\000\065\n", '\000' , "\032\234\210\017\061\177\000\000\000\000\000\000\000\000\000\000@\330j\347\377\177\000\000\000\000\000\000\000\000\000\000(<\247\017\061\177\000\000\330\331j\347\377\177\000\000\f\000\000\000\000\000\000\000p\261\232|\000\000\000\000\264\246\210\017\061\177\000\000\000\000\000\000\000\000\000\000\305j\362\001\000\000\000\000\060\000\000\000\000\000\000\000tT`\016\061\177\000\000\000\000\000\000\000\000\000\000@\330j\347\377\177\000\000 at l`\016\061\177\000\000,\rq\016\061\177\000\000\000@\000\000\016\000\000\000,\rq\016\061\177\000\000\000"... __func__ = "mgt_vcc_default" #19 0x00000000004533a9 in main (argc=0, argv=0x7fffe76af0e8) at varnishd.c:592 o = -1 C_flag = 1 F_flag = 0 b_arg = 0x0 f_arg = 0x7fffe76af475 "/etc/varnish/default.vcl" i_arg = 0x0 l_arg = 0x0 h_arg = 0x4733c9 "critbit" M_arg = 0x0 n_arg = 0x0 P_arg = 0x0 S_arg = 0x0 s_arg = 0x4733d1 "file" s_arg_given = 1 T_arg = 0x7fffe76af4b3 "localhost:8134" p = 0x7fffe76aef5f "" vcl = 0x7f310e02f000 "# This is a basic VCL configuration file for varnish. See the vcl(7)\n# man page for details on VCL syntax and semantics.\n# \n# Default backend definition. Set this to point to your content\n# server.\n"... cli = {{magic = 0, sb = 0x7f310e01e4c0, result = CLIS_OK, cmd = 0x0, auth = 0, challenge = '\000' , ident = 0x0, vlu = 0x0, cls = 0x0}} pfh = 0x0 dirname = 0x7f310e004460 "/opt/varnish/var/varnish/luke/" ---Type to continue, or q to quit--- __func__ = "main" (gdb) }}} Relevant bit of vcl: {{{ sub vcl_fetch { unset beresp.http.Set-Cookie; set beresp.ttl = 30s * std.random(1,10); } }}} . -- Ticket URL: Varnish The Varnish HTTP Accelerator From darvin.denmian at gmail.com Fri Oct 22 12:51:09 2010 From: darvin.denmian at gmail.com (Darvin Denmian) Date: Fri, 22 Oct 2010 10:51:09 -0200 Subject: Varnish-2.1.4 Compiling Error Message-ID: Hello, I'm trying to generate a RPM package of varnish-2.1.4 in a CentOS-5.5 OS, 64bits. When I execute the command: rpmbuild -ba redhat/varnish.spec I got the following message: #### top macro def tmpdir=/tmp/vtc.23005.6b8b4567 #### top macro def bad_ip=10.255.255.255 # top TEST ././tests/v00017.vtc starting # top TEST VCL compiler coverage test: vcc_acl.c ## v1 Launch ### v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.23005.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.23005.6b8b4567/v1/_S -M '127.0.0.1 33880' -P /tmp/vtc.23005.6b8b4567/v1/varnishd.pid -sfile,/tmp/vtc.23005.6b8b4567/v1,10M ### v1 debug| storage_file: filename: /tmp/vtc.23005.6b8b4567/v1/varnish.PkiJW9 size 10 MB.\n ### v1 debug| Creating new SHMFILE\n ### v1 debug| Varnish on Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n ### v1 debug| 200 239 \n ### v1 debug| -----------------------------\n ### v1 debug| Varnish HTTP accelerator CLI.\n ### v1 debug| -----------------------------\n ### v1 debug| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n ### v1 debug| \n ### v1 debug| Type 'help' for command list.\n ### v1 debug| Type 'quit' to close CLI session.\n ### v1 debug| Type 'start' to launch worker process.\n ### v1 debug| \n ### v1 CLI connection fd = 4 ### v1 CLI RX 107 #### v1 CLI RX| ukncxlgzzoupwmsbtoxfavbapdvsnxoj\n #### v1 CLI RX| \n #### v1 CLI RX| Authentication required.\n #### v1 CLI TX| auth 5bd6fb73ae081b54a8f6324801f50f9536e8981a9b6594fb22b496ef8b069ae7\n ### v1 CLI RX 200 #### v1 CLI RX| -----------------------------\n #### v1 CLI RX| Varnish HTTP accelerator CLI.\n #### v1 CLI RX| -----------------------------\n #### v1 CLI RX| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n #### v1 CLI RX| \n #### v1 CLI RX| Type 'help' for command list.\n #### v1 CLI RX| Type 'quit' to close CLI session.\n #### v1 CLI RX| Type 'start' to launch worker process.\n #### v1 CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 106 #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos 28)\n #### v1 CLI RX| acl a { "10.1.2.3"/33; }\n #### v1 CLI RX| ---------------------------##---\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 106 #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos 24)\n #### v1 CLI RX| acl a { "1::2"/129; }\n #### v1 CLI RX| -----------------------###---\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 200 #### v1 CLI RX| VCL compiled. #### v1 CLI TX| vcl.use vcl3 ### v1 CLI RX 200 #### v1 CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 106 #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Conflicting ACL entries:\n #### v1 CLI RX| (input Line 4 Pos 17)\n #### v1 CLI RX| "1.2.3.4";\n #### v1 CLI RX| ----------------#########-\n #### v1 CLI RX| vs:\n #### v1 CLI RX| (input Line 5 Pos 18)\n #### v1 CLI RX| !"1.2.3.4";\n #### v1 CLI RX| -----------------#########-\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"...com\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 106 #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| DNS lookup(...com): Name or service not known\n #### v1 CLI RX| (input Line 3 Pos 17)\n #### v1 CLI RX| acl a { "...com"; }\n #### v1 CLI RX| ----------------########---\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 200 #### v1 CLI RX| VCL compiled. ---- v1 VCL compilation got 200 expected 106 # top Test timed out # top TEST ././tests/v00017.vtc FAILED FAIL: ./tests/v00017.vtc # top TEST ././tests/v00018.vtc passed (2.138s) ... ============================================== 1 of 192 tests failed Please report to varnish-dev at varnish-cache.org ============================================== Can somebody help me with this? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdzstz at gmail.com Fri Oct 22 16:52:43 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Fri, 22 Oct 2010 18:52:43 +0200 Subject: Varnish-2.1.4 Compiling Error In-Reply-To: References: Message-ID: Hello, In the past I had the same problem in a Solaris instaled in 10.255.255.255 network, I think I changed the IP from varnish source and changed to other bad ip (255.255.255.255). I cannot send my fix, because I have not the sources of that installation. 2010/10/22 Darvin Denmian > Hello, > > I'm trying to generate a RPM package of varnish-2.1.4 in a CentOS-5.5 OS, > 64bits. > When I execute the command: > > rpmbuild -ba redhat/varnish.spec > > I got the following message: > > #### top macro def tmpdir=/tmp/vtc.23005.6b8b4567 > #### top macro def bad_ip=10.255.255.255 > # top TEST ././tests/v00017.vtc starting > # top TEST VCL compiler coverage test: vcc_acl.c > ## v1 Launch > ### v1 CMD: cd ../varnishd && ./varnishd -d -d -n > /tmp/vtc.23005.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a > '127.0.0.1:0' -S /tmp/vtc.23005.6b8b4567/v1/_S -M '127.0.0.1 33880' -P > /tmp/vtc.23005.6b8b4567/v1/varnishd.pid > -sfile,/tmp/vtc.23005.6b8b4567/v1,10M > ### v1 debug| storage_file: filename: > /tmp/vtc.23005.6b8b4567/v1/varnish.PkiJW9 size 10 MB.\n > ### v1 debug| Creating new SHMFILE\n > ### v1 debug| Varnish on Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n > ### v1 debug| 200 239 \n > ### v1 debug| -----------------------------\n > ### v1 debug| Varnish HTTP accelerator CLI.\n > ### v1 debug| -----------------------------\n > ### v1 debug| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n > ### v1 debug| \n > ### v1 debug| Type 'help' for command list.\n > ### v1 debug| Type 'quit' to close CLI session.\n > ### v1 debug| Type 'start' to launch worker process.\n > ### v1 debug| \n > ### v1 CLI connection fd = 4 > ### v1 CLI RX 107 > #### v1 CLI RX| ukncxlgzzoupwmsbtoxfavbapdvsnxoj\n > #### v1 CLI RX| \n > #### v1 CLI RX| Authentication required.\n > #### v1 CLI TX| auth > 5bd6fb73ae081b54a8f6324801f50f9536e8981a9b6594fb22b496ef8b069ae7\n > ### v1 CLI RX 200 > #### v1 CLI RX| -----------------------------\n > #### v1 CLI RX| Varnish HTTP accelerator CLI.\n > #### v1 CLI RX| -----------------------------\n > #### v1 CLI RX| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n > #### v1 CLI RX| \n > #### v1 CLI RX| Type 'help' for command list.\n > #### v1 CLI RX| Type 'quit' to close CLI session.\n > #### v1 CLI RX| Type 'start' to launch worker process.\n > #### v1 CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { > return(pass); } }\n" > ### v1 CLI RX 106 > #### v1 CLI RX| Message from VCC-compiler:\n > #### v1 CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos > 28)\n > #### v1 CLI RX| acl a { "10.1.2.3"/33; }\n > #### v1 CLI RX| ---------------------------##---\n > #### v1 CLI RX| Running VCC-compiler failed, exit 1\n > #### v1 CLI RX| VCL compilation failed > ## v1 VCL compilation failed (as expected) > #### v1 CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { > return(pass); } }\n" > ### v1 CLI RX 106 > #### v1 CLI RX| Message from VCC-compiler:\n > #### v1 CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos > 24)\n > #### v1 CLI RX| acl a { "1::2"/129; }\n > #### v1 CLI RX| -----------------------###---\n > #### v1 CLI RX| Running VCC-compiler failed, exit 1\n > #### v1 CLI RX| VCL compilation failed > ## v1 VCL compilation failed (as expected) > #### v1 CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv > { if (client.ip ~ a) { return(pass); } }\n" > ### v1 CLI RX 200 > #### v1 CLI RX| VCL compiled. > #### v1 CLI TX| vcl.use vcl3 > ### v1 CLI RX 200 > #### v1 CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if > (client.ip ~ a) { return(pass); } }\n" > ### v1 CLI RX 106 > #### v1 CLI RX| Message from VCC-compiler:\n > #### v1 CLI RX| Conflicting ACL entries:\n > #### v1 CLI RX| (input Line 4 Pos 17)\n > #### v1 CLI RX| "1.2.3.4";\n > #### v1 CLI RX| ----------------#########-\n > #### v1 CLI RX| vs:\n > #### v1 CLI RX| (input Line 5 Pos 18)\n > #### v1 CLI RX| !"1.2.3.4";\n > #### v1 CLI RX| -----------------#########-\n > #### v1 CLI RX| Running VCC-compiler failed, exit 1\n > #### v1 CLI RX| VCL compilation failed > ## v1 VCL compilation failed (as expected) > #### v1 CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a { \"...com\"; }\n\tsub vcl_recv { if (client.ip ~ a) { > return(pass); } }\n" > ### v1 CLI RX 106 > #### v1 CLI RX| Message from VCC-compiler:\n > #### v1 CLI RX| DNS lookup(...com): Name or service not known\n > #### v1 CLI RX| (input Line 3 Pos 17)\n > #### v1 CLI RX| acl a { "...com"; }\n > #### v1 CLI RX| ----------------########---\n > #### v1 CLI RX| Running VCC-compiler failed, exit 1\n > #### v1 CLI RX| VCL compilation failed > ## v1 VCL compilation failed (as expected) > #### v1 CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; > }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { > return(pass); } }\n" > ### v1 CLI RX 200 > #### v1 CLI RX| VCL compiled. > ---- v1 VCL compilation got 200 expected 106 > # top Test timed out > # top TEST ././tests/v00017.vtc FAILED > FAIL: ./tests/v00017.vtc > # top TEST ././tests/v00018.vtc passed (2.138s) > > ... > > ============================================== > 1 of 192 tests failed > Please report to varnish-dev at varnish-cache.org > ============================================== > > Can somebody help me with this? > > Thanks ! > > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at varnish-cache.org > http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darvin.denmian at gmail.com Fri Oct 22 16:56:42 2010 From: darvin.denmian at gmail.com (Darvin Denmian) Date: Fri, 22 Oct 2010 14:56:42 -0200 Subject: Varnish-2.1.4 Compiling Error In-Reply-To: References: Message-ID: Jorge, I'll try the proposed solution ! Thanks for your reply. On Fri, Oct 22, 2010 at 2:52 PM, Jorge D?az wrote: > > Hello, > > In the past I had the same problem in a Solaris instaled in 10.255.255.255 network,?I think I changed the IP from varnish source and changed to other bad ip?(255.255.255.255). > > I cannot send my fix, because I have not the sources of that installation. > > 2010/10/22 Darvin Denmian >> >> Hello, >> >> I'm trying to generate a RPM package of varnish-2.1.4 in a CentOS-5.5 OS, 64bits. >> When I execute the command: >> >> ?? rpmbuild -ba redhat/varnish.spec >> >> I got the following message: >> >> #### top? macro def tmpdir=/tmp/vtc.23005.6b8b4567 >> #### top? macro def bad_ip=10.255.255.255 >> #??? top? TEST ././tests/v00017.vtc starting >> #??? top? TEST VCL compiler coverage test: vcc_acl.c >> ##?? v1?? Launch >> ###? v1?? CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.23005.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.23005.6b8b4567/v1/_S -M '127.0.0.1 33880' -P /tmp/vtc.23005.6b8b4567/v1/varnishd.pid -sfile,/tmp/vtc.23005.6b8b4567/v1,10M >> ###? v1?? debug| storage_file: filename: /tmp/vtc.23005.6b8b4567/v1/varnish.PkiJW9 size 10 MB.\n >> ###? v1?? debug| Creating new SHMFILE\n >> ###? v1?? debug| Varnish on Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >> ###? v1?? debug| 200 239???? \n >> ###? v1?? debug| -----------------------------\n >> ###? v1?? debug| Varnish HTTP accelerator CLI.\n >> ###? v1?? debug| -----------------------------\n >> ###? v1?? debug| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >> ###? v1?? debug| \n >> ###? v1?? debug| Type 'help' for command list.\n >> ###? v1?? debug| Type 'quit' to close CLI session.\n >> ###? v1?? debug| Type 'start' to launch worker process.\n >> ###? v1?? debug| \n >> ###? v1?? CLI connection fd = 4 >> ###? v1?? CLI RX? 107 >> #### v1?? CLI RX| ukncxlgzzoupwmsbtoxfavbapdvsnxoj\n >> #### v1?? CLI RX| \n >> #### v1?? CLI RX| Authentication required.\n >> #### v1?? CLI TX| auth 5bd6fb73ae081b54a8f6324801f50f9536e8981a9b6594fb22b496ef8b069ae7\n >> ###? v1?? CLI RX? 200 >> #### v1?? CLI RX| -----------------------------\n >> #### v1?? CLI RX| Varnish HTTP accelerator CLI.\n >> #### v1?? CLI RX| -----------------------------\n >> #### v1?? CLI RX| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >> #### v1?? CLI RX| \n >> #### v1?? CLI RX| Type 'help' for command list.\n >> #### v1?? CLI RX| Type 'quit' to close CLI session.\n >> #### v1?? CLI RX| Type 'start' to launch worker process.\n >> #### v1?? CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 106 >> #### v1?? CLI RX| Message from VCC-compiler:\n >> #### v1?? CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos 28)\n >> #### v1?? CLI RX|???????? acl a { "10.1.2.3"/33; }\n >> #### v1?? CLI RX| ---------------------------##---\n >> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >> #### v1?? CLI RX| VCL compilation failed >> ##?? v1?? VCL compilation failed (as expected) >> #### v1?? CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 106 >> #### v1?? CLI RX| Message from VCC-compiler:\n >> #### v1?? CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos 24)\n >> #### v1?? CLI RX|???????? acl a { "1::2"/129; }\n >> #### v1?? CLI RX| -----------------------###---\n >> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >> #### v1?? CLI RX| VCL compilation failed >> ##?? v1?? VCL compilation failed (as expected) >> #### v1?? CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 200 >> #### v1?? CLI RX| VCL compiled. >> #### v1?? CLI TX| vcl.use vcl3 >> ###? v1?? CLI RX? 200 >> #### v1?? CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 106 >> #### v1?? CLI RX| Message from VCC-compiler:\n >> #### v1?? CLI RX| Conflicting ACL entries:\n >> #### v1?? CLI RX| (input Line 4 Pos 17)\n >> #### v1?? CLI RX|???????????????? "1.2.3.4";\n >> #### v1?? CLI RX| ----------------#########-\n >> #### v1?? CLI RX| vs:\n >> #### v1?? CLI RX| (input Line 5 Pos 18)\n >> #### v1?? CLI RX|???????????????? !"1.2.3.4";\n >> #### v1?? CLI RX| -----------------#########-\n >> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >> #### v1?? CLI RX| VCL compilation failed >> ##?? v1?? VCL compilation failed (as expected) >> #### v1?? CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"...com\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 106 >> #### v1?? CLI RX| Message from VCC-compiler:\n >> #### v1?? CLI RX| DNS lookup(...com): Name or service not known\n >> #### v1?? CLI RX| (input Line 3 Pos 17)\n >> #### v1?? CLI RX|???????? acl a { "...com"; }\n >> #### v1?? CLI RX| ----------------########---\n >> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >> #### v1?? CLI RX| VCL compilation failed >> ##?? v1?? VCL compilation failed (as expected) >> #### v1?? CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >> ###? v1?? CLI RX? 200 >> #### v1?? CLI RX| VCL compiled. >> ---- v1?? VCL compilation got 200 expected 106 >> #??? top? Test timed out >> #??? top? TEST ././tests/v00017.vtc FAILED >> FAIL: ./tests/v00017.vtc >> #??? top? TEST ././tests/v00018.vtc passed (2.138s) >> >> ... >> >> ============================================== >> 1 of 192 tests failed >> Please report to varnish-dev at varnish-cache.org >> ============================================== >> >> Can somebody help me with this? >> >> Thanks ! >> >> _______________________________________________ >> varnish-bugs mailing list >> varnish-bugs at varnish-cache.org >> http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > From varnish-bugs at varnish-cache.org Fri Oct 22 18:53:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Oct 2010 18:53:05 -0000 Subject: [Varnish] #799: beresp.ttl = 10s * std.random(..) ==> segfaulting vcc In-Reply-To: <045.1a9cf3ecbf416d623b389bdac479f390@varnish-cache.org> References: <045.1a9cf3ecbf416d623b389bdac479f390@varnish-cache.org> Message-ID: <054.856cfeccc8b7467d28b003bcd4f06142@varnish-cache.org> #799: beresp.ttl = 10s * std.random(..) ==> segfaulting vcc ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5458]) Don't assert the format until we have done the error check. The ticket (#799) probably triggers this by using std.random() without a "import std" statement. Fixes: #799 -- Ticket URL: Varnish The Varnish HTTP Accelerator From renato at luren.com.br Fri Oct 22 18:59:25 2010 From: renato at luren.com.br (Renato Farias) Date: Fri, 22 Oct 2010 16:59:25 -0200 (BRST) Subject: Varnish-2.1.4 Compiling Error Message-ID: Hi Darvin, Can you send you source? I want to try it. hugs Att, Renato Farias >---- Original Message ---- >From: Darvin Denmian >To: "Jorge D?az" >Cc: varnish-bugs at varnish-cache.org >Sent: Fri, Oct 22, 2010, 2:56 PM >Subject: Re: Varnish-2.1.4 Compiling Error > >Jorge, > >I'll try the proposed solution ! Thanks for your reply. > >On Fri, Oct 22, 2010 at 2:52 PM, Jorge D?az wrote: >> >> Hello, >> >> In the past I had the same problem in a Solaris instaled in 10.255.255.255 network,?I think I changed the IP from varnish source and changed to other bad ip?(255.255.255.255). >> >> I cannot send my fix, because I have not the sources of that installation. >> >> 2010/10/22 Darvin Denmian >>> >>> Hello, >>> >>> I'm trying to generate a RPM package of varnish-2.1.4 in a CentOS-5.5 OS, 64bits. >>> When I execute the command: >>> >>> ?? rpmbuild -ba redhat/varnish.spec >>> >>> I got the following message: >>> >>> #### top? macro def tmpdir=/tmp/vtc.23005.6b8b4567 >>> #### top? macro def bad_ip=10.255.255.255 >>> #??? top? TEST ././tests/v00017.vtc starting >>> #??? top? TEST VCL compiler coverage test: vcc_acl.c >>> ##?? v1?? Launch >>> ###? v1?? CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.23005.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.23005.6b8b4567/v1/_S -M '127.0.0.1 33880' -P /tmp/vtc.23005.6b8b4567/v1/varnishd.pid -sfile,/tmp/vtc.23005.6b8b4567/v1,10M >>> ###? v1?? debug| storage_file: filename: /tmp/vtc.23005.6b8b4567/v1/varnish.PkiJW9 size 10 MB.\n >>> ###? v1?? debug| Creating new SHMFILE\n >>> ###? v1?? debug| Varnish on Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>> ###? v1?? debug| 200 239???? \n >>> ###? v1?? debug| -----------------------------\n >>> ###? v1?? debug| Varnish HTTP accelerator CLI.\n >>> ###? v1?? debug| -----------------------------\n >>> ###? v1?? debug| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>> ###? v1?? debug| \n >>> ###? v1?? debug| Type 'help' for command list.\n >>> ###? v1?? debug| Type 'quit' to close CLI session.\n >>> ###? v1?? debug| Type 'start' to launch worker process.\n >>> ###? v1?? debug| \n >>> ###? v1?? CLI connection fd = 4 >>> ###? v1?? CLI RX? 107 >>> #### v1?? CLI RX| ukncxlgzzoupwmsbtoxfavbapdvsnxoj\n >>> #### v1?? CLI RX| \n >>> #### v1?? CLI RX| Authentication required.\n >>> #### v1?? CLI TX| auth 5bd6fb73ae081b54a8f6324801f50f9536e8981a9b6594fb22b496ef8b069ae7\n >>> ###? v1?? CLI RX? 200 >>> #### v1?? CLI RX| -----------------------------\n >>> #### v1?? CLI RX| Varnish HTTP accelerator CLI.\n >>> #### v1?? CLI RX| -----------------------------\n >>> #### v1?? CLI RX| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>> #### v1?? CLI RX| \n >>> #### v1?? CLI RX| Type 'help' for command list.\n >>> #### v1?? CLI RX| Type 'quit' to close CLI session.\n >>> #### v1?? CLI RX| Type 'start' to launch worker process.\n >>> #### v1?? CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 106 >>> #### v1?? CLI RX| Message from VCC-compiler:\n >>> #### v1?? CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos 28)\n >>> #### v1?? CLI RX|???????? acl a { "10.1.2.3"/33; }\n >>> #### v1?? CLI RX| ---------------------------##---\n >>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>> #### v1?? CLI RX| VCL compilation failed >>> ##?? v1?? VCL compilation failed (as expected) >>> #### v1?? CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 106 >>> #### v1?? CLI RX| Message from VCC-compiler:\n >>> #### v1?? CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos 24)\n >>> #### v1?? CLI RX|???????? acl a { "1::2"/129; }\n >>> #### v1?? CLI RX| -----------------------###---\n >>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>> #### v1?? CLI RX| VCL compilation failed >>> ##?? v1?? VCL compilation failed (as expected) >>> #### v1?? CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 200 >>> #### v1?? CLI RX| VCL compiled. >>> #### v1?? CLI TX| vcl.use vcl3 >>> ###? v1?? CLI RX? 200 >>> #### v1?? CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 106 >>> #### v1?? CLI RX| Message from VCC-compiler:\n >>> #### v1?? CLI RX| Conflicting ACL entries:\n >>> #### v1?? CLI RX| (input Line 4 Pos 17)\n >>> #### v1?? CLI RX|???????????????? "1.2.3.4";\n >>> #### v1?? CLI RX| ----------------#########-\n >>> #### v1?? CLI RX| vs:\n >>> #### v1?? CLI RX| (input Line 5 Pos 18)\n >>> #### v1?? CLI RX|???????????????? !"1.2.3.4";\n >>> #### v1?? CLI RX| -----------------#########-\n >>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>> #### v1?? CLI RX| VCL compilation failed >>> ##?? v1?? VCL compilation failed (as expected) >>> #### v1?? CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"...com\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 106 >>> #### v1?? CLI RX| Message from VCC-compiler:\n >>> #### v1?? CLI RX| DNS lookup(...com): Name or service not known\n >>> #### v1?? CLI RX| (input Line 3 Pos 17)\n >>> #### v1?? CLI RX|???????? acl a { "...com"; }\n >>> #### v1?? CLI RX| ----------------########---\n >>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>> #### v1?? CLI RX| VCL compilation failed >>> ##?? v1?? VCL compilation failed (as expected) >>> #### v1?? CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>> ###? v1?? CLI RX? 200 >>> #### v1?? CLI RX| VCL compiled. >>> ---- v1?? VCL compilation got 200 expected 106 >>> #??? top? Test timed out >>> #??? top? TEST ././tests/v00017.vtc FAILED >>> FAIL: ./tests/v00017.vtc >>> #??? top? TEST ././tests/v00018.vtc passed (2.138s) >>> >>> ... >>> >>> ============================================== >>> 1 of 192 tests failed >>> Please report to varnish-dev at varnish-cache.org >>> ============================================== >>> >>> Can somebody help me with this? >>> >>> Thanks ! >>> >>> _______________________________________________ >>> varnish-bugs mailing list >>> varnish-bugs at varnish-cache.org >>> http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs >> > >_______________________________________________ >varnish-bugs mailing list >varnish-bugs at varnish-cache.org >http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs From darvin.denmian at gmail.com Fri Oct 22 19:10:54 2010 From: darvin.denmian at gmail.com (Darvin Denmian) Date: Fri, 22 Oct 2010 17:10:54 -0200 Subject: Varnish-2.1.4 Compiling Error In-Reply-To: References: Message-ID: Hello, I found the solution in this link: http://www.varnish-cache.org/trac/ticket/692#comment:1 On Fri, Oct 22, 2010 at 4:59 PM, Renato Farias wrote: > Hi Darvin, > > Can you send you source? > > I want to try it. > > hugs > > Att, > > Renato Farias > >>---- Original Message ---- >>From: Darvin Denmian >>To: "Jorge D?az" >>Cc: varnish-bugs at varnish-cache.org >>Sent: Fri, Oct 22, 2010, 2:56 PM >>Subject: Re: Varnish-2.1.4 Compiling Error >> >>Jorge, >> >>I'll try the proposed solution ! Thanks for your reply. >> >>On Fri, Oct 22, 2010 at 2:52 PM, Jorge D?az wrote: >>> >>> Hello, >>> >>> In the past I had the same problem in a Solaris instaled in 10.255.255.255 network,?I think I changed the IP from varnish source and changed to other bad ip?(255.255.255.255). >>> >>> I cannot send my fix, because I have not the sources of that installation. >>> >>> 2010/10/22 Darvin Denmian >>>> >>>> Hello, >>>> >>>> I'm trying to generate a RPM package of varnish-2.1.4 in a CentOS-5.5 OS, 64bits. >>>> When I execute the command: >>>> >>>> ?? rpmbuild -ba redhat/varnish.spec >>>> >>>> I got the following message: >>>> >>>> #### top? macro def tmpdir=/tmp/vtc.23005.6b8b4567 >>>> #### top? macro def bad_ip=10.255.255.255 >>>> #??? top? TEST ././tests/v00017.vtc starting >>>> #??? top? TEST VCL compiler coverage test: vcc_acl.c >>>> ##?? v1?? Launch >>>> ###? v1?? CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.23005.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.23005.6b8b4567/v1/_S -M '127.0.0.1 33880' -P /tmp/vtc.23005.6b8b4567/v1/varnishd.pid -sfile,/tmp/vtc.23005.6b8b4567/v1,10M >>>> ###? v1?? debug| storage_file: filename: /tmp/vtc.23005.6b8b4567/v1/varnish.PkiJW9 size 10 MB.\n >>>> ###? v1?? debug| Creating new SHMFILE\n >>>> ###? v1?? debug| Varnish on Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>>> ###? v1?? debug| 200 239???? \n >>>> ###? v1?? debug| -----------------------------\n >>>> ###? v1?? debug| Varnish HTTP accelerator CLI.\n >>>> ###? v1?? debug| -----------------------------\n >>>> ###? v1?? debug| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>>> ###? v1?? debug| \n >>>> ###? v1?? debug| Type 'help' for command list.\n >>>> ###? v1?? debug| Type 'quit' to close CLI session.\n >>>> ###? v1?? debug| Type 'start' to launch worker process.\n >>>> ###? v1?? debug| \n >>>> ###? v1?? CLI connection fd = 4 >>>> ###? v1?? CLI RX? 107 >>>> #### v1?? CLI RX| ukncxlgzzoupwmsbtoxfavbapdvsnxoj\n >>>> #### v1?? CLI RX| \n >>>> #### v1?? CLI RX| Authentication required.\n >>>> #### v1?? CLI TX| auth 5bd6fb73ae081b54a8f6324801f50f9536e8981a9b6594fb22b496ef8b069ae7\n >>>> ###? v1?? CLI RX? 200 >>>> #### v1?? CLI RX| -----------------------------\n >>>> #### v1?? CLI RX| Varnish HTTP accelerator CLI.\n >>>> #### v1?? CLI RX| -----------------------------\n >>>> #### v1?? CLI RX| Linux,2.6.18-194.el5,x86_64,-sfile,-hcritbit\n >>>> #### v1?? CLI RX| \n >>>> #### v1?? CLI RX| Type 'help' for command list.\n >>>> #### v1?? CLI RX| Type 'quit' to close CLI session.\n >>>> #### v1?? CLI RX| Type 'start' to launch worker process.\n >>>> #### v1?? CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 106 >>>> #### v1?? CLI RX| Message from VCC-compiler:\n >>>> #### v1?? CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos 28)\n >>>> #### v1?? CLI RX|???????? acl a { "10.1.2.3"/33; }\n >>>> #### v1?? CLI RX| ---------------------------##---\n >>>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>>> #### v1?? CLI RX| VCL compilation failed >>>> ##?? v1?? VCL compilation failed (as expected) >>>> #### v1?? CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 106 >>>> #### v1?? CLI RX| Message from VCC-compiler:\n >>>> #### v1?? CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos 24)\n >>>> #### v1?? CLI RX|???????? acl a { "1::2"/129; }\n >>>> #### v1?? CLI RX| -----------------------###---\n >>>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>>> #### v1?? CLI RX| VCL compilation failed >>>> ##?? v1?? VCL compilation failed (as expected) >>>> #### v1?? CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 200 >>>> #### v1?? CLI RX| VCL compiled. >>>> #### v1?? CLI TX| vcl.use vcl3 >>>> ###? v1?? CLI RX? 200 >>>> #### v1?? CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 106 >>>> #### v1?? CLI RX| Message from VCC-compiler:\n >>>> #### v1?? CLI RX| Conflicting ACL entries:\n >>>> #### v1?? CLI RX| (input Line 4 Pos 17)\n >>>> #### v1?? CLI RX|???????????????? "1.2.3.4";\n >>>> #### v1?? CLI RX| ----------------#########-\n >>>> #### v1?? CLI RX| vs:\n >>>> #### v1?? CLI RX| (input Line 5 Pos 18)\n >>>> #### v1?? CLI RX|???????????????? !"1.2.3.4";\n >>>> #### v1?? CLI RX| -----------------#########-\n >>>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>>> #### v1?? CLI RX| VCL compilation failed >>>> ##?? v1?? VCL compilation failed (as expected) >>>> #### v1?? CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"...com\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 106 >>>> #### v1?? CLI RX| Message from VCC-compiler:\n >>>> #### v1?? CLI RX| DNS lookup(...com): Name or service not known\n >>>> #### v1?? CLI RX| (input Line 3 Pos 17)\n >>>> #### v1?? CLI RX|???????? acl a { "...com"; }\n >>>> #### v1?? CLI RX| ----------------########---\n >>>> #### v1?? CLI RX| Running VCC-compiler failed, exit 1\n >>>> #### v1?? CLI RX| VCL compilation failed >>>> ##?? v1?? VCL compilation failed (as expected) >>>> #### v1?? CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" >>>> ###? v1?? CLI RX? 200 >>>> #### v1?? CLI RX| VCL compiled. >>>> ---- v1?? VCL compilation got 200 expected 106 >>>> #??? top? Test timed out >>>> #??? top? TEST ././tests/v00017.vtc FAILED >>>> FAIL: ./tests/v00017.vtc >>>> #??? top? TEST ././tests/v00018.vtc passed (2.138s) >>>> >>>> ... >>>> >>>> ============================================== >>>> 1 of 192 tests failed >>>> Please report to varnish-dev at varnish-cache.org >>>> ============================================== >>>> >>>> Can somebody help me with this? >>>> >>>> Thanks ! >>>> >>>> _______________________________________________ >>>> varnish-bugs mailing list >>>> varnish-bugs at varnish-cache.org >>>> http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs >>> >> >>_______________________________________________ >>varnish-bugs mailing list >>varnish-bugs at varnish-cache.org >>http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs > > From varnish-bugs at varnish-cache.org Mon Oct 25 03:32:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Oct 2010 03:32:34 -0000 Subject: [Varnish] #800: 5452 Breaks Solaris Build Message-ID: <044.9a5280eb866b57287b8dce305b7d2c44@varnish-cache.org> #800: 5452 Breaks Solaris Build ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ http://www.varnish-cache.org/trac/changeset/5452 The non-portable pthread_timedjoin_np function does not exists on solaris, so it breaks the build. Perhaps use a macro to do it the old way when solaris is detected? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 25 07:10:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Oct 2010 07:10:02 -0000 Subject: [Varnish] #801: duplicate Content-Length headers Message-ID: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> #801: duplicate Content-Length headers ----------------------+----------------------------------------------------- Reporter: Talisker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Varnish is sending an HTTP response to the client with duplicate Content- Length headers; most browsers ignore this, but recent versions of Chrome get confused -- instead of a normal error page, Chrome gives the end user a friendly "Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH): Unknown error." The problem can be seen on http://gamestar.de, http://jamendo.com, and http://associated-press.net, among others (all of which reference Varnish in their headers); I'm also running into the problem on a site I'm working on, and can confirm that the duplicate Content-Length headers appear regardless of browser (again, chrome being the only one that pukes). Some info from my server: Varnish 2.1.4 -> Apache 2.2 -> Django 1.2.3, all on a solo 64-bit Ubuntu 10.04 server. Varnish is a stock install from repo.varnish-cache.org. Response headers coming from Apache 2.2 into Varnish: {{{ HTTP/1.1 200 OK Date: Mon, 25 Oct 2010 06:34:06 GMT Server: Apache/2.2 Content-Encoding: gzip Expires: Mon, 25 Oct 2010 06:34:06 GMT Vary: Cookie,Accept-Encoding ETag: "611e6876fefd686ed347255f3d7e7ab0" Cache-Control: max-age=0 Set-Cookie: csrftoken=5be57c4df521b9f4ab1a634ee73e5ddf; Max-Age=31449600; Path=/ Set-Cookie: sessionid=42c35dfe2903aa53dbf1d4d08b16e934; Path=/ Content-Length: 874 Last-Modified: Mon, 25 Oct 2010 06:34:06 GMT Content-Type: text/html; charset=utf-8 }}} ...and, the headers for the same request as passed on to the client (note the duplicate Content-Length headers): {{{ HTTP/1.1 200 OK Server: Apache/2.2 Content-Encoding: gzip Expires: Mon, 25 Oct 2010 06:33:21 GMT Vary: Cookie,Accept-Encoding ETag: "90b96d56a557f90f5f73f958b79be9a3" Set-Cookie: csrftoken=77c35d105a360f679aa7f7d5920d047a; Max-Age=31449600; Path=/ Set-Cookie: sessionid=fb6a8daedbbe59f02b0395ef7a104343; Path=/ Content-Length: 875 Last-Modified: Mon, 25 Oct 2010 06:33:21 GMT Content-Type: text/html; charset=utf-8 Content-Length: 875 Date: Mon, 25 Oct 2010 06:33:21 GMT X-Varnish: 726005028 Age: 0 Via: 1.1 varnish Connection: keep-alive }}} The VCL in question: {{{ # Default backend definition. backend default { .host = "127.0.0.1"; .port = "80"; } sub vcl_recv { # normalize accept-encoding header if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } # grace setting set req.grace = 30s; # ignore cookies on static files if (req.url ~ "\.(js|css|html|xml|gif|jpg|jpeg|bmp|png|tiff|tif|img|tga|wmf|ico|svg|swf|mp3|mp4|m4a|ogg|mov|avi|wmv)$") { if (req.http.cookie) { remove req.http.cookie; } } # remove csrftoken cookies from GETs if (req.http.cookie && req.request == "GET" && req.http.cookie ~ "csrftoken=") { set req.http.cookie = regsub(req.http.cookie, "(^|; ) *csrftoken=[^;]+;? *", "\1"); if (req.http.cookie == "") { remove req.http.cookie; } } } sub vcl_fetch { if (beresp.http.Pragma ~ "no-cache" || beresp.http.Cache-Control ~ "(no-cache|no-store|private)") { return(pass); } set beresp.grace = 1m; } sub vcl_pipe { set req.http.connection = "close"; } }}} ...and, finally, a trace from varnishlog: {{{ 11 SessionOpen c 192.168.110.1 60791 0.0.0.0:8100 11 ReqStart c 192.168.110.1 60791 888116555 11 RxRequest c GET 11 RxURL c /url/ 11 RxProtocol c HTTP/1.1 11 RxHeader c Host: example.com:8100 11 RxHeader c Connection: keep-alive 11 RxHeader c Cache-Control: no-cache 11 RxHeader c Pragma: no-cache 11 RxHeader c Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 11 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.11 Safari/534.10 11 RxHeader c Accept-Encoding: gzip,deflate,sdch 11 RxHeader c Accept-Language: en-US,en;q=0.8 11 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 11 RxHeader c Cookie: csrftoken=199e18114d7c1b4d36656b30cd545e43; sessionid=41eef12ba53b68962854ba9d4e90bcda 11 VCL_call c recv 11 VCL_trace c 1 9.5 11 VCL_trace c 2 9.9 11 VCL_trace c 3 10.9 11 VCL_trace c 4 10.13 11 VCL_trace c 5 11.13 11 VCL_trace c 9 21.5 11 VCL_trace c 10 24.9 11 VCL_trace c 15 29.1 11 VCL_trace c 22 3.5 11 VCL_trace c 23 3.9 11 VCL_trace c 24 3.28 11 VCL_trace c 25 3.52 11 VCL_trace c 26 4.9 11 VCL_trace c 27 5.13 11 VCL_trace c 29 8.5 11 VCL_trace c 30 9.1 11 VCL_trace c 31 43.5 11 VCL_trace c 32 43.9 11 VCL_trace c 33 44.9 11 VCL_trace c 34 44.13 11 VCL_trace c 36 48.13 11 VCL_trace c 37 51.5 11 VCL_trace c 38 51.9 11 VCL_trace c 46 61.5 11 VCL_trace c 47 61.9 11 VCL_trace c 50 65.5 11 VCL_trace c 51 65.9 11 VCL_trace c 52 65.35 11 VCL_trace c 53 67.9 11 VCL_return c pass 11 VCL_call c hash 11 VCL_trace c 57 87.5 11 VCL_trace c 58 88.9 11 VCL_trace c 59 89.9 11 VCL_return c hash 11 VCL_call c pass 11 VCL_trace c 56 83.5 11 VCL_return c pass 12 BackendOpen b default 127.0.0.1 44909 127.0.0.1 80 11 Backend c 12 default default 12 TxRequest b GET 12 TxURL b /url/ 12 TxProtocol b HTTP/1.1 12 TxHeader b Host: example.com:8100 12 TxHeader b Pragma: no-cache 12 TxHeader b Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 12 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.11 Safari/534.10 12 TxHeader b Accept-Language: en-US,en;q=0.8 12 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 12 TxHeader b Accept-Encoding: gzip 12 TxHeader b cookie: sessionid=41eef12ba53b68962854ba9d4e90bcda 12 TxHeader b X-Forwarded-For: 192.168.110.1 12 TxHeader b X-Varnish: 888116555 12 RxProtocol b HTTP/1.1 12 RxStatus b 200 12 RxResponse b OK 12 RxHeader b Date: Mon, 25 Oct 2010 06:47:28 GMT 12 RxHeader b Server: Apache/2.2 12 RxHeader b Content-Encoding: gzip 12 RxHeader b Expires: Mon, 25 Oct 2010 06:47:28 GMT 12 RxHeader b Vary: Cookie,Accept-Encoding 12 RxHeader b ETag: "a34a447a0fb119421cd136a3888bde5c" 12 RxHeader b Cache-Control: max-age=0 12 RxHeader b Set-Cookie: csrftoken=9fedc77c05845a879d117e125e899e76; Max-Age=31449600; Path=/ 12 RxHeader b Set-Cookie: sessionid=41eef12ba53b68962854ba9d4e90bcda; Path=/ 12 RxHeader b Content-Length: 875 12 RxHeader b Last-Modified: Mon, 25 Oct 2010 06:47:28 GMT 12 RxHeader b Content-Type: text/html; charset=utf-8 11 TTL c 888116555 RFC 0 1287989248 0 0 0 0 11 VCL_call c fetch 11 VCL_trace c 16 32.5 11 VCL_trace c 17 32.9 11 VCL_trace c 18 32.44 11 VCL_trace c 20 38.5 11 VCL_trace c 66 108.5 11 VCL_trace c 67 108.9 11 VCL_trace c 68 109.9 11 VCL_return c pass 11 ObjProtocol c HTTP/1.1 11 ObjStatus c 200 11 ObjResponse c OK 11 ObjHeader c Date: Mon, 25 Oct 2010 06:47:28 GMT 11 ObjHeader c Server: Apache/2.2 11 ObjHeader c Content-Encoding: gzip 11 ObjHeader c Expires: Mon, 25 Oct 2010 06:47:28 GMT 11 ObjHeader c Vary: Cookie,Accept-Encoding 11 ObjHeader c ETag: "a34a447a0fb119421cd136a3888bde5c" 11 ObjHeader c Set-Cookie: csrftoken=9fedc77c05845a879d117e125e899e76; Max-Age=31449600; Path=/ 11 ObjHeader c Set-Cookie: sessionid=41eef12ba53b68962854ba9d4e90bcda; Path=/ 11 ObjHeader c Content-Length: 875 11 ObjHeader c Last-Modified: Mon, 25 Oct 2010 06:47:28 GMT 11 ObjHeader c Content-Type: text/html; charset=utf-8 12 Length b 875 12 BackendReuse b default 11 VCL_call c deliver 11 VCL_trace c 73 118.5 11 VCL_return c deliver 11 TxProtocol c HTTP/1.1 11 TxStatus c 200 11 TxResponse c OK 11 TxHeader c Server: Apache/2.2 11 TxHeader c Content-Encoding: gzip 11 TxHeader c Expires: Mon, 25 Oct 2010 06:47:28 GMT 11 TxHeader c Vary: Cookie,Accept-Encoding 11 TxHeader c ETag: "a34a447a0fb119421cd136a3888bde5c" 11 TxHeader c Set-Cookie: csrftoken=9fedc77c05845a879d117e125e899e76; Max-Age=31449600; Path=/ 11 TxHeader c Set-Cookie: sessionid=41eef12ba53b68962854ba9d4e90bcda; Path=/ 11 TxHeader c Content-Length: 875 11 TxHeader c Last-Modified: Mon, 25 Oct 2010 06:47:28 GMT 11 TxHeader c Content-Type: text/html; charset=utf-8 11 TxHeader c Content-Length: 875 11 TxHeader c Date: Mon, 25 Oct 2010 06:47:28 GMT 11 TxHeader c X-Varnish: 888116555 11 TxHeader c Age: 0 11 TxHeader c Via: 1.1 varnish 11 TxHeader c Connection: keep-alive 11 Length c 875 11 ReqEnd c 888116555 1287989248.537992716 1287989248.602463961 0.000497580 0.062018871 0.002452374 11 SessionClose c EOF 11 StatSess c 192.168.110.1 60791 0 1 1 0 1 1 558 875 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 25 07:26:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Oct 2010 07:26:53 -0000 Subject: [Varnish] #801: duplicate Content-Length headers In-Reply-To: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> References: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> Message-ID: <054.deb90f41c662e44ea197732730474c0a@varnish-cache.org> #801: duplicate Content-Length headers ----------------------+----------------------------------------------------- Reporter: Talisker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by Talisker): Just tested with muuuuch simpler VCL: {{{ backend default { .host = "127.0.0.1"; .port = "80"; } }}} ...and still get the duplicate Content-Length headers. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 25 08:37:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Oct 2010 08:37:57 -0000 Subject: [Varnish] #801: duplicate Content-Length headers In-Reply-To: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> References: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> Message-ID: <054.cdc71a4c1f4e01d7c987d83acaa866ec@varnish-cache.org> #801: duplicate Content-Length headers ----------------------+----------------------------------------------------- Reporter: Talisker | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5461]) On pass (from vcl_recv) we did not remove the backends Content-Length header before adding our own. We can not do this with the fetch filtering, because pass might send HEAD requests to the backend. XXX: It's arguable that the filtering stuff might be better done inline than with a table. Fixes: #801 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 25 13:07:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Oct 2010 13:07:33 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC In-Reply-To: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> References: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> Message-ID: <051.93f5308e449b47bd2bcfba42191c510d@varnish-cache.org> #663: Varnish should auto-configure pthread support and VCC_CC --------------------------------------------------+------------------------- Reporter: slink | Owner: tfheen Type: enhancement | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: errno, mt-safety, pthread, reentrant | --------------------------------------------------+------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [5464]) Auto-detect pthread support and VCC_CC Thanks to Nils Goroll for the patch. Fixes #663 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 26 07:47:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 26 Oct 2010 07:47:14 -0000 Subject: [Varnish] #801: duplicate Content-Length headers In-Reply-To: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> References: <045.455c43bac33c37388be60f119014e9d4@varnish-cache.org> Message-ID: <054.1e191be7c58468d4bedee4cbc4e8d3a5@varnish-cache.org> #801: duplicate Content-Length headers ----------------------+----------------------------------------------------- Reporter: Talisker | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5467]) Merge r5461: Remove Content-Length on pass from vcl_recv On pass (from vcl_recv) we did not remove the backends Content-Length header before adding our own. We can not do this with the fetch filtering, because pass might send HEAD requests to the backend. XXX: It's arguable that the filtering stuff might be better done inline than with a table. Fixes: #801 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 26 14:51:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 26 Oct 2010 14:51:28 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() Message-ID: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- {{{ anic message: Assert error in VRT_r_obj_status(), cache_vrt.c line 343:#012 Condition((sp->obj) != NULL) not true.#012thread = (cache- worker)#012ident = Linux,2.6.34.7-56.fc13.i686,i686,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x806d79d: /usr/sbin/varnishd() [0x806d79d]#012 0x80776e8: /usr/sbin/varnishd(VRT_r_obj_status+0x158) [0x80776e8]#012 0x648a32: ./vcl.1P9zoqAU.so(+0x1a32) [0x648a32]#012 0x80731c5: /usr/sbin/varnishd(VCL_fetch_method+0x55) [0x80731c5]#012 0x8059f70: /usr/sbin/varnishd() [0x8059f70]#012 0x805bc42: /usr/sbin/varnishd(CNT_Session+0x3c2) [0x805bc42]#012 0x806f320: /usr/sbin/varnishd() [0x806f320]#012 0x806f70a: /usr/sbin/varnishd() [0x806f70a]#012 0x806fc3e: /usr/sbin/varnishd() [0x806fc3e]#012 0x580919: /lib/libpthread.so.0() [0x580919]#012sp = 0xaca07004 {#012 fd = 12, id = 12, xid = 479311681,#012 client = 127.0.0.1:53031,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 500, err_reason = (null),#012 restarts = 0, esis = 0#012 ws = 0xaca0704c { #012 id = "sess",#012 {s,f,r,e} = {0xaca077dc,+536,(nil),+16384},#012 },#012 http[req] = {#012 ws = 0xaca0704c[sess]#012 "GET",#012 "/test.php",#012 "HTTP/1.1",#012 "Host: localhost:8080",#012 "User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100920 Fedora/3.6.10-1.fc13 Firefox/3.6.10",#012 "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",#012 "Accept-Language: en-us,en;q=0.5",#012 "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",#012 "Keep-Alive: 115",#012 "Connection: keep-alive",#012 "Cache-Control: max-age=0",#012 "Accept-Encoding: gzip",#012 },#012 worker = 0xac877124 {#012 ws = 0xac87723c { #012 id = "wrk",#012 {s,f,r,e} = {0xac8710d0,+296,(nil),+16384},#012 },#012 http[bereq] = {#012 ws = 0xac87723c[wrk]#012 "GET",#012 "/test.php",#012 "HTTP/1.1",#012 "Host: localhost:8080",#012 "User-Ag }}} This is using varnish 2.1.4 and the syslog example here: http://www .varnish-cache.org/trac/wiki/VCLExampleSyslog Using other variables seems to work fine, trying to use VRT_r_obj_status() leads to the asset error above. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 27 12:30:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Oct 2010 12:30:24 -0000 Subject: [Varnish] #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse In-Reply-To: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> References: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> Message-ID: <054.d9a5bdd66f0aca7b0df133e197b6f42a@varnish-cache.org> #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse ----------------------+----------------------------------------------------- Reporter: askalski | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: (In [5476]) Read expected final CRLF after chunked encoding data from backend. Make "chunkedlen" test server command output final CRLF after chunked data. Update a couple of test cases to output the final CRLF. Fixes: #780 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 27 18:24:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Oct 2010 18:24:28 -0000 Subject: [Varnish] #803: If-Modified-Since + pass hangs until backend closes connection Message-ID: <040.bbd3b8a33f6f2406383a7ea691fa094b@varnish-cache.org> #803: If-Modified-Since + pass hangs until backend closes connection --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.1.4 Severity: normal | Keywords: --------------------+------------------------------------------------------- if you pass on a if-modified-since request, varnish doesn't recognize that the 304 does not have a body. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 27 18:48:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Oct 2010 18:48:41 -0000 Subject: [Varnish] #803: If-Modified-Since + pass hangs until backend closes connection In-Reply-To: <040.bbd3b8a33f6f2406383a7ea691fa094b@varnish-cache.org> References: <040.bbd3b8a33f6f2406383a7ea691fa094b@varnish-cache.org> Message-ID: <049.d9f69299d689f9ad7ab8c56f2bf6c078@varnish-cache.org> #803: If-Modified-Since + pass hangs until backend closes connection --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5478]) Special case beresp status 1xx, 204 and 304, they have no body. (r5477 is a requirement for this fix) Fixes: #803 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 27 19:21:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Oct 2010 19:21:14 -0000 Subject: [Varnish] #804: Invalid command line option in varnishtest.1 Message-ID: <047.028f94ba444956a6d18d2c68d6b4ba1b@varnish-cache.org> #804: Invalid command line option in varnishtest.1 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Type: documentation Status: new | Priority: low Milestone: | Component: documentation Version: 2.1.4 | Severity: minor Keywords: | ------------------------+--------------------------------------------------- The man page and web page both include the following invalid command line option: "-L port Listen on port" main in vtc.c for varnishtest does not handle that option. Either the docs or the program are wrong. I suspect the former. Error exists in trunk too. Best regards, jim -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 27 21:54:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Oct 2010 21:54:41 -0000 Subject: [Varnish] #805: Negative ReqEnd accept time (ESI enabled) and hanging request Message-ID: <043.a1d082f96df5a220dbf6111b921708bb@varnish-cache.org> #805: Negative ReqEnd accept time (ESI enabled) and hanging request ----------------------+----------------------------------------------------- Reporter: tesdal | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: ----------------------+----------------------------------------------------- We see entries like 21 ReqEnd c 315153529 1288175527.482929945 1288175531.779880047 -4.293623447 nan nan 14 ReqEnd c 315196003 1288177021.750665903 1288177023.020342827 -1.266375780 nan nan in Varnish 2.1.3 with ESI enabled. HAProxy in front reports timing like 0/0/0/63/101889 and 0/0/0/8649/1182844. That means it took 63ms and 8649ms before Varnish started returning data, but that the connection wasn't closed until after 101 and 1182 seconds. Varnish logs are in: http://pastie.textmate.org/private/rperx3qox8nmys71qg9w3a ESI is used extensively for the entire site, it's not unique to this URL, but this URL is the only place we have noticed the seemingly hanging Varnish connections so far. Tollef said that he had an idea he wanted to investigate about the cause of this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 28 03:47:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Oct 2010 03:47:14 -0000 Subject: [Varnish] #806: invalid Content-Length results in hang and then 503 Message-ID: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> #806: invalid Content-Length results in hang and then 503 ---------------------+------------------------------------------------------ Reporter: amorton | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Hi, I was using Varnish > Nginx > Tornado and there was a bug in Tornado that was causing it to sometimes include a non zero content length when returning 304 for an unchanged file. As near as I can tell this was causing varnish to log and error, then hang until 60 seconds had passed where it would return a 503 error code. I corrected the bug in tornado and got the expected behavior. I thought you may want to know about the timeout. Am running varnishd (varnish-2.1.2 SVN 4769:4772) Here is an example of the hanging and error... 15 RxProtocol - HTTP/1.1 15 RxStatus - 304 15 RxResponse - Not Modified 15 RxHeader - Server: nginx/0.7.67 15 RxHeader - Date: Thu, 28 Oct 2010 01:50:33 GMT 15 RxHeader - Content-Type: application/x-javascript 15 RxHeader - Connection: keep-alive 15 RxHeader - Keep-Alive: timeout=20 15 RxHeader - Last-Modified: Thu, 28 Oct 2010 11:31:23 GMT 15 RxHeader - Content-Length: 163855 15 RxHeader - Cache-Control: public 4 TTL - 2051465986 RFC 120 1288230633 0 0 0 0 4 VCL_call - fetch 4 VCL_return - deliver 4 ObjProtocol - HTTP/1.1 4 ObjStatus - 304 4 ObjResponse - Not Modified 4 ObjHeader - Server: nginx/0.7.67 4 ObjHeader - Date: Thu, 28 Oct 2010 01:50:33 GMT 4 ObjHeader - Content-Type: application/x-javascript 4 ObjHeader - Keep-Alive: timeout=20 4 ObjHeader - Last-Modified: Thu, 28 Oct 2010 11:31:23 GMT 4 ObjHeader - Cache-Control: public 4 FetchError - straight read_error: 11 15 BackendClose - jbx_webhead0 4 VCL_call - error 4 VCL_return - deliver 4 Length - 488 4 VCL_call - deliver 4 VCL_return - deliver 4 TxProtocol - HTTP/1.1 4 TxStatus - 503 4 TxResponse - Service Unavailable 4 TxHeader - Server: Varnish 4 TxHeader - Retry-After: 0 4 TxHeader - Content-Type: text/html; charset=utf-8 4 TxHeader - Content-Length: 488 4 TxHeader - Date: Thu, 28 Oct 2010 01:51:34 GMT 4 TxHeader - X-Varnish: 2051465986 4 TxHeader - Age: 61 4 TxHeader - Via: 1.1 varnish 4 TxHeader - Connection: close 4 ReqEnd - 2051465986 1288230633.044901848 1288230694.293493748 0.000034809 61.248561621 0.000030279 4 SessionClose - error 4 StatSess - 192.168.49.104 40516 61 1 1 0 1 0 236 488 This is an example of a working request to a different web head through the same varnish server... 5 RxProtocol - HTTP/1.1 5 RxStatus - 304 5 RxResponse - Not Modified 5 RxHeader - Server: nginx/0.7.67 5 RxHeader - Date: Thu, 28 Oct 2010 01:49:41 GMT 5 RxHeader - Content-Type: application/x-javascript 5 RxHeader - Connection: keep-alive 5 RxHeader - Keep-Alive: timeout=20 5 RxHeader - Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 5 RxHeader - Content-Length: 0 5 RxHeader - Cache-Control: public 4 TTL c 2051465985 RFC 120 1288230581 0 0 0 0 4 VCL_call c fetch 4 VCL_return c deliver 4 ObjProtocol c HTTP/1.1 4 ObjStatus c 304 4 ObjResponse c Not Modified 4 ObjHeader c Server: nginx/0.7.67 4 ObjHeader c Date: Thu, 28 Oct 2010 01:49:41 GMT 4 ObjHeader c Content-Type: application/x-javascript 4 ObjHeader c Keep-Alive: timeout=20 4 ObjHeader c Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 4 ObjHeader c Cache-Control: public 5 BackendReuse - jbx_webhead1 4 Length c 0 4 VCL_call c deliver 4 VCL_return c deliver 4 TxProtocol c HTTP/1.1 4 TxStatus c 304 4 TxResponse c Not Modified 4 TxHeader c Server: nginx/0.7.67 4 TxHeader c Content-Type: application/x-javascript 4 TxHeader c Keep-Alive: timeout=20 4 TxHeader c Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 4 TxHeader c Cache-Control: public 4 TxHeader c Content-Length: 0 4 TxHeader c Date: Thu, 28 Oct 2010 01:49:41 GMT 4 TxHeader c X-Varnish: 2051465985 4 TxHeader c Age: 0 4 TxHeader c Via: 1.1 varnish 4 TxHeader c Connection: keep-alive 4 ReqEnd c 2051465985 1288230581.047450781 1288230581.094709396 0.000034332 0.047218323 0.000040293 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 28 03:49:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Oct 2010 03:49:24 -0000 Subject: [Varnish] #806: invalid Content-Length results in hang and then 503 In-Reply-To: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> References: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> Message-ID: <053.a8f1c9850d14bb3788eec492b6ce4c75@varnish-cache.org> #806: invalid Content-Length results in hang and then 503 ---------------------+------------------------------------------------------ Reporter: amorton | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Comment(by amorton): Sorry, here are better formatted logs. Firs the failing request. {{{ 15 RxProtocol - HTTP/1.1 15 RxStatus - 304 15 RxResponse - Not Modified 15 RxHeader - Server: nginx/0.7.67 15 RxHeader - Date: Thu, 28 Oct 2010 01:50:33 GMT 15 RxHeader - Content-Type: application/x-javascript 15 RxHeader - Connection: keep-alive 15 RxHeader - Keep-Alive: timeout=20 15 RxHeader - Last-Modified: Thu, 28 Oct 2010 11:31:23 GMT 15 RxHeader - Content-Length: 163855 15 RxHeader - Cache-Control: public 4 TTL - 2051465986 RFC 120 1288230633 0 0 0 0 4 VCL_call - fetch 4 VCL_return - deliver 4 ObjProtocol - HTTP/1.1 4 ObjStatus - 304 4 ObjResponse - Not Modified 4 ObjHeader - Server: nginx/0.7.67 4 ObjHeader - Date: Thu, 28 Oct 2010 01:50:33 GMT 4 ObjHeader - Content-Type: application/x-javascript 4 ObjHeader - Keep-Alive: timeout=20 4 ObjHeader - Last-Modified: Thu, 28 Oct 2010 11:31:23 GMT 4 ObjHeader - Cache-Control: public 4 FetchError - straight read_error: 11 15 BackendClose - jbx_webhead0 4 VCL_call - error 4 VCL_return - deliver 4 Length - 488 4 VCL_call - deliver 4 VCL_return - deliver 4 TxProtocol - HTTP/1.1 4 TxStatus - 503 4 TxResponse - Service Unavailable 4 TxHeader - Server: Varnish 4 TxHeader - Retry-After: 0 4 TxHeader - Content-Type: text/html; charset=utf-8 4 TxHeader - Content-Length: 488 4 TxHeader - Date: Thu, 28 Oct 2010 01:51:34 GMT 4 TxHeader - X-Varnish: 2051465986 4 TxHeader - Age: 61 4 TxHeader - Via: 1.1 varnish 4 TxHeader - Connection: close 4 ReqEnd - 2051465986 1288230633.044901848 1288230694.293493748 0.000034809 61.248561621 0.000030279 4 SessionClose - error 4 StatSess - 192.168.49.104 40516 61 1 1 0 1 0 236 488 }}} And one that works {{{ 5 RxProtocol - HTTP/1.1 5 RxStatus - 304 5 RxResponse - Not Modified 5 RxHeader - Server: nginx/0.7.67 5 RxHeader - Date: Thu, 28 Oct 2010 01:49:41 GMT 5 RxHeader - Content-Type: application/x-javascript 5 RxHeader - Connection: keep-alive 5 RxHeader - Keep-Alive: timeout=20 5 RxHeader - Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 5 RxHeader - Content-Length: 0 5 RxHeader - Cache-Control: public 4 TTL c 2051465985 RFC 120 1288230581 0 0 0 0 4 VCL_call c fetch 4 VCL_return c deliver 4 ObjProtocol c HTTP/1.1 4 ObjStatus c 304 4 ObjResponse c Not Modified 4 ObjHeader c Server: nginx/0.7.67 4 ObjHeader c Date: Thu, 28 Oct 2010 01:49:41 GMT 4 ObjHeader c Content-Type: application/x-javascript 4 ObjHeader c Keep-Alive: timeout=20 4 ObjHeader c Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 4 ObjHeader c Cache-Control: public 5 BackendReuse - jbx_webhead1 4 Length c 0 4 VCL_call c deliver 4 VCL_return c deliver 4 TxProtocol c HTTP/1.1 4 TxStatus c 304 4 TxResponse c Not Modified 4 TxHeader c Server: nginx/0.7.67 4 TxHeader c Content-Type: application/x-javascript 4 TxHeader c Keep-Alive: timeout=20 4 TxHeader c Last-Modified: Fri, 08 Oct 2010 11:32:00 GMT 4 TxHeader c Cache-Control: public 4 TxHeader c Content-Length: 0 4 TxHeader c Date: Thu, 28 Oct 2010 01:49:41 GMT 4 TxHeader c X-Varnish: 2051465985 4 TxHeader c Age: 0 4 TxHeader c Via: 1.1 varnish 4 TxHeader c Connection: keep-alive 4 ReqEnd c 2051465985 1288230581.047450781 1288230581.094709396 0.000034332 0.047218323 0.000040293 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 28 06:39:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Oct 2010 06:39:49 -0000 Subject: [Varnish] #807: varnishlog should do input validation Message-ID: <043.8ccc2e377b952dd35985726ef7341ac8@varnish-cache.org> #807: varnishlog should do input validation ------------------------+--------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- If varnishlog is run with -r and passed a compressed (or non-varnishlog) file, it will happily output garbage. We should make sure what we read at least resembles a valid varnishlog file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 28 21:15:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Oct 2010 21:15:01 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.58e9715853903cd3d08aad30dcd8575a@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: hang stop responding | ----------------------------------+----------------------------------------- Changes (by eli): * status: closed => reopened * resolution: worksforme => Comment: I am getting exactly the same problem with 2.1.3 varnishlog shows: 858 StatSess - (null) (null) 1288300233 0 0 0 0 0 0 0 858 SessionClose - dropped 858 StatSess - (null) (null) 1288300233 0 0 0 0 0 0 0 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1288300233 1.0 858 SessionClose - dropped 858 StatSess - (null) (null) 1288300233 0 0 0 0 0 0 0 858 SessionClose - dropped 858 StatSess - (null) (null) 1288300233 0 0 0 0 0 0 0 Entries in the syslog are also two hours off. I'm not exactly sure what the trigger is, but it seems to be happening more frequently, from once a week to more than once a day. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 28 21:57:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Oct 2010 21:57:22 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.8ccf9608f95f3c2b6de2161e1c2c08d7@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: hang stop responding | ----------------------------------+----------------------------------------- Comment(by eli): Actually it seems like not ALL requests are failing. varnishtop looks like: {{{ 523 0.00 0.21 N worker threads created 10545 0.00 4.22 N worker threads limited 251 0.00 0.10 N queued work requests 33895 0.00 13.57 N overflowed work requests 33234 34.97 13.31 N dropped work requests }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 29 00:06:50 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Oct 2010 00:06:50 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.d2d569f708b3e6f37fbdb1d9c9e1492e@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: hang stop responding | ----------------------------------+----------------------------------------- Comment(by eli): Here's a question: are the dropped sessions and the (null) StatSession lines in the log consistent with a Varnish instance that is simply overloaded? Could a large number of clients be holding a session open and causing all my problems? I'm wondering if there's an actual or perhaps inadvertent DDoS going on here. I've upgraded to 2.1.4 and also tweaked my params to increase the thread pool size and decrease sess_timeout and send_timeout and things seem to be doing better. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 29 07:26:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Oct 2010 07:26:19 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.5e4b23390827ade6ea1511fa4b855119@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: hang stop responding | ----------------------------------+----------------------------------------- Comment(by ahongens): I had this problem for a while with a quite overloaded Varnish. My 4 nodes had 8GB RAM each, and I set varnish to use ~16GB, so it would swap to disk. My dataset is >1TB, since there are a lot of sites behind this cluster. Varnish stopped ocassionally. After I experienced this for a while I set varnish to use 6GB (so less than the physical ram), and since then I haven't seen a single problem with varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 30 15:31:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 30 Oct 2010 15:31:13 -0000 Subject: [Varnish] #808: Assert crash on load testing Message-ID: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> #808: Assert crash on load testing -------------------+-------------------------------------------------------- Reporter: diego | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Error ocurred at both SVN 5430 and latest SVN 5487. To reproduce using httperf 0.9 and set num-calls to about 4000 and above. This is related to the session_workspace value. With 512KB, it will sustain/buffer 3600 requests/second. I have tested the session_workspace value and it directly correlates to how many calls can be made per keep- alive request before varnish asserts and restarts. Lowering the value lowers the number of num-calls httperf will be able send without crashing varnish. For example, using defaults, varnish can only sustain a few hundred almost simultaneous requests from a single connection. If varnish can somehow not assert but check its session memory usage and close the connection if reaching session workspace limit, it would be ideal as compared to the case now where varnish restarts. {{{ httperf --server www.myserver.com --uri / --num-conns 1 --num-calls 4000 }}} Varnish startup line: {{{ varnishd -f varnish_vcl.txt -a $IP:22201 -T 127.0.0.1:22201 -n /raid0 -h critbit -smalloc,8G -p thread_pools=2 -p thread_pool_min=100 -p thread_pool_max=500 -p thread_pool_add_delay=2 -p listen_depth=4096 -p session_linger=50/100/150 -p lru_interval=20 -p sess_workspace=512000 }}} {{{ Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) died signal=6 Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaac19008 { fd = 12, id = 12, xid = 733244310, client = 209.151.227.72 56196, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaac19080 { id = "sess", {s,f,r,e} = {0x2aaaaac19cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaaac19080[sess] Oct 29 06:18:57 kitty1 /raid0[21974]: child (22075) Started Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said Child starts Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) died signal=6 Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab0af008 { fd = 12, id = 12, xid = 227475721, client = 209.151.227.72 57424, step = STP_DELIVER, handling = deliver, restarts = 0, esis = 0 ws = 0x2aaaab0af080 { id = "sess", {s,f,r,e} = {0x2aaaab0afcd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaab0af080[sess] "GET", "/", "HTTP/1. Oct 29 06:19:47 kitty1 /raid0[21974]: child (22094) Started Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said Child starts Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) died signal=6 Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaabe8008 { fd = 14, id = 14, xid = 170289336, client = 209.151.227.72 57483, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaabe8080 { id = "sess", {s,f,r,e} = {0x2aaaaabe8cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaaabe8080[sess] Oct 29 06:19:49 kitty1 /raid0[21974]: child (22113) Started Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said Child starts Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) died signal=6 Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab336008 { fd = 22, id = 22, xid = 161296516, client = 209.151.227.72 57576, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaab336080 { id = "sess", {s,f,r,e} = {0x2aaaab336cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaab336080[sess] Oct 29 06:19:53 kitty1 /raid0[21974]: child (22132) Started Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator