From varnish-bugs at varnish-cache.org Mon May 2 10:08:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:08:49 -0000 Subject: [Varnish] #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable In-Reply-To: <046.30ca96fa862f0e17f0d65adc58e171b7@varnish-cache.org> References: <046.30ca96fa862f0e17f0d65adc58e171b7@varnish-cache.org> Message-ID: <055.7a04bfe1d2e47f6067f35dcd2eab1236@varnish-cache.org> #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable -----------------------+---------------------------------------------------- Reporter: thiagocsf | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Keywords: cacheable 307 -----------------------+---------------------------------------------------- Changes (by kristian): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:11:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:11:21 -0000 Subject: [Varnish] #906: Varnish 2.1.x packages for el5 are not signed In-Reply-To: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> References: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> Message-ID: <050.ab9f15671dca191c708bffe1f429ccf8@varnish-cache.org> #906: Varnish 2.1.x packages for el5 are not signed --------------------+------------------------------------------------------- Reporter: maxp | Owner: tfheen Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Keywords: gpg rpm security --------------------+------------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:16:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:16:14 -0000 Subject: [Varnish] #905: Modification of multi-line beresp or resp header mangles value In-Reply-To: <042.3754aa30b0723f9ee2df26331b4df940@varnish-cache.org> References: <042.3754aa30b0723f9ee2df26331b4df940@varnish-cache.org> Message-ID: <051.e6e597c0f7b04f5b6b3ae9b1768a1ed6@varnish-cache.org> #905: Modification of multi-line beresp or resp header mangles value ---------------------+------------------------------------------------------ Reporter: lrowe | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: In varnish-trunk, soon to be 3.0, we have VMOD function that can do this std.collect() and we collect the Vary: header by default in the C-code because Varnish relies on it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:17:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:17:53 -0000 Subject: [Varnish] #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 In-Reply-To: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> References: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> Message-ID: <052.4b69856d74be5e5c0395592dc5656029@varnish-cache.org> #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 ----------------------+----------------------------------------------------- Reporter: kdajka | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: 3b4859455803b606107c07b25b784372d5665a1f ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:23:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:23:05 -0000 Subject: [Varnish] #903: Segmentation fault in varnish 3b4859455803b606107c07b25b784372d5665a1f In-Reply-To: <043.04455f1c56c4d22970fbcd4e327fc60b@varnish-cache.org> References: <043.04455f1c56c4d22970fbcd4e327fc60b@varnish-cache.org> Message-ID: <052.df7cc257b31380d25d50953346fbbebc@varnish-cache.org> #903: Segmentation fault in varnish 3b4859455803b606107c07b25b784372d5665a1f ----------------------+----------------------------------------------------- Reporter: kdajka | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:28:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:28:45 -0000 Subject: [Varnish] #883: Memory leaking In-Reply-To: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> References: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> Message-ID: <051.287cf2a29e472b223771e9b3a6fc5a64@varnish-cache.org> #883: Memory leaking ----------------------+----------------------------------------------------- Reporter: arety | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Keywords: memory usage ----------------------+----------------------------------------------------- Comment(by kristian): I'm closing this ticket as I haven't seen any other reports, and no further data is available. Feel free to re-open it if you have further data. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:28:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:28:56 -0000 Subject: [Varnish] #883: Memory leaking In-Reply-To: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> References: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> Message-ID: <051.b93ffc7098b48ca006f606811ec177ca@varnish-cache.org> #883: Memory leaking --------------------------+------------------------------------------------- Reporter: arety | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Resolution: worksforme Keywords: memory usage | --------------------------+------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 10:33:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 10:33:42 -0000 Subject: [Varnish] #899: Mixing of compressed and uncompressed content with ESI In-Reply-To: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> References: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> Message-ID: <054.44528d6d02a6f09645f807c5dd4c310d@varnish-cache.org> #899: Mixing of compressed and uncompressed content with ESI ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk Comment: Without gzip support enabled we don't pay attention to gzip status, the backend can compress if it wants to and we just treat is a Vary thing. The only sensible solution, in light of -spersistent, is to tag all objects created with gzip support and only deliver such when gzip-support is enabled. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 12:01:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 12:01:25 -0000 Subject: [Varnish] #886: Ban-related crashes In-Reply-To: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> References: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> Message-ID: <054.82e8c4e170ab47d1577bdb43d43a68ff@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): As discussed, I've located the root of the problem. ban_check_object is accessed by through HSH_Lookup - which holds a lock on the objecthead, and through ban_lurker, which only holds a refcounter. When ban_check_object is accessed from both of these at the same time with the same oc, whichever finishes first will update the oc->ban in ban_check_object on cache_ban.c:471: {{{ 470 if (b == oc->ban) { /* not banned */ 471 oc->ban = b0; 472 o->ban_t = oc->ban->t0; 473 oc_updatemeta(oc); 474 return (0); 475 } else { }}} This will confuse the other thread, which is looping through the ban, looking for the one that matches oc->ban (which has now been changed). While a lock on oh in the ban lurker is one solution, an other might be a temporary copy of oc->ban, but that still means you get two threads checking the same object, which is very much less than ideal (I don't see a use-case for two threads checking the same oc at the same time...). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 2 17:08:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 May 2011 17:08:56 -0000 Subject: =?utf-8?q?=5BVarnish=5D_=23909=3A_Varnish_returns_503_error_when?= =?utf-8?q?_a_=E2=80=9CTransfer-Enconding=3A_chunked=E2=80=9D_hea?= =?utf-8?q?der_is_sent_by_the_backend?= Message-ID: <042.c465724affa8de1cd82eac9a542fd9c7@varnish-cache.org> #909: Varnish returns 503 error when a ?Transfer-Enconding: chunked? header is sent by the backend -----------------------------+---------------------------------------------- Reporter: borja | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Hi We have detected a problem with the development version of Varnish. When a ?Transfer-Enconding: chunked? header is sent by the backend, Varnish returns a 503 error. You can check it with a simple php script and the default vcl file, only setting a backend server:[[BR]] {{{ Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 3 08:18:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 May 2011 08:18:16 -0000 Subject: [Varnish] #907: Varnish alternates between 200 and 304 responses with ETags In-Reply-To: <042.9c4ec3d6f94dfb542b47fb0f16bc4c24@varnish-cache.org> References: <042.9c4ec3d6f94dfb542b47fb0f16bc4c24@varnish-cache.org> Message-ID: <051.c34dc37feee69db0ab100a37bcd42a53@varnish-cache.org> #907: Varnish alternates between 200 and 304 responses with ETags ---------------------+------------------------------------------------------ Reporter: lrowe | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [a7c18717f45390231bf62cfedcf805458b26ca26]) Round down synthesized last-modified timestamp in object Commit 3bd239e9b2361c96b1acf1c03bce9c50baaf838d makes it so we set the object's last-modified timestamp to the current timestamp if there's no Last-Modified header. This makes it so we can do conditional gets even when there's no Last-Modified or ETag header from the backend. However, the time entered was a float, so we effectively ended up with an off-by-up-to-one-minus-epsilon error. This lead to requests ending up in a 304/200 response code round-dance. We now round the timestamp down to the nearest whole second instead, which should fix this bug. Thanks to lrowe for a helpful bug report. Fixes: #907 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 3 09:10:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 May 2011 09:10:04 -0000 Subject: [Varnish] #827: varnish child died in object_cmp In-Reply-To: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> References: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> Message-ID: <052.9eac1739762e7b3a9f427e843ffaf276@varnish-cache.org> #827: varnish child died in object_cmp --------------------------+------------------------------------------------- Reporter: dmyaho | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: invalid Keywords: Assert error | --------------------------+------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => invalid Comment: I'm closing this, as there's nothing more we can do about it unless more (newer) data is presented. Feel free to re-open if you have more data (for 2.1.5 or trunk). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 5 21:48:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 May 2011 21:48:12 -0000 Subject: [Varnish] #910: handling esi:include target with pipe crashes varnish Message-ID: <045.362ec39f64f63f3ab9bb5674a1479015@varnish-cache.org> #910: handling esi:include target with pipe crashes varnish ----------------------+----------------------------------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- From the documentation at http://www.varnish- cache.org/trac/wiki/ESIfeatures {{{ The target of must not be handled as pipe, the object will be ignored in that case. }}} Attempting this actually crashes varnish, rather than simply ignore the object as the documentation suggests. Varnish 2.1.5 writes the following the shmlog: "INCOMPLETE AT: cnt_recv(1099)" Reproduced both in 2.1.5 and in trunk (f8dd5ccc). {{{ }}} {{{ sub vcl_recv { if (req.url ~ "/crasher.html") { return (pipe); } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 6 09:01:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 May 2011 09:01:11 -0000 Subject: =?utf-8?q?Re=3A_=5BVarnish=5D_=23909=3A_Varnish_returns_503_erro?= =?utf-8?q?r_when_a_=E2=80=9CTransfer-Enconding=3A_chunked?= =?utf-8?q?=E2=80=9D_header_is_sent_by_the_backend?= In-Reply-To: <042.c465724affa8de1cd82eac9a542fd9c7@varnish-cache.org> References: <042.c465724affa8de1cd82eac9a542fd9c7@varnish-cache.org> Message-ID: <051.5ec3e502bb27ab97d1bbdaf0c3681040@varnish-cache.org> #909: Varnish returns 503 error when a ?Transfer-Enconding: chunked? header is sent by the backend ------------------------------+--------------------------------------------- Reporter: borja | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Resolution: invalid | Keywords: ------------------------------+--------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Transfer-Encoding: chunked is a very special header, that affects how the body of the object is transmitted on the wire. It is not a header you should ever set from a CGI script, and if you do, your webserver should detect it and handle it properly, either by removing it again or by switching to chunked transmission mode. Varnish does the right thing in this case, because the HTTP response it receives makes no sense. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 6 11:12:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 May 2011 11:12:23 -0000 Subject: [Varnish] #886: Ban-related crashes In-Reply-To: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> References: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> Message-ID: <054.e40b068880c77a405a1216fe49860a62@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: I have tried to solve this in 4c18047ef64fb5a40f229dfb0e30dc85530ffb7e Let me know if I succeeded. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 6 13:34:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 May 2011 13:34:08 -0000 Subject: [Varnish] #911: parameter "vcc_err_unref" don't work on subroutine Message-ID: <044.ef9e036d5a190efdfa3fb5153709cb59@varnish-cache.org> #911: parameter "vcc_err_unref" don't work on subroutine -----------------------------+---------------------------------------------- Reporter: ehocdet | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Keywords: vcc_err_unref | -----------------------------+---------------------------------------------- according to: http://www.varnish- cache.org/trac/changeset/38d7ebb0ac5d3ad387869f423589f9ff3b33a71c#file7 unref subroutine must be show a warning not a error with vcc_err_unref=off param. patch to correct this: -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 6 19:59:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 May 2011 19:59:19 -0000 Subject: [Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris Message-ID: <043.55a281ff7bab8b4ac521aa0e65dfdd9e@varnish-cache.org> #912: Vanish lacks the file_read privilege on recent OpenSolaris --------------------+------------------------------------------------------- Reporter: mamash | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | --------------------+------------------------------------------------------- The waive_privileges code does not work properly on recent OpenSolaris OS, snv_140 and newer (also Illumos/OpenIndiana). In addition to 'net_access', 'file_read' is also needed, otherwise the VCL shared object cannot be opened by the child process: {{{ Pushing vcls failed: dlopen(./vcl.ORk8t3RP.so): ld.so.1: varnishd: fatal: ./vcl.ORk8t3RP.so: Permission denied }}} I believe this remains a problem in the trunk too. More information here: [http://webcache.googleusercontent.com/search?q=cache:EIzTALnLxX4J:bugs.opensolaris.org/bugdatabase/view_bug.do%3Fbug_id%3D6440298+bug+6440298&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com Bug 6440298 (Google Cache)][[BR]] [http://mail.opensolaris.org/pipermail/opensolaris- arc/2009-July/016660.html Mail list discussion] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 08:23:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 08:23:52 -0000 Subject: [Varnish] #910: handling esi:include target with pipe crashes varnish In-Reply-To: <045.362ec39f64f63f3ab9bb5674a1479015@varnish-cache.org> References: <045.362ec39f64f63f3ab9bb5674a1479015@varnish-cache.org> Message-ID: <054.28634b351faeefd2baf76118266792fe@varnish-cache.org> #910: handling esi:include target with pipe crashes varnish -----------------------+---------------------------------------------------- Reporter: askalski | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: wontfix | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: This is an intentional crash. There is no sane way to handle ESI+pipe and to be sure to get the admins attention, doing so is an assert. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 08:34:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 08:34:57 -0000 Subject: [Varnish] #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 In-Reply-To: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> References: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> Message-ID: <052.b050cf7b42a8ae9ef292e509fbd90df9@varnish-cache.org> #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 ----------------------+----------------------------------------------------- Reporter: kdajka | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: 3b4859455803b606107c07b25b784372d5665a1f ----------------------+----------------------------------------------------- Comment(by phk): It looks like this could happen if the client closes the connection prematurely. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 09:52:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 09:52:19 -0000 Subject: [Varnish] #856: nm -an hack does not work on solaris In-Reply-To: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org> References: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org> Message-ID: <051.b2ec915710f6d993c21a35c08a127177@varnish-cache.org> #856: nm -an hack does not work on solaris --------------------------+------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: new Priority: lowest | Milestone: Component: port:solaris | Version: trunk Severity: trivial | Keywords: Solaris --------------------------+------------------------------------------------- Changes (by phk): * component: varnishd => port:solaris -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 09:53:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 09:53:08 -0000 Subject: [Varnish] #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.2dac51e3b9ff43dfc0bf2e553b61b4e6@varnish-cache.org> #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED --------------------------+------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: port:solaris | Version: 2.1.4 Severity: normal | Keywords: --------------------------+------------------------------------------------- Changes (by phk): * component: varnishd => port:solaris -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 09:53:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 09:53:51 -0000 Subject: [Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris In-Reply-To: <043.55a281ff7bab8b4ac521aa0e65dfdd9e@varnish-cache.org> References: <043.55a281ff7bab8b4ac521aa0e65dfdd9e@varnish-cache.org> Message-ID: <052.1e7f5ac4085ac8582258992e6230ca62@varnish-cache.org> #912: Vanish lacks the file_read privilege on recent OpenSolaris --------------------------+------------------------------------------------- Reporter: mamash | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: 2.1.5 Severity: major | Keywords: --------------------------+------------------------------------------------- Changes (by phk): * owner: => slink * component: varnishd => port:solaris -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 10:01:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 10:01:10 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> References: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> Message-ID: <049.743c706ff5dae94284020a2ce0e1cae2@varnish-cache.org> #889: opensolaris build issue --------------------------+------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Keywords: --------------------------+------------------------------------------------- Changes (by phk): * component: build => port:solaris -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 12:37:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 12:37:55 -0000 Subject: [Varnish] #886: Ban-related crashes In-Reply-To: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> References: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> Message-ID: <054.0cbd41b02fc570f1f6cb6e17b3379ff3@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => fixed Comment: I have not been able to trigger any ban-related asserts after this commit, and I'm fairly confident that I would have caught it if it was present. As such, I'm closing this. I'll still keep this in mind as I continue to test, though. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 9 14:54:03 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 May 2011 14:54:03 -0000 Subject: [Varnish] #910: handling esi:include target with pipe crashes varnish In-Reply-To: <045.362ec39f64f63f3ab9bb5674a1479015@varnish-cache.org> References: <045.362ec39f64f63f3ab9bb5674a1479015@varnish-cache.org> Message-ID: <054.7fdf0b2855da2dd1018cc8efc3e3c16e@varnish-cache.org> #910: handling esi:include target with pipe crashes varnish -----------------------+---------------------------------------------------- Reporter: askalski | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: wontfix | Keywords: -----------------------+---------------------------------------------------- Comment(by askalski): Two comments about the wontfix resolution, before I let this ticket go (I don't use pipe, so the crash doesn't actually affect me)... 1. Shouldn't this at least be a documentation fix? 2. I can dream up scenarios where the assert would be undesirable. The varnish administrator may be a different person/team/organization from the people publishing HTML pages. Are assertions an appropriate way to perform input validation? I would think that if it's at all possible, an attempted "pipe" on an esi-include should skip over esi tag and log an error to shmlog. That way, an admin who cared about that type of error could monitor and alert on the shmlog. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 10 10:48:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 May 2011 10:48:12 -0000 Subject: [Varnish] #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 In-Reply-To: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> References: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> Message-ID: <052.f4c6ffed9c1d2a18b19ecf96e07dcd24@varnish-cache.org> #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 ------------------------------------------------------+--------------------- Reporter: kdajka | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: 3b4859455803b606107c07b25b784372d5665a1f | ------------------------------------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [1184eddd7337d1ee6312dac629aaca0ac2fdebcf]) Do not bail out of the VGZ functions if WRW fails to write, we may still need the object. Instead, add a WRW_error() function to query if there are WRW trouble. Fixes #904 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 10 11:02:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 May 2011 11:02:51 -0000 Subject: [Varnish] #911: parameter "vcc_err_unref" don't work on subroutine In-Reply-To: <044.ef9e036d5a190efdfa3fb5153709cb59@varnish-cache.org> References: <044.ef9e036d5a190efdfa3fb5153709cb59@varnish-cache.org> Message-ID: <053.fc8cb48f70b339f7c49453651cdd4535@varnish-cache.org> #911: parameter "vcc_err_unref" don't work on subroutine ------------------------------+--------------------------------------------- Reporter: ehocdet | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: vcc_err_unref ------------------------------+--------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [f830854cdbaf40870d810d35d1cd6667352f0daa]) vcc_err_unref=false should also allow unreferenced subroutines. Submitted by: ehocdet Fixes #911 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 10 11:13:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 May 2011 11:13:49 -0000 Subject: [Varnish] #899: Mixing of compressed and uncompressed content with ESI In-Reply-To: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> References: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> Message-ID: <054.a94a0aa7bd687f17b233ec9de301d9ec@varnish-cache.org> #899: Mixing of compressed and uncompressed content with ESI ---------------------------+------------------------------------------------ Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ Changes (by phk): * owner: phk => kristian * component: varnishd => documentation Comment: After further thinking, I have concluded that this is not something we can put a bandaid on, as -spersistent will invalidate any such attempt. This is now a documentation issue: "Don't Do That Then". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 10 19:56:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 May 2011 19:56:33 -0000 Subject: [Varnish] #913: Regsub on unset header doesn't work, but autovivifies Message-ID: <040.44a4a1d39e5a45c0021e9589aa2c178d@varnish-cache.org> #913: Regsub on unset header doesn't work, but autovivifies -------------------+-------------------------------------------------------- Reporter: jib | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.5 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- If the behaviour is undefined currently, I'd suggest making it autovivify on first use, meaing that X-Test-OneLine would hold '1 2' with a patch. Also broken in git HEAD at revision: ~/sources/git/varnish-cache$ git log | head -1 commit f830854cdbaf40870d810d35d1cd6667352f0daa $ dpkg -l | grep varnish ii libvarnish1 2.1.5-1~lucid4 shared libraries for Varnish ii varnish 2.1.5-1~lucid4 a state-of-the-art, high-performance HTTP ac ==================================================== sub vcl_deliver { remove resp.http.X-Test-OneLine; remove resp.http.X-Test-TwoLine; set resp.http.X-Test-OneLine = regsub( resp.http.X-Test-OneLine, "$", "1 2" ); set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", "1" ); set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", "2" ); } $ curl -Is http://localhost:6081/ | grep X-Test X-Test-OneLine: X-Test-TwoLine: 2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 11 09:30:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 May 2011 09:30:53 -0000 Subject: [Varnish] #876: Can't start varnish: "SHMFILE owned by running varnishd master" In-Reply-To: <042.b152ffb1624d0390243a17893e133b5d@varnish-cache.org> References: <042.b152ffb1624d0390243a17893e133b5d@varnish-cache.org> Message-ID: <051.20a5b4647d6b10f24bd027cd4ca48d25@varnish-cache.org> #876: Can't start varnish: "SHMFILE owned by running varnishd master" -------------------+-------------------------------------------------------- Reporter: wijet | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.3 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by rback): I had this same problem after one of our servers lost power. Varnish wouldn't start until I restarted the process in /proc/PID/cmdline. To get varnishlog and varnishncsa working I had to delete the _.vsl file. Before that they would start but not report any traffic. My varnish version is 2.1.4 on Red Hat 5.5. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 13 21:22:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 May 2011 21:22:48 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd Message-ID: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd -----------------------------+---------------------------------------------- Reporter: drwilco | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishadm Version: trunk | Severity: normal Keywords: varnishadm | -----------------------------+---------------------------------------------- When using 'param.show -l' I got errors. A little digging showed that varnishadm uses a non-blocking socket to communicate with varnishd, but doesn't take EAGAIN/EWOULDBLOCK fully into account when reading responses. My patch fixes that by always doing a poll() before trying to read. https://github.com/drwilco/varnish- cache/commit/5094c2ae175d8335c79838ee5ecf89e3f9d4efb8 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat May 14 04:00:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 14 May 2011 04:00:22 -0000 Subject: [Varnish] #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes Message-ID: <042.bfce08d5f32e25c94a2694278228a89a@varnish-cache.org> #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes ------------------------------+--------------------------------------------- Reporter: jnlin | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: presistent cache | ------------------------------+--------------------------------------------- Hello All, I have tried varnish recently but found it crashes every 10 minutes: tmp-1-117 [/big] -jnlin- varnishd -V varnishd (varnish-3.0.0-beta1 revision varnish-3.0.0-beta1) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS tmp-1-117 [/big] -jnlin- uname -a FreeBSD tmp-1-117 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 tmp-1-117 [/big] -jnlin- dmesg -a | less -RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x280692a008 { fd = 17, id = 17, xid = 617873085, client = 10.1.1.5 1799, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x280692a080 { id = "sess", {s,f,r,e} = {0x280692ace0,+2520,0x0,+65536}, }, http[req] = { ws = 0x280692a080[sess] "GET", "/f.pixnet.net/js/all.js?v=545d6dbf1980b02c6ff9e5ea863d979f", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: */*", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", "Connection: k pid 95058 (varnishd), uid 65534: exited on signal 6 May 13 02:04:14 tmp-1-117 /big[35707]: Child (95058) Panic message: Assert error in smp_allocobj(), storage_persistent.c line 497: Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident = FreeBSD,8.2-RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x28071dd008 { fd = 33, id = 33, xid = 637471130, client = 10.1.1.5 49373, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x28071dd080 { id = "sess", {s,f,r,e} = {0x28071ddce0,+2536,0x0,+65536}, }, http[req] = { ws = 0x28071dd080[sess] "GET", "/panel/images/blog/common/pixmore/trans.gif", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: image/png,image/*;q=0.8,*/*;q=0.5", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", pid 49696 (varnishd), uid 65534: exited on signal 6 May 13 02:04:17 tmp-1-117 /big[35707]: Child (49696) Panic message: Assert error in smp_allocobj(), storage_persistent.c line 497: Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident = FreeBSD,8.2-RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x2807136008 { fd = 20, id = 20, xid = 89186144, client = 10.1.1.6 44867, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x2807136080 { id = "sess", {s,f,r,e} = {0x2807136ce0,+2536,0x0,+65536}, }, http[req] = { ws = 0x2807136080[sess] "GET", "/common/toolbar/userinfo.css?v=545d6dbf1980b02c6ff9e5ea863d979f", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: text/css,*/*;q=0.1", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", pid 94341 (varnishd), uid 65534: exited on signal 6 [...sniped...] My varnish config is here: https://gist.github.com/970095 And my parameters of running varnish is: tmp-1-117 [/big] -jnlin- sudo varnishd -a :3128 -T 127.0.0.1:6082 -f /big/test.vcl -n /big -s persistent,/big/cache/varnish.cache,96G -w 100,2000 -u nobody -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 00:42:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 00:42:06 -0000 Subject: [Varnish] #916: [PATCH] VCC assert error Message-ID: <044.85c048fbc77a690403c403d44b1d9d4c@varnish-cache.org> #916: [PATCH] VCC assert error ---------------------+------------------------------------------------------ Reporter: drwilco | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: VCC | ---------------------+------------------------------------------------------ This VCL: {{{ backend s1 { .host = "localhost"; .port = "8080"; } sub vcl_fetch { if (req.backend == s-1){ set req.backend = s-1; } } }}} Gives the following error: {{{ Message from VCC-compiler: Assert error in vcc_expr4(), vcc_expr.c line 674: Condition((sym->eval) != 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed Command failed with error code 106 }}} This is because VCC adds a symbol when it adds a reference, but the symbol does not get the eval field filled, like it should. The simple fix would probably be to add a check for sym->ndef == 0 and put an error out, but in the above VCL that would have the weird side effect of erroring on the second reference until it is fixed and then erroring on the first reference. Instead I fixed it by having vcc_AddRef use VCC_FindSymbol, instead of VCC_GetSymbolTok, and putting a nice error message in there. And calls to vcc_AddRef are now followed by ERRCHK or an assert if the error should not be possible. Patch: https://github.com/drwilco/varnish- cache/commit/9659fe48be9f8aafd82063601cbe5196c40fabe4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 00:44:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 00:44:08 -0000 Subject: [Varnish] #916: [PATCH] VCC assert error In-Reply-To: <044.85c048fbc77a690403c403d44b1d9d4c@varnish-cache.org> References: <044.85c048fbc77a690403c403d44b1d9d4c@varnish-cache.org> Message-ID: <053.815f5f2af8c9b361371b14f6312fba37@varnish-cache.org> #916: [PATCH] VCC assert error ---------------------+------------------------------------------------------ Reporter: drwilco | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: VCC | ---------------------+------------------------------------------------------ Comment(by drwilco): "This is because VCC adds a symbol when it adds a reference, but the symbol does not get the eval field filled, like it should. " should read "This is because VCC adds a symbol when it adds a reference '''to an undefined symbol''', but the symbol does not get the eval field filled, like it should." -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 09:05:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 09:05:30 -0000 Subject: [Varnish] #917: CLI here documents do not work for ban command Message-ID: <040.212a1832c3ca6de1ba9b3457d3c23508@varnish-cache.org> #917: CLI here documents do not work for ban command ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- It is not possible to use CLI here documents to enter bans via CLI (this would eliminate the backslash-escape issue in #755) -- Ticket URL: Varnish The Varnish HTTP Accelerator From oliver at j-o-a.de Mon May 16 09:12:59 2011 From: oliver at j-o-a.de (Oliver Joa) Date: Mon, 16 May 2011 11:12:59 +0200 Subject: Segfault in varnishncsa (3.0.0-beta1) Message-ID: <4DD0EA9B.8040906@j-o-a.de> Hi, varnishncsa (3.0.0-beta1) crashes with segfault after a PURGE-Request. It happens only when I use a Format-String: varnishncsa -F '%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i" %{Varnish:hitmiss}x' Thanks Oliver Joa From varnish-bugs at varnish-cache.org Mon May 16 09:23:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 09:23:06 -0000 Subject: [Varnish] #917: CLI here documents do not work for ban command In-Reply-To: <040.212a1832c3ca6de1ba9b3457d3c23508@varnish-cache.org> References: <040.212a1832c3ca6de1ba9b3457d3c23508@varnish-cache.org> Message-ID: <049.9aa984f902c13350744a897d8a214027@varnish-cache.org> #917: CLI here documents do not work for ban command ----------------------+----------------------------------------------------- Reporter: phk | 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: Fixed in 8d15ec9f4ed5a3089fb287db20643b41051f657e -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 09:40:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 09:40:46 -0000 Subject: [Varnish] #755: Incorrect escaping of purges In-Reply-To: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> References: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> Message-ID: <054.c280c018560214484f0580c4e900c950@varnish-cache.org> #755: Incorrect escaping of purges ----------------------+----------------------------------------------------- Reporter: kristian | Owner: kristian 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: Ok, I think I got to the bottom of this mess now. The reason you need to escape \ here is that CLI has quoted strings. I am not prepared to rule that we will never need a CLI argument with a space in it, so CLI quoted arguments are here to stay, which means that " needs to be quoted and consequently \ also. We could restrict \ escaping to "..." quoted arguments in the CLI, which would allow you to give \.foo as a blank argument, but that would only work for regexp's without whitespace. The real solution is to use a CLI here document, which eliminates the need for any kind of escaping. However, this did not work for CLI commands forwarded to the child process. This issue is fixed under ticket #917, and so I think we can now also close this ticket: Use a here document: {{{ ban req.url ~ << FOSDKFJDSLKF \.bar FOSDKFJDSLKF }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 10:30:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 10:30:53 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.691ef72ec7bec98c7f198d0c1b6c446b@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Keywords: varnishadm ------------------------+--------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 10:31:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 10:31:33 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.9a9b0dbffb463368706d0d3af8656c14@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: tfheen Type: defect | Status: assigned Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Keywords: varnishadm ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => assigned Comment: Looks reasonable, but I'll have to understand the change first before committing it. Will hopefully get to it this week. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 10:40:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 10:40:04 -0000 Subject: [Varnish] #913: Regsub on unset header doesn't work, but autovivifies In-Reply-To: <040.44a4a1d39e5a45c0021e9589aa2c178d@varnish-cache.org> References: <040.44a4a1d39e5a45c0021e9589aa2c178d@varnish-cache.org> Message-ID: <049.a8046db813eb93fb6baa0fe8cb3724ac@varnish-cache.org> #913: Regsub on unset header doesn't work, but autovivifies -------------------+-------------------------------------------------------- Reporter: jib | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.5 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Description changed by phk: Old description: > If the behaviour is undefined currently, I'd suggest making it autovivify > on first use, > meaing that X-Test-OneLine would hold '1 2' with a patch. > > Also broken in git HEAD at revision: > ~/sources/git/varnish-cache$ git log | head -1 > commit f830854cdbaf40870d810d35d1cd6667352f0daa > > $ dpkg -l | grep varnish > ii libvarnish1 2.1.5-1~lucid4 > shared libraries for Varnish > ii varnish 2.1.5-1~lucid4 a > state-of-the-art, high-performance HTTP ac > > ==================================================== > > sub vcl_deliver { > remove resp.http.X-Test-OneLine; > remove resp.http.X-Test-TwoLine; > set resp.http.X-Test-OneLine = regsub( resp.http.X-Test-OneLine, "$", > "1 2" ); > set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", > "1" ); > set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", > "2" ); > } > > $ curl -Is http://localhost:6081/ | grep X-Test > X-Test-OneLine: > X-Test-TwoLine: 2 New description: If the behaviour is undefined currently, I'd suggest making it autovivify on first use, meaing that X-Test-OneLine would hold '1 2' with a patch. Also broken in git HEAD at revision: ~/sources/git/varnish-cache$ git log | head -1 commit f830854cdbaf40870d810d35d1cd6667352f0daa {{{ $ dpkg -l | grep varnish ii libvarnish1 2.1.5-1~lucid4 shared libraries for Varnish ii varnish 2.1.5-1~lucid4 a state-of-the-art, high-performance HTTP ac ==================================================== sub vcl_deliver { remove resp.http.X-Test-OneLine; remove resp.http.X-Test-TwoLine; set resp.http.X-Test-OneLine = regsub( resp.http.X-Test-OneLine, "$", "1 2" ); set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", "1" ); set resp.http.X-Test-TwoLine = regsub( resp.http.X-Test-OneLine, "$", "2" ); } $ curl -Is http://localhost:6081/ | grep X-Test X-Test-OneLine: X-Test-TwoLine: 2 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 11:05:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 11:05:58 -0000 Subject: [Varnish] #913: Regsub on unset header doesn't work, but autovivifies In-Reply-To: <040.44a4a1d39e5a45c0021e9589aa2c178d@varnish-cache.org> References: <040.44a4a1d39e5a45c0021e9589aa2c178d@varnish-cache.org> Message-ID: <049.4119466db847b369d3c74f4c30f7af96@varnish-cache.org> #913: Regsub on unset header doesn't work, but autovivifies ---------------------+------------------------------------------------------ Reporter: jib | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.5 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [25228a235b50c2e3b224a08473954bc99cf1d365]) VCL regexp and regsub should treat a NULL argument as an empty string. Fixes #913 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 11:58:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 11:58:21 -0000 Subject: [Varnish] #918: Segfault in varnishncsa (3.0.0-beta1) Message-ID: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> #918: Segfault in varnishncsa (3.0.0-beta1) -----------------------------+---------------------------------------------- Reporter: olli | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Hi, varnishncsa (3.0.0-beta1) crashes with segfault after a PURGE-Request. It happens only when I use a Format-String: varnishncsa -F '%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i" %{Varnish:hitmiss}x' Sorry if I made wrong, but I don't know how to report this Bug. Thanks Oliver Joa -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 12:30:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 12:30:04 -0000 Subject: [Varnish] #900: The \" escape does not work. In-Reply-To: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> References: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> Message-ID: <054.efca159fa9ee325cb946c479f578d493@varnish-cache.org> #900: The \" escape does not work. ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): While the above is fixed, this is now an issue. To ban \foo, the \ needs to be escaped in the ban() function of VCL. This seems to be somewhat flawed. VCL first. VCL {{{ backend foo { .host = "kly.no"; } sub vcl_recv { if (req.url ~ "ban") { ban("req.url ~ \digit1"); ban("req.url ~ \\digit2"); ban("req.url ~ \\\digit3"); ban("req.url ~ \\\\digit4"); ban("req.url ~ \\\\\digit5"); error 200 "BANNED"; } } }}} After a request to blatti followed by /ban (note that \d is a valid regex matching digits.): {{{ ban.list 200 117 0x7f68ad118080 1305548665.244920 0 req.url ~ \\digit4 0x7f68ad118040 1305548665.244900 0 req.url ~ \digit2 }}} This is also not all that neat on CLI. This is after adding a single object to the cache: {{{ stop Stopping Child 200 0 Child (29754) said Child dies Child (29754) died Child cleanup complete start child (29775) Started 200 0 Child (29775) said Child starts ban req.url ~ \digit1 100 85 Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence ban req.url ~ \\digit2 100 85 Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence ban req.url ~ \\\digit3 100 85 Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence ban req.url ~ \\\\digit4 200 0 ban req.url ~ \\\\\digit5 100 85 Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence ban.list 200 58 0x7f68b5819f40 1305548943.609118 0 req.url ~ \digit4 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 12:32:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 12:32:30 -0000 Subject: [Varnish] #900: The \" escape does not work. In-Reply-To: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> References: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> Message-ID: <054.5e5cb1dffe30026b1097892ebd6e37c2@varnish-cache.org> #900: The \" escape does not work. ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Oh, and to ban (any digit)igit on cli: {{{ ban req.url ~ \\\\\\\\digit 200 0 ban.list 200 58 0x7f68b5819f00 1305549101.169183 0 req.url ~ \\digit }}} .... that's 8 \'s. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 13:03:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 13:03:55 -0000 Subject: [Varnish] #900: The \" escape does not work. In-Reply-To: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> References: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> Message-ID: <054.a078e41571837d0b71499a1d6092ea60@varnish-cache.org> #900: The \" escape does not work. ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): The VCL case looks right to me. \d is a regexp magic, so only the lines with an even number of \\ are valid regexps. The rest should give a syntax error in VSL. Similarly you end up with 8 \\ in the CLI case because you need to get a double \\ to the regexp. A better and less confusiing testcase would be the regexp \.bar. I seem to reproduce that needs \\\\.bar from CLI, will investigate. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 16 13:21:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 May 2011 13:21:28 -0000 Subject: [Varnish] #900: The \" escape does not work. In-Reply-To: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> References: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> Message-ID: <054.fb6bb92b13be96f8b41e5376445bb512@varnish-cache.org> #900: The \" escape does not work. ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [c4d7754730928c8fe66a206958de5a7b40b9a9ff]) Correctly quote backslash, even if it is the only thing that needs quoting in the string. Fixes #900 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 17 14:19:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 May 2011 14:19:30 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.6300c76ba3e428ea29603cb80f85f134@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: tfheen Type: defect | Status: assigned Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Keywords: varnishadm ------------------------+--------------------------------------------------- Comment(by drwilco): While you're getting up to speed on the fix, take this along as well: https://github.com/drwilco/varnish- cache/commit/456ca99dfc24fc473b96b126db132623fe777d81 The old line is pretty much ignoring the -t parameter (or the 5 second default), and slotting in a 33.3 minute timeout. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 18 09:32:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 May 2011 09:32:12 -0000 Subject: [Varnish] #919: 503 error from varish while apache returns 200 Message-ID: <042.ce36521e27a423cd056033b77372ee69@varnish-cache.org> #919: 503 error from varish while apache returns 200 ------------------------+--------------------------------------------------- Reporter: damol | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: 503 centos | ------------------------+--------------------------------------------------- in one of 10000 requests i am recieving an 503 error. with mostly this rule in my varnishlog: {{{ 30 FetchError c http read error: 11 }}} my varnish.vcl: {{{ # This is the configuration of varnish this file contains several checks that decides to cache a page or not. # Author: Daan Molenaar C{ #include #include #include }C # first we tell how we can talk to the default webserver backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 600s; .first_byte_timeout = 600s; .between_bytes_timeout = 600s; } sub vcl_recv { ## check the custom configuration file if the url is allowed to be handled by varnish C{ FILE * pFile; long lSize; char * buffer; size_t result; pFile = fopen ( "/etc/varnish/websites.cfg" , "rb" ); if (pFile==NULL) {fputs ("File error",stderr); exit (1);} // obtain file size: fseek (pFile , 0 , SEEK_END); lSize = ftell (pFile); rewind (pFile); // allocate memory to contain the whole file: buffer = (char*) malloc (sizeof(char)*lSize); if (buffer == NULL) {fputs ("Memory error",stderr); exit (2);} // copy the file into the buffer: result = fread (buffer,1,lSize,pFile); if (result != lSize) {fputs ("Reading error",stderr); exit (3);} /* the whole file is now loaded in the memory buffer. */ char *host = VRT_GetHdr(sp, HDR_REQ, "\005Host:"); char * pch; // add a < and > to be sure you get the complete host char new_host[80]; strcpy (new_host,"<"); strcat (new_host,host); strcat (new_host,">"); pch = strstr (buffer, new_host); if(pch){ VRT_SetHdr(sp, HDR_REQ, "\014X-May-Cache:", "YES", vrt_magic_string_end); } // terminate fclose (pFile); free (buffer); }C # if caching for this website is not enabled if (req.http.X-May-Cache !~ "YES") { return(pass); } ## Default request checks if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { # Non-RFC2616 or CONNECT which is weird. return (pipe); } if (req.request != "GET" && req.request != "HEAD") { # We only deal with GET and HEAD by default return (pass); } ## Remove has_js and Google Analytics cookies. set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+)=[^;]*", ""); ## set the browser to IE because the content does not differ set req.http.user-agent = "MSIE"; ## Remove a ";" prefix, if present. set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); ## Remove empty cookies. if (req.http.Cookie ~ "^\s*$") { unset req.http.Cookie; } ## Let's have a little grace set req.grace = 60s; ## Normalize the Accept-Encoding header ## as per: http://varnish-cache.org/wiki/FAQ/Compression if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$" || req.url ~ "robots\.txt") { # No point in compressing these remove req.http.Accept-Encoding; } elsif (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 encoding algorithm remove req.http.Accept-Encoding; } } ## cache css js and images always also when no user is logged in if (req.url ~ "\.(css|js|jpg|jpeg|gif|ico|png)$") { lookup; } ## No varnish for install,update.php or cron.php if (req.url ~ "install\.php|update\.php|cron\.php") { return (pass); } if (req.http.Cookie ~ "NO_CACHE=Y") { # there is no "no-cache" cookie set in the site return (pass); } lookup; } sub vcl_fetch { // set the time to live to one hour set obj.ttl = 3600s; set obj.grace = 60s; } ### vcl_hash creates the key for varnish under which the object is stored. It is ### possible to store the same url under 2 different keys, by making vcl_hash ### create a different hash. sub vcl_hash { ## these 2 entries are the default ones used for vcl. Below we add our own. set req.hash += req.url; set req.hash += req.http.host; ## cache css js and images always #if(req.url !~ "\.(css|js|jpg|jpeg|gif|ico|png)$"){ ## Remove the SESSION cookie from the cookie and save it in the Hash set req.http.X-SYNETIC-COOKIE-NO-SESS = regsuball(req.http.Cookie, "(^|; ) *SESS[A-Za-z0-9=]+;? *", "\1"); set req.hash += req.http.X-SYNETIC-COOKIE-NO-SESS; #} hash; } sub vcl_error { // Let's deliver a slightly more friedly error page. // You can customize this as you wish. set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" "} obj.status " " obj.response {"

Page Could Not Be Loaded

We're very sorry, but the page could not be loaded properly. This should be fixed very soon, and we apologize for any inconvenience.

Debug Info:

                         Status: "} obj.status {"
                         Response: "} obj.response {"
                         XID: "} req.xid {"
Varnish
"}; deliver; } sub vcl_deliver { return (deliver); } }}} i am running centos 5.5 64x -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun May 22 06:56:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 22 May 2011 06:56:11 -0000 Subject: [Varnish] #920: Add the ability to set daemon options for varnishncsa Message-ID: <043.506aef4093cd07d52eaff17f09c80259@varnish-cache.org> #920: Add the ability to set daemon options for varnishncsa --------------------+------------------------------------------------------- Reporter: mkania | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- Would it be possible to have daemon options for varnishncsa in /etc/default/varnishncsa? This would allow me to have the ncsa logging daemon start with all the necessary flags without me having to modify the init script and add the daemon options manually. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun May 22 14:08:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 22 May 2011 14:08:17 -0000 Subject: [Varnish] #918: Segfault in varnishncsa (3.0.0-beta1) In-Reply-To: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> References: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> Message-ID: <050.782302553386f3d05dd722f466c15849@varnish-cache.org> #918: Segfault in varnishncsa (3.0.0-beta1) -----------------------------+---------------------------------------------- Reporter: olli | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Comment(by mkania): I am also getting a segfault with varnishncsa on varnish 3.0 beta 1. {{{ [46845.461643] varnishncsa[21183]: segfault at 0 ip 00007fabf3513b52 sp 00007fff33ea6088 error 4 in libc-2.11.2.so[7fabf3498000+158000] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 07:20:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 07:20:04 -0000 Subject: [Varnish] #916: [PATCH] VCC assert error In-Reply-To: <044.85c048fbc77a690403c403d44b1d9d4c@varnish-cache.org> References: <044.85c048fbc77a690403c403d44b1d9d4c@varnish-cache.org> Message-ID: <053.edcc7c4f9cc14e1795440f7f56b9a432@varnish-cache.org> #916: [PATCH] VCC assert error ----------------------+----------------------------------------------------- Reporter: drwilco | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: fixed | Keywords: VCC ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [aa07de47e21abce49b35a51d27c80c03b71e0f36]) Don't allow symbols in expressions unless we can evaluate them. Fixes: #916 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 08:47:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 08:47:10 -0000 Subject: [Varnish] #899: Mixing of compressed and uncompressed content with ESI In-Reply-To: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> References: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> Message-ID: <054.f920f6ea3d599556ee3125f9c3d2cbba@varnish-cache.org> #899: Mixing of compressed and uncompressed content with ESI ---------------------------+------------------------------------------------ Reporter: kristian | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by Kristian Lyngstol ): * status: new => closed * resolution: => fixed Comment: (In [feba4935cc0f07bb248554d1fe96fdacfbb95459]) Document gzip-enabled- later + ESI Closes #899 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 10:04:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 10:04:47 -0000 Subject: [Varnish] #920: Add the ability to set daemon options for varnishncsa In-Reply-To: <043.506aef4093cd07d52eaff17f09c80259@varnish-cache.org> References: <043.506aef4093cd07d52eaff17f09c80259@varnish-cache.org> Message-ID: <052.4e355042b09f830d87beebf3d154ecc8@varnish-cache.org> #920: Add the ability to set daemon options for varnishncsa ------------------------+--------------------------------------------------- Reporter: mkania | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Resolution: duplicate | Keywords: ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: Duplicate of #831 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 10:08:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 10:08:17 -0000 Subject: [Varnish] #918: Segfault in varnishncsa (3.0.0-beta1) In-Reply-To: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> References: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> Message-ID: <050.94e969888b369f6a37faf19c4167bd02@varnish-cache.org> #918: Segfault in varnishncsa (3.0.0-beta1) -------------------------+-------------------------------------------------- Reporter: olli | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishncsa | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 10:11:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 10:11:53 -0000 Subject: [Varnish] #919: 503 error from varish while apache returns 200 In-Reply-To: <042.ce36521e27a423cd056033b77372ee69@varnish-cache.org> References: <042.ce36521e27a423cd056033b77372ee69@varnish-cache.org> Message-ID: <051.6ceda7c03d66e341b4cef7325bf6e931@varnish-cache.org> #919: 503 error from varish while apache returns 200 --------------------+------------------------------------------------------- Reporter: damol | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: 503 centos --------------------+------------------------------------------------------- Changes (by tfheen): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 23 10:28:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 May 2011 10:28:01 -0000 Subject: [Varnish] #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable In-Reply-To: <046.30ca96fa862f0e17f0d65adc58e171b7@varnish-cache.org> References: <046.30ca96fa862f0e17f0d65adc58e171b7@varnish-cache.org> Message-ID: <055.aaf200406d6abd9a98bd305ec2a4a4b2@varnish-cache.org> #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable ---------------------------+------------------------------------------------ Reporter: thiagocsf | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Resolution: fixed Keywords: cacheable 307 | ---------------------------+------------------------------------------------ Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [0fb00eb730e9a41b8cc696607585d9982764fe39]) Add 307 Temporary Redirect to the list of responses we consider cacheable. Fixes #908 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 24 00:47:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 May 2011 00:47:07 -0000 Subject: [Varnish] #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec Message-ID: <040.9e1623b96dbcd9a138f50f34a418c0ea@varnish-cache.org> #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec -----------------------------+---------------------------------------------- Reporter: agd | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- i've built {{{ varnishd -V varnishd (varnish-3.0.0-beta1 revision 0fb00eb) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS }}} on linux 64-bit. @ service start, {{{ service varnish start Starting varnish SMF.s0: filename: /var/cache/varnish/test1/test1.file.backend size 400 MB. Message from C-compiler: ./vcl.1P9zoqAU.c: In function 'VGC_function_test1site_vcl_recv': ./vcl.1P9zoqAU.c:950:13: warning: passing argument 3 of 'VRT_regsub' from incompatible pointer type ./vcl.1P9zoqAU.c:223:13: note: expected 'const char *' but argument is of type 'struct sockaddr_storage *' ./vcl.1P9zoqAU.c:961:13: warning: passing argument 3 of 'VRT_regsub' from incompatible pointer type ./vcl.1P9zoqAU.c:223:13: note: expected 'const char *' but argument is of type 'struct sockaddr_storage *' }}} but checking, {{{ ps ax | grep -i varnish 29982 ? Ss 0:00 /usr/local/sbin/varnishd -f /usr/local/etc/varnish/vcl.test1.conf -a 127.0.0.1:7100,[::1]:7100 -T 127.0.0.1:7101 -s file,/var/cache/varnish/test1/test1.file.backend,400M -p queue_max 2000 -p thread_pools 4 -p thread_pool_min 200 -p thread_pool_max 4000 -p thread_pool_add_delay 2 -h critbit -p listen_depth 2048 -p sess_timeout 600 -p session_linger 50 -p sess_workspace 16384 -P /var/run/varnish.pid -n test1 29983 ? Sl 0:00 /usr/local/sbin/varnishd -f /usr/local/etc/varnish/vcl.test1.conf -a 127.0.0.1:7100,[::1]:7100 -T 127.0.0.1:7101 -s file,/var/cache/varnish/test1/test1.file.backend,400M -p queue_max 2000 -p thread_pools 4 -p thread_pool_min 200 -p thread_pool_max 4000 -p thread_pool_add_delay 2 -h critbit -p listen_depth 2048 -p sess_timeout 600 -p session_linger 50 -p sess_workspace 16384 -P /var/run/varnish.pid -n test1 }}} and my site's accessible, caching appearing OK checking in the vcl for instances of regsub, i've {{{ sub test1site_vcl_recv { ... if (req.http.X-Forwarded-For) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + regsub(client.ip, ":.*", ""); } else { set req.http.X-Forwarded-For = regsub(client.ip, ":.*", ""); } ... set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); ... } }}} checking compiled output (-C), ~ lineno 220, {{{ ... /* Regexp related */ void VRT_re_init(void **, const char *); void VRT_re_fini(void *); int VRT_re_match(const char *, void *re); const char *VRT_regsub(const struct sess *sp, int all, const char *, void *, const char *); void VRT_panic(const struct sess *sp, const char *, ...); ... }}} & ! lineno 942 {{{ ... if ( (VRT_GetHdr(sp, HDR_REQ, "\020X-Forwarded-For:") != 0) ) { VRT_count(sp, 21); VRT_SetHdr(sp, HDR_REQ, "\020X-Forwarded-For:", VRT_GetHdr(sp, HDR_REQ, "\020X-Forwarded-For:"), ", ", VRT_regsub(sp, 0, VRT_r_client_ip(sp), VGC_re_5 , ""), vrt_magic_string_end ); } else { VRT_count(sp, 22); VRT_SetHdr(sp, HDR_REQ, "\020X-Forwarded-For:", VRT_regsub(sp, 0, VRT_r_client_ip(sp), VGC_re_6 , ""), vrt_magic_string_end ); } ... }}} are those 'warnings' (not errors) anything to worry about? is there an issue with any of the used syntax? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 25 04:20:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 May 2011 04:20:57 -0000 Subject: [Varnish] #922: Missing errorhandling code in cnt_error() Message-ID: <043.e7c41968f1ef5dd3fca0498aad837ff5@varnish-cache.org> #922: Missing errorhandling code in cnt_error() -----------------------------+---------------------------------------------- Reporter: mkania | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- I've had one crash so far testing 3.0beta1. This is the output from panic.show {{{ varnish> panic.show 200 Last panic at: Wed, 25 May 2011 02:14:31 GMT Missing errorhandling code in cnt_error(), cache_center.c line 418: Condition((sp->obj) != 0) not true.errno = 110 (Connection timed out) thread = (cache-worker) ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42d368: /usr/sbin/varnishd() [0x42d368] 0x41793e: /usr/sbin/varnishd() [0x41793e] 0x418165: /usr/sbin/varnishd(CNT_Session+0x245) [0x418165] 0x42f958: /usr/sbin/varnishd() [0x42f958] 0x42eb49: /usr/sbin/varnishd() [0x42eb49] 0x7f23348248ba: /lib/libpthread.so.0(+0x68ba) [0x7f23348248ba] 0x7f233458c02d: /lib/libc.so.6(clone+0x6d) [0x7f233458c02d] sp = 0x7f1f3623b008 { fd = 65, id = 65, xid = 45290058, client = 10.6.14.10 60026, step = STP_ERROR, handling = error, err_code = 503, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f1f3623b080 { id = "sess", {s,f,r,e} = {0x7f1f3623bcf0,+416,(nil),+65536}, }, http[req] = { ws = 0x7f1f3623b080[sess] "HEAD", "/dist/blacklist.xml", "HTTP/1.1", "Host: varnish-cache", "Accept-Encoding: identity", "Max-Forwards: 10", "Connection: Keep-Alive", "X-Forwarded-For: 10.3.7.15, 10.6.14.10", }, worker = 0x7f1f52b51b90 { ws = 0x7f1f52b51d30 { id = "wrk", {s,f,r,e} = {0x7f1f52b3fb20,+24,(nil),+65536}, }, }, vcl = { srcname = { "input", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 25 12:55:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 May 2011 12:55:01 -0000 Subject: [Varnish] #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 Message-ID: <043.ce557490a286e8322c8667a2cfa4e751@varnish-cache.org> #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 ------------------------------------------------------+--------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishlog Version: trunk | Severity: normal Keywords: bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 | ------------------------------------------------------+--------------------- When using varnishlog from latest trunk - bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 I'm getting segfaults. {{{ webadm at varnishic06:~$ gdb -c core.4176 varnish/bin/varnishlog GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/local/inp/varnish_bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398/lib/varnish/libvarnish.so...done. Loaded symbols for /usr/local/inp/varnish/lib/varnish/libvarnish.so Reading symbols from /usr/local/inp/varnish_bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398/lib/varnish/libvarnishcompat.so...done. Loaded symbols for /usr/local/inp/varnish/lib/varnish/libvarnishcompat.so Reading symbols from /usr/local/inp/varnish_bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398/lib/libvarnishapi.so.1...done. Loaded symbols for /usr/local/inp/varnish/lib/libvarnishapi.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.3...done. Loaded symbols for /usr/lib/libpcre.so.3 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by `varnishlog -o -n blox_varnishic06'. Program terminated with signal 11, Segmentation fault. [New process 4176] #0 0x0000000000401552 in h_order (priv=0x16dd010, tag=SLT_Length, fd=4294967295, len=6, spec=0, ptr=0x7f3e3a2d4264
, bm=0) at varnishlog.c:100 100 varnishlog.c: No such file or directory. in varnishlog.c (gdb) bt #0 0x0000000000401552 in h_order (priv=0x16dd010, tag=SLT_Length, fd=4294967295, len=6, spec=0, ptr=0x7f3e3a2d4264
, bm=0) at varnishlog.c:100 #1 0x00007f3e3f91bcaa in VSL_Dispatch (vd=0x16dd010, func=0x401524 , priv=0x16dd010) at vsl.c:308 #2 0x000000000040199e in do_order (vd=0x16dd010) at varnishlog.c:189 #3 0x0000000000401f09 in main (argc=4, argv=0x7ffffc8c6af8) at varnishlog.c:359 }}} Using 6 weeks old varnishlog with current trunk doesn't render any problems: {{{ varnish_3b4859455803b606107c07b25b784372d5665a1f_debug/bin/varnishlog }}} So it could be narrowed to 4 changes: http://www.varnish- cache.org/trac/log/bin/varnishlog/varnishlog.c?action=stop_on_copy&mode=stop_on_copy&rev=&stop_rev=6f038c18768b6dd524c392ebe2765b06f5650b27&limit=100 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 26 08:31:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 May 2011 08:31:51 -0000 Subject: [Varnish] #924: Missing errorhandling code in cnt_error(), cache_center.c line 418: Message-ID: <043.f39c953ee32bf4bb3160e0ca1be57acd@varnish-cache.org> #924: Missing errorhandling code in cnt_error(), cache_center.c line 418: --------------------+------------------------------------------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: major Keywords: | --------------------+------------------------------------------------------- Hi, I'm seeing child restarts in newest trunk bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398. I have 3 backtraces all were triggered by PURGE (the squid way), after few hours after start. This varnish instance is getting about 10 PURGE requests and ~2 bans per hour. Crashes happend after malloc fulled up. My system: Linux varnishic06 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar.pl_varnishd.pid -a :8084 \ -i foo.bar_varnishic06 -n foo.bar_varnishic06 -f /exp/confvarnish/foo.bar.pl/foo.bar.pl.vcl \ -T :2084 -h classic,20011 -p thread_pools 4 -p ban_lurker_sleep 0.1 -w 200,4000,2 \ -t 0 -s malloc,9G }}} {{{ panic.show 200 Last panic at: Wed, 25 May 2011 19:52:55 GMT Missing errorhandling code in cnt_error(), cache_center.c line 418: Condition((sp->obj) != 0) not true.thread = (cache-worker) ident = Linux,2.6.26-2-amd64,x86_64,-smalloc,-smalloc,-hclassic,epoll Backtrace: 0x434d81: pan_backtrace+16 0x434fea: pan_ic+164 0x41864a: cnt_error+12d 0x41c36a: CNT_Session+67a 0x436c0d: wrk_do_cnt_sess+12a 0x436478: wrk_thread_real+851 0x436879: wrk_thread+e5 0x7fd9a2252fc7: _end+7fd9a1bc398f 0x7fd9a1fc864d: _end+7fd9a1939015 sp = 0x7fd8414de008 { fd = 654, id = 654, xid = 909745151, client = 172.20.26.107 43629, step = STP_ERROR, handling = error, err_code = 404, err_reason = Not in cache., restarts = 0, esi_level = 0 ws = 0x7fd8414de080 { id = "sess", {s,f,r,e} = {0x7fd8414decf0,+144,(nil),+65536}, }, http[req] = { ws = 0x7fd8414de080[sess] "PURGE", "/resource/IMG_0127.jpg", "HTTP/1.1", "Host: foo.bar.pl", "x-real-forwarded-for: 172.20.26.107", }, worker = 0x7fd84ab51e10 { ws = 0x7fd84ab51fb0 { id = "wrk", {s,f,r,e} = {0x7fd84ab3fd20,+48,(nil),+65536}, }, http[bereq] = { ws = 0x7fd84ab51fb0[wrk] "GET", "/resource/IMG_0127.jpg", "HTTP/1.1", "Host: foo.bar.pl", "x-real-forwarded-for: 172.20.26.107", "X-Varnish: 909745151", "Accept-Encoding: gzip", }, }, vcl = { srcname = { "input", "Default", "/exp/confvarnish/foo.bar.pl/backends_foo.bar.pl.vcl", "/exp/confvarnish/global/500.vcl", }, }, }, }}} {{{ $ gdb -c varnish_bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398/var/varnish/foo.bar_varnishic06/ core.3297 varnish_bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398/sbin/varnishd [...] Core was generated by `/usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar.pl_varnishd.pid -a 19'. Program terminated with signal 6, Aborted. [...] (gdb) bt #0 0x00007fd9a1f2aed5 in raise () from /lib/libc.so.6 #1 0x00007fd9a1f2c3f3 in abort () from /lib/libc.so.6 #2 0x0000000000435097 in pan_ic (func=0x46d3ef "cnt_error", file=0x46d226 "cache_center.c", line=418, cond=0x46d3f9 "(sp->obj) != 0", err=0, xxx=1) at cache_panic.c:358 #3 0x000000000041864a in cnt_error (sp=0x7fd8414de008) at cache_center.c:418 #4 0x000000000041c36a in CNT_Session (sp=0x7fd8414de008) at steps.h:46 #5 0x0000000000436c0d in wrk_do_cnt_sess (w=0x7fd84ab51e10, priv=0x7fd8414de008) at cache_pool.c:300 #6 0x0000000000436478 in wrk_thread_real (qp=0x7fd9a1b0f2e0, shm_workspace=8192, sess_workspace=65536, nhttp=64, http_space=1160, siov=128) at cache_pool.c:184 #7 0x0000000000436879 in wrk_thread (priv=0x7fd9a1b0f2e0) at cache_pool.c:230 #8 0x00007fd9a2252fc7 in start_thread () from /lib/libpthread.so.0 #9 0x00007fd9a1fc864d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x0000000000435097 in pan_ic (func=0x46d3ef "cnt_error", file=0x46d226 "cache_center.c", line=418, cond=0x46d3f9 "(sp->obj) != 0", err=0, xxx=1) at cache_panic.c:358 358 cache_panic.c: No such file or directory. in cache_panic.c (gdb) print *sp $1 = {magic = 741317722, fd = 654, id = 654, xid = 909745151, restarts = 0, esi_level = 0, disable_esi = 0, hash_ignore_busy = 0 '\0', hash_always_miss = 0 '\0', wrk = 0x7fd84ab51e10, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x7fd8414de2e0, mysockaddr = 0x7fd8414de360, mylsock = 0x7fd9a1b20550, addr = 0x7fd8414decf0 "172.20.26.107", port = 0x7fd8414ded00 "43629", client_identity = 0x0, doclose = 0x0, http = 0x7fd8414de3e0, http0 = 0x7fd8414de868, ws = {{ magic = 905626964, id = 0x47286e "sess", s = 0x7fd8414decf0 "172.20.26.107", f = 0x7fd8414ded80 "0100101 Firefox/4.0.1", r = 0x0, e = 0x7fd8414eecf0 "", overflow = 0}}, ws_ses = 0x7fd8414ded08 "PURGE", ws_req = 0x7fd8414ded48 "172.20.26.107", digest = "e&\237:yB?\212;\017\216\016?j??\204??\223??\"\025??\f\227?\232?k", htc = {{magic = 1041886673, fd = 654, maxbytes = 32768, maxhdr = 2048, ws = 0x7fd8414de080, rxbuf = {b = 0x7fd8414ded08 "PURGE", e = 0x7fd8414ded48 "172.20.26.107"}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1306352754.8537035, t_req = 1306352754.8537273, t_resp = nan(0x8000000000000), t_end = 1306352754.8537035, exp = {ttl = -1, grace = 30, keep = -1}, step = STP_ERROR, cur_method = 0, handling = 1, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 404, err_reason = 0x7fd99adf70c7
, list = {vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x7fd9a1b0fa68, vbc = 0x0, obj = 0x0, objcore = 0x0, vcl = 0x7fd9a1b26428, hash_objhead = 0x0, mem = 0x7fd8414de000, workreq = { list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x436ae3 , priv = 0x7fd8414de008}, acct_tmp = {first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_ses = {first = 1306352754.8537035, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, ev = {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 26 09:26:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 May 2011 09:26:45 -0000 Subject: [Varnish] #925: Missing stats in varnishadm in v3.0 Message-ID: <043.1d7674fadfc0f3f576223245ef737546@varnish-cache.org> #925: Missing stats in varnishadm in v3.0 --------------------+------------------------------------------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishadm Version: trunk | Severity: minor Keywords: | --------------------+------------------------------------------------------- There is difference between returned stats from varnishadm between v2.1.5 and v3.0. Here are missing ones: SHM cycles through buffer SMA allocator requests SMA outstanding allocations SMA outstanding bytes SMA bytes allocated SMA bytes free SMS allocator requests SMS bytes allocated SMS bytes freed Will this stats return in new version? I'm asking because at least one monitoring system - Cacti is using telnet to connect to admin console -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 09:42:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 09:42:36 -0000 Subject: [Varnish] #925: Missing stats in varnishadm in v3.0 In-Reply-To: <043.1d7674fadfc0f3f576223245ef737546@varnish-cache.org> References: <043.1d7674fadfc0f3f576223245ef737546@varnish-cache.org> Message-ID: <052.5a8542a80ab4f6acb5accc593aae1564@varnish-cache.org> #925: Missing stats in varnishadm in v3.0 ----------------------+----------------------------------------------------- Reporter: kdajka | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: varnishadm => varnishd Comment: I have pondered this issue, and it will not be fixed, quite the contrary. The CLI::stats command was added as a quick hack back in the 1.x days and it will now be removed before the 3.0 release. This is consistent with the fact that we do not provide access the the log data from CLI either. The CLI is not designed for subscribing to stats, it is single-threaded and any TCP blocking trying to deliver stats will prevent any other CLI connection from getting anything done. The correct way to access stats in Varnish, is to access the shared memory, either using varnishstats or using the libvarnishapi functions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 09:55:50 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 09:55:50 -0000 Subject: [Varnish] #925: Missing stats in varnishadm in v3.0 In-Reply-To: <043.1d7674fadfc0f3f576223245ef737546@varnish-cache.org> References: <043.1d7674fadfc0f3f576223245ef737546@varnish-cache.org> Message-ID: <052.3762ac1fa910a30624e264733eba14d5@varnish-cache.org> #925: Missing stats in varnishadm in v3.0 ----------------------+----------------------------------------------------- Reporter: kdajka | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 13:00:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 13:00:16 -0000 Subject: [Varnish] #924: Missing errorhandling code in cnt_error(), cache_center.c line 418: In-Reply-To: <043.f39c953ee32bf4bb3160e0ca1be57acd@varnish-cache.org> References: <043.f39c953ee32bf4bb3160e0ca1be57acd@varnish-cache.org> Message-ID: <052.93d631f4ac2d756a4e6e3013ac38089f@varnish-cache.org> #924: Missing errorhandling code in cnt_error(), cache_center.c line 418: ---------------------+------------------------------------------------------ Reporter: kdajka | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: major Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [94fe1956a596430501a6fe4100d998007f3b4215]) If we cannot allocate an object in cnt_error() just close and go to cnt_done(), there is nothing we can do. For some inderterminate value of "fixes" this... Fixes #924 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 13:02:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 13:02:18 -0000 Subject: [Varnish] #922: Missing errorhandling code in cnt_error() In-Reply-To: <043.e7c41968f1ef5dd3fca0498aad837ff5@varnish-cache.org> References: <043.e7c41968f1ef5dd3fca0498aad837ff5@varnish-cache.org> Message-ID: <052.34ed37a9435edb07d572ea761ae780c6@varnish-cache.org> #922: Missing errorhandling code in cnt_error() ------------------------------+--------------------------------------------- Reporter: mkania | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: trunk | Severity: normal Resolution: duplicate | Keywords: ------------------------------+--------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Duplicate of #924 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 13:03:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 13:03:54 -0000 Subject: [Varnish] #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec In-Reply-To: <040.9e1623b96dbcd9a138f50f34a418c0ea@varnish-cache.org> References: <040.9e1623b96dbcd9a138f50f34a418c0ea@varnish-cache.org> Message-ID: <049.a9be0f201419d16c63fb95d519c95c35@varnish-cache.org> #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec ----------------------+----------------------------------------------------- Reporter: agd | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: Can you please provide me with a copy of your VCL ? If you do not want to attach it to the ticket, you can email it directly to me. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 19:28:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 19:28:37 -0000 Subject: [Varnish] #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes In-Reply-To: <042.bfce08d5f32e25c94a2694278228a89a@varnish-cache.org> References: <042.bfce08d5f32e25c94a2694278228a89a@varnish-cache.org> Message-ID: <051.eb3a355182820ce97a8413d4ad464d05@varnish-cache.org> #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes ------------------------------+--------------------------------------------- Reporter: jnlin | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: presistent cache | ------------------------------+--------------------------------------------- Description changed by phk: Old description: > Hello All, > > I have tried varnish recently but found it crashes every 10 minutes: > > tmp-1-117 [/big] -jnlin- varnishd -V > varnishd (varnish-3.0.0-beta1 revision varnish-3.0.0-beta1) > Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS > tmp-1-117 [/big] -jnlin- uname -a > FreeBSD tmp-1-117 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 > 02:41:51 UTC 2011 > root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > tmp-1-117 [/big] -jnlin- dmesg -a | less > -RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = > 0x280692a008 { fd = 17, id = 17, xid = 617873085, client = > 10.1.1.5 1799, step = STP_ERROR, handling = deliver, err_code = > 400, err_reason = (null), restarts = 0, esi_level = 0 ws = > 0x280692a080 { id = "sess", {s,f,r,e} = > {0x280692ace0,+2520,0x0,+65536}, }, http[req] = { ws = > 0x280692a080[sess] "GET", > "/f.pixnet.net/js/all.js?v=545d6dbf1980b02c6ff9e5ea863d979f", > "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 > (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 > Firefox/3.6.6", "Accept: */*", "Accept-Language: > zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", > "Accept-Charset: UTF-8,*", "Keep-Alive: 115", > "Connection: k > pid 95058 (varnishd), uid 65534: exited on signal 6 > May 13 02:04:14 tmp-1-117 /big[35707]: Child (95058) Panic message: > Assert error in smp_allocobj(), storage_persistent.c line 497: > Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident > = FreeBSD,8.2-RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp > = 0x28071dd008 { fd = 33, id = 33, xid = 637471130, client = > 10.1.1.5 49373, step = STP_ERROR, handling = deliver, err_code = > 400, err_reason = (null), restarts = 0, esi_level = 0 ws = > 0x28071dd080 { id = "sess", {s,f,r,e} = > {0x28071ddce0,+2536,0x0,+65536}, }, http[req] = { ws = > 0x28071dd080[sess] "GET", > "/panel/images/blog/common/pixmore/trans.gif", "HTTP/1.1", > "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; > Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", > "Accept: image/png,image/*;q=0.8,*/*;q=0.5", "Accept-Language: > zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", > "Accept-Charset: UTF-8,*", "Keep-Alive: 115", > pid 49696 (varnishd), uid 65534: exited on signal 6 > May 13 02:04:17 tmp-1-117 /big[35707]: Child (49696) Panic message: > Assert error in smp_allocobj(), storage_persistent.c line 497: > Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident > = FreeBSD,8.2-RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp > = 0x2807136008 { fd = 20, id = 20, xid = 89186144, client = > 10.1.1.6 44867, step = STP_ERROR, handling = deliver, err_code = > 400, err_reason = (null), restarts = 0, esi_level = 0 ws = > 0x2807136080 { id = "sess", {s,f,r,e} = > {0x2807136ce0,+2536,0x0,+65536}, }, http[req] = { ws = > 0x2807136080[sess] "GET", > "/common/toolbar/userinfo.css?v=545d6dbf1980b02c6ff9e5ea863d979f", > "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: > Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) > Gecko/20100625 Firefox/3.6.6", "Accept: text/css,*/*;q=0.1", > "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", > "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", > "Keep-Alive: 115", > pid 94341 (varnishd), uid 65534: exited on signal 6 > > [...sniped...] > > My varnish config is here: https://gist.github.com/970095 > > And my parameters of running varnish is: > tmp-1-117 [/big] -jnlin- sudo varnishd -a :3128 -T 127.0.0.1:6082 -f > /big/test.vcl -n /big -s persistent,/big/cache/varnish.cache,96G -w > 100,2000 -u nobody New description: Hello All, I have tried varnish recently but found it crashes every 10 minutes: {{{ tmp-1-117 [/big] -jnlin- varnishd -V varnishd (varnish-3.0.0-beta1 revision varnish-3.0.0-beta1) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS tmp-1-117 [/big] -jnlin- uname -a FreeBSD tmp-1-117 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 tmp-1-117 [/big] -jnlin- dmesg -a | less -RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x280692a008 { fd = 17, id = 17, xid = 617873085, client = 10.1.1.5 1799, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x280692a080 { id = "sess", {s,f,r,e} = {0x280692ace0,+2520,0x0,+65536}, }, http[req] = { ws = 0x280692a080[sess] "GET", "/f.pixnet.net/js/all.js?v=545d6dbf1980b02c6ff9e5ea863d979f", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: */*", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", "Connection: k pid 95058 (varnishd), uid 65534: exited on signal 6 May 13 02:04:14 tmp-1-117 /big[35707]: Child (95058) Panic message: Assert error in smp_allocobj(), storage_persistent.c line 497: Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident = FreeBSD,8.2 RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x28071dd008 { fd = 33, id = 33, xid = 637471130, client = 10.1.1.5 49373, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x28071dd080 { id = "sess", {s,f,r,e} = {0x28071ddce0,+2536,0x0,+65536}, }, http[req] = { ws = 0x28071dd080[sess] "GET", "/panel/images/blog/common/pixmore/trans.gif", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: image/png,image/*;q=0.8,*/*;q=0.5", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", pid 49696 (varnishd), uid 65534: exited on signal 6 May 13 02:04:17 tmp-1-117 /big[35707]: Child (49696) Panic message: Assert error in smp_allocobj(), storage_persistent.c line 497: Condition((sp->objcore) != 0) not true. thread = (cache-worker) ident = FreeBSD,8.2-RELEASE,amd64,-spersistent,-smalloc,-hcritbit,kqueue sp = 0x2807136008 { fd = 20, id = 20, xid = 89186144, client = 10.1.1.6 44867, step = STP_ERROR, handling = deliver, err_code = 400, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x2807136080 { id = "sess", {s,f,r,e} = {0x2807136ce0,+2536,0x0,+65536}, }, http[req] = { ws = 0x2807136080[sess] "GET", "/common/toolbar/userinfo.css?v=545d6dbf1980b02c6ff9e5ea863d979f", "HTTP/1.1", "Host: s.pixfs.net", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6", "Accept: text/css,*/*;q=0.1", "Accept-Language: zh-tw,en-us;q=0.7,en;q=0.3", "Accept-Encoding: gzip,deflate", "Accept-Charset: UTF-8,*", "Keep-Alive: 115", pid 94341 (varnishd), uid 65534: exited on signal 6 }}} [...sniped...] My varnish config is here: https://gist.github.com/970095 And my parameters of running varnish is: tmp-1-117 [/big] -jnlin- sudo varnishd -a :3128 -T 127.0.0.1:6082 -f /big/test.vcl -n /big -s persistent,/big/cache/varnish.cache,96G -w 100,2000 -u nobody -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 19:48:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 19:48:37 -0000 Subject: [Varnish] #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes In-Reply-To: <042.bfce08d5f32e25c94a2694278228a89a@varnish-cache.org> References: <042.bfce08d5f32e25c94a2694278228a89a@varnish-cache.org> Message-ID: <051.9d23be56307245d4af0a10cf82c1644e@varnish-cache.org> #915: Varnish 3.0 beta1 with persistent cache crashes every 10 minutes ---------------------+------------------------------------------------------ Reporter: jnlin | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: fixed | Keywords: presistent cache ---------------------+------------------------------------------------------ Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [cfad47881d155111cb38bb049a106d1865e099bd]) The persistent stevedore is not even able to allocate an object without and objcore, so return NULL if asked to. Add a fallback in cnt_error() to attempt the Transient storage if we hit this case. There already is a similar retry for the regular object allocation attempt. Fixes #915 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 27 20:22:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 May 2011 20:22:47 -0000 Subject: [Varnish] #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec In-Reply-To: <040.9e1623b96dbcd9a138f50f34a418c0ea@varnish-cache.org> References: <040.9e1623b96dbcd9a138f50f34a418c0ea@varnish-cache.org> Message-ID: <049.3e8c92f9f65dde583c87869bc2d5c932@varnish-cache.org> #921: 3.0.0b1r0fb00eb/linux-64 build; incompatible pointer type & wrong arg type warnings @ exec ----------------------+----------------------------------------------------- Reporter: agd | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [76fc17c1852e2a1cb29f4e49a32009a93bb45972]) Make sure that the arguments we pass regsub() came out as strings. Fixes #921 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 30 10:10:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 May 2011 10:10:51 -0000 Subject: [Varnish] #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 In-Reply-To: <043.ce557490a286e8322c8667a2cfa4e751@varnish-cache.org> References: <043.ce557490a286e8322c8667a2cfa4e751@varnish-cache.org> Message-ID: <052.102245b9e2721a091756c493efd7ca11@varnish-cache.org> #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 ------------------------+--------------------------------------------------- Reporter: kdajka | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 ------------------------+--------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 30 11:34:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 May 2011 11:34:32 -0000 Subject: [Varnish] #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 In-Reply-To: <043.ce557490a286e8322c8667a2cfa4e751@varnish-cache.org> References: <043.ce557490a286e8322c8667a2cfa4e751@varnish-cache.org> Message-ID: <052.9e357513771240c4124538521fc1acb2@varnish-cache.org> #923: Segmentation Fault in varnishlog bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 ------------------------------------------------------+--------------------- Reporter: kdajka | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: bbc2f9194c45c94b4c7348a3fd3b4f1bc9574398 | ------------------------------------------------------+--------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [84353810d7e8aff9de925066ce3392093001d0b9]) Don't emit Length records for piped requests We don't have a file descriptor for piped requests, so just don't emit a Length record. Fixes: #923 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 30 11:34:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 May 2011 11:34:35 -0000 Subject: [Varnish] #918: Segfault in varnishncsa (3.0.0-beta1) In-Reply-To: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> References: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> Message-ID: <050.823224ff2c87ce1cd36dc7faa9bbf859@varnish-cache.org> #918: Segfault in varnishncsa (3.0.0-beta1) -------------------------+-------------------------------------------------- Reporter: olli | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishncsa | Version: Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [ebf15ebd61974be719ce315f95caa8c835ea37d6]) Ignore piped requests in varnishncsa, since we probably miss some of their information Fixes: #918 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 30 18:17:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 May 2011 18:17:42 -0000 Subject: [Varnish] #926: VSS headers are not exported Message-ID: <045.357c4f956532d432cb70dbcfda62171e@varnish-cache.org> #926: VSS headers are not exported -----------------------------+---------------------------------------------- Reporter: weltling | Type: enhancement Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: packaging Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- VSS_* functionality is not availiable in the exported libvarnish api. As a consequence, it's impossible to use the libvarnish network features and build apps, connecting to a varnish instance through the sockets. The lack was showing up, as I was trying to implement a varnishadm alike app using the exported libvarnishapi. The functionality of the -T param is not possible without VSS_* functions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 07:33:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 07:33:22 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.a29806c98eda8cb38e40ebd1df33180d@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Keywords: varnishadm ------------------------+--------------------------------------------------- Changes (by martin): * status: assigned => new * owner: tfheen => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 08:33:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 08:33:58 -0000 Subject: [Varnish] #927: Assert error in stv_alloc(), stevedore.c in varnish_32e40a6ececf4a2ea65830e723c770d1ce261898 Message-ID: <043.c2db84effe9fcd8808d104eea97f97f5@varnish-cache.org> #927: Assert error in stv_alloc(), stevedore.c in varnish_32e40a6ececf4a2ea65830e723c770d1ce261898 --------------------+------------------------------------------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- Hi, I'm seeing "Assert error in stv_alloc(), stevedore.c line 194:" in newest trunk 32e40a6ececf4a2ea65830e723c770d1ce261898 My system: Linux varnishic06 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar.pl_varnishd.pid -a :8084 \ -i foo.bar_varnishic06 -n foo.bar_varnishic06 -f /exp/confvarnish/foo.bar.pl/foo.bar.pl.vcl \ -T :2084 -h classic,20011 -p thread_pools 4 -p ban_lurker_sleep 0.1 -w 200,4000,2 \ -t 0 -s malloc,1G }}} {{{ panic.show 200 Last panic at: Tue, 31 May 2011 04:44:02 GMT Assert error in stv_alloc(), stevedore.c line 194: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.26-2-amd64,x86_64,-smalloc,-smalloc,-hclassic,epoll Backtrace: 0x434e0d: pan_backtrace+16 0x435076: pan_ic+164 0x450ea0: stv_alloc+280 0x45182e: STV_alloc+1d 0x427c2c: FetchStorage+9a 0x4279cd: vfp_nop_bytes+27 0x428204: fetch_chunked+339 0x428fac: FetchBody+3e0 0x4199f1: cnt_fetchbody+9b9 0x41c32b: CNT_Session+5ae sp = 0x7fc61573f008 { fd = 145, id = 145, xid = 1059381681, client = 123.123.123.123 14836, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fc61573f080 { id = "sess", {s,f,r,e} = {0x7fc61573fcf0,+728,(nil),+65536}, }, http[req] = { ws = 0x7fc61573f080[sess] "GET", "/resource/5_wetlinska__003.jpg", "HTTP/1.1", "Accept: */*", "Referer: http://foo.bar.pl/html/1310721,262146,169,170.html?3,1", "Accept-Language: pl", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322)", "Host: foo.bar.pl", "Connection: Keep-Alive", "x-real-forwarded-for: 123.123.123.123", "X-Forwarded-For: 123.123.123.123", }, worker = 0x7fc6e4fefe10 { ws = 0x7fc6e4feffb0 { id = "wrk", {s,f,r,e} = {0x7fc6e4fddd20,+3040,(nil),+65536}, }, http[bereq] = { ws = 0x7fc6e4feffb0[wrk] "GET", "/resource/5_wetlinska__003.jpg", "HTTP/1.1", "Accept: */*", "Referer: http://foo.bar.pl/html/1310721,262146,169,170.html?3,1", "Accept-Language: pl", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322)", "Host: foo.bar.pl", "x-real-forwarded-for: 123.123.123.123", "X-Forwarded-For: 123.123.123.123", "X-Varnish: 1059381681", "Accept-Encoding: gzip", }, http[beresp] = { ws = 0x7fc6e4feffb0[wrk] "HTTP/1.1", "200", "OK", "Date: Tue, 31 May 2011 04:44:02 GMT", "Server: Apache", "Cache-Control: PUBLIC, max-age=0, must-revalidate", "Last-Modified: Mon, 09 May 2011 22:17:04 GMT", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Connection: close", "Transfer-Encoding: chunked", "Content-Type: image/jpeg", "x-url: /resource/5_wetlinska__003.jpg", "x-host: foo.bar.pl", }, }, vcl = { srcname = { "input", "Default", "/exp/confvarnish/foo.bar.pl/backends_foo.bar.pl.vcl", "/exp/confvarnish/global/500.vcl", }, }, obj = 0x7fc58c9f4800 { xid = 1059381681, ws = 0x7fc58c9f4818 { id = "obj", {s,f,r,e} = {0x7fc58c9f4a40,+328,(nil),+384}, }, http[obj] = { ws = 0x7fc58c9f4818[obj] "HTTP/1.1", "OK", "Date: Tue, 31 May 2011 04:44:02 GMT", "Server: Apache", "Cache-Control: PUBLIC, max-age=0, must-revalidate", "Last-Modified: Mon, 09 May 2011 22:17:04 GMT", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Content-Type: image/jpeg", "x-url: /resource/5_wetlinska__003.jpg", "x-host: foo.bar.pl", }, len = 131072, store = { 131072 { ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 |......JFIF.....H| 00 48 00 00 ff ed 00 a8 50 68 6f 74 6f 73 68 6f |.H......Photosho| 70 20 33 2e 30 00 38 42 49 4d 04 04 00 00 00 00 |p 3.0.8BIM......| 00 8c 1c 02 00 00 02 00 02 1c 02 74 00 80 20 20 |...........t.. | [131008 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 08:52:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 08:52:08 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.e23d9b2431fd931e5cc9482b52565417@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishadm | ------------------------+--------------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [50a77ab0a92abf1e686611a0a25d241a2ecd14c0]) Do proper non-blocking reads. Spotted: drwilco Fixes: #914 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 09:09:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 09:09:43 -0000 Subject: [Varnish] #914: varnishadm fails to read large responses from varnishd In-Reply-To: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> References: <044.c87e0974c7f15dd567d2a2ef18c7fa4c@varnish-cache.org> Message-ID: <053.6189387227ed39d6167862a5c0d82d20@varnish-cache.org> #914: varnishadm fails to read large responses from varnishd ------------------------+--------------------------------------------------- Reporter: drwilco | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishadm | ------------------------+--------------------------------------------------- Comment(by martin): I'm reluctant to put in that other patch you added here, as that extended timeout allows slow operations started on the command line to have extended time (e.g. compiling the VCL). The timeout in varnishadm is used for commands that are not expected to take long (e.g. receiving banner and doing the auth stuff), and also for the receiving of responses from varnish when in interactive mode, but only when we know from polling that there is a message available. So the timeout is a timeout for the network only, not for the actual running of the command by varnishd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 12:17:41 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 12:17:41 -0000 Subject: [Varnish] #926: VSS headers are not exported In-Reply-To: <045.357c4f956532d432cb70dbcfda62171e@varnish-cache.org> References: <045.357c4f956532d432cb70dbcfda62171e@varnish-cache.org> Message-ID: <054.1ca4a3ba8daa767104d0bebe086a47b7@varnish-cache.org> #926: VSS headers are not exported ------------------------------+--------------------------------------------- Reporter: weltling | Type: enhancement Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: packaging Version: trunk | Severity: normal Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Ok, that resulted in a rather huge amount of name-space cleanup. I belive libvarnishapi is now consistent and complete. The VSS functions are (still) not exported, you should use whatever functions your local environment have for opening a TCP connection. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 31 14:43:39 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 31 May 2011 14:43:39 -0000 Subject: [Varnish] #928: strace attached to child causes child to die Message-ID: <048.d8685bc72e2f98a74463b3c5eab42307@varnish-cache.org> #928: strace attached to child causes child to die ------------------------------+--------------------------------------------- Reporter: David Busby | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: strace,child,die | ------------------------------+--------------------------------------------- Attempted strace {{{ strace -p 8671 Process 8671 attached - interrupt to quit close(6) = 0 close(7) = 0 write(1, "Child dies", 10) = 10 write(1, "\n", 1) = 1 exit_group(1) = ? Process 8671 detached }}} Output to /var/log/messages {{{ May 31 14:37:29 109 live[8670]: Child (8671) said Child dies May 31 14:37:30 109 live[8670]: Child (8671) died May 31 14:37:30 109 live[8670]: child (9235) Started May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 live[8670]: Child (9235) said Child starts May 31 14:37:30 109 live[8670]: Child (9235) said Probe("GET /status.html HTTP/1.1 May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 live[8670]: Child (9235) said Host: 127.0.0.1 May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 live[8670]: Child (9235) said Connection: close May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 last message repeated 2 times May 31 14:37:30 109 live[8670]: Child (9235) said ", 0.05, 2) May 31 14:37:30 109 live[8670]: Child (9235) said Probe("GET /status.html HTTP/1.1 May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 live[8670]: Child (9235) said Host: 172.31.56.23 May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 live[8670]: Child (9235) said Connection: close May 31 14:37:30 109 live[8670]: Child (9235) said May 31 14:37:30 109 last message repeated 2 times May 31 14:37:30 109 live[8670]: Child (9235) said ", 0.05, 2) }}} This is hindering diagnostics of a "http first read error: -1 11 (Resource temporarily unavailable)" this "Child dies" seems to occur regardless of the VCL being run. Please let me know if more information is required. Regards D.Busby -- Ticket URL: Varnish The Varnish HTTP Accelerator