From varnish-bugs at projects.linpro.no Fri Jan 1 13:48:23 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 01 Jan 2010 13:48:23 -0000 Subject: [Varnish] #611: Websockets support Message-ID: <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> #611: Websockets support -------------------------+-------------------------------------------------- Reporter: wesnoth | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- It would be great if Varnish could support websockets from HTML5. This might require some changes, though I haven't tested it. There is support for websockets in Google chrome, other browsers will get support soon. More information about websockets can be found here: http://dev.w3.org/html5/websockets/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From phk at phk.freebsd.dk Fri Jan 1 20:23:31 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 01 Jan 2010 20:23:31 +0000 Subject: [Varnish] #611: Websockets support In-Reply-To: Your message of "Fri, 01 Jan 2010 13:48:23 GMT." <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> Message-ID: <64504.1262377411@critter.freebsd.dk> In message <053.714c9943e160c430d748fe95d32b2341 at projects.linpro.no>, "Varnish" writes: > It would be great if Varnish could support websockets from HTML5. What would Varnish do, differently from the "pipe" it can already do, for such a websocket ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish-bugs at projects.linpro.no Mon Jan 4 10:37:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 10:37:24 -0000 Subject: [Varnish] #608: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "& " evaluation in URLs In-Reply-To: <049.34aecf43a7f89853387dac29c9b47292@projects.linpro.no> References: <049.34aecf43a7f89853387dac29c9b47292@projects.linpro.no> Message-ID: <058.2d625c5f5774e6e510a8db73125ed7fb@projects.linpro.no> #608: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "&" evaluation in URLs --------------------+------------------------------------------------------- Reporter: niz | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: duplicate Keywords: esi | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: Closing as duplicate of 607. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 10:56:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 10:56:59 -0000 Subject: [Varnish] #606: Varnish 2.0.6 -- fix for ESI src= parsing error -- causes a "bogus" character in the URL and a potential memory clobber In-Reply-To: <049.070c9154bde6d4b5a3ec933268fa40fe@projects.linpro.no> References: <049.070c9154bde6d4b5a3ec933268fa40fe@projects.linpro.no> Message-ID: <058.bf29a1ac7748a2be99f4bee38e55b1d3@projects.linpro.no> #606: Varnish 2.0.6 -- fix for ESI src= parsing error -- causes a "bogus" character in the URL and a potential memory clobber --------------------+------------------------------------------------------- Reporter: niz | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: You are looking at 2.0.5, not 2.0.6. The relevant code from 2.0.6 reads: {{{ if ( val.b != val.e ) { s = Tlen(val) + 1; c = WS_Alloc(ws, s); memcpy(c, val.b, Tlen(val)); val.b = c; val.e = val.b + s; val.e[-1] = '\0'; } }}} (This fix was the primary reason for 2.0.6 being needed) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 11:39:15 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 11:39:15 -0000 Subject: [Varnish] #611: Websockets support In-Reply-To: <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> References: <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> Message-ID: <062.f352758777f0c814b7ca2fbd528a4085@projects.linpro.no> #611: Websockets support -------------------------+-------------------------------------------------- Reporter: wesnoth | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by phk): What would varnish do with these connections ? As far as I can see, "pipe" is all we can do, and that is already possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 11:52:13 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 11:52:13 -0000 Subject: [Varnish] #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "& " evaluation in URLs In-Reply-To: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> References: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> Message-ID: <058.77fcd155ae0a93101e902dd732ea8dfb@projects.linpro.no> #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "&" evaluation in URLs ----------------------+----------------------------------------------------- Reporter: niz | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: esi | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 12:50:54 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 12:50:54 -0000 Subject: [Varnish] #586: Debian source files instalation In-Reply-To: <052.f49e8f689d60029221cb2cbaa3d68f87@projects.linpro.no> References: <052.f49e8f689d60029221cb2cbaa3d68f87@projects.linpro.no> Message-ID: <061.ac9f14339077e8c235190c9b4e6dad2f@projects.linpro.no> #586: Debian source files instalation ---------------------------+------------------------------------------------ Reporter: werdan | Owner: Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4420]) Document need for ldconfig on Linux On Linux, ldconfig needs to be run after installing shared libraries to system paths (typically /usr/local/lib, /usr/lib and /lib). Document this. Fixes #586 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 14:59:29 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 14:59:29 -0000 Subject: [Varnish] #581: struct acct stats counted improperly in 2.0.5 In-Reply-To: <049.1d1d34d794e869189da7c82cf71e6068@projects.linpro.no> References: <049.1d1d34d794e869189da7c82cf71e6068@projects.linpro.no> Message-ID: <058.c002ff70df8dd7a3e06fc9faf500007c@projects.linpro.no> #581: struct acct stats counted improperly in 2.0.5 ------------------------+--------------------------------------------------- Reporter: tgr | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: acct stats | ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This was fixed in r4398. {{{ commit 3cb38c0343428f0352a1e519cc8e733a69d054b2 Author: tfheen Date: Wed Dec 16 08:50:49 2009 +0000 Merge small part of r4215: Charge sessions when herding In 2.0.5 we default to lingering for a bit which can cause sessions to not be charged for a long time. This fixes it. git-svn-id: svn+ssh://projects.linpro.no/svn/varnish/branches/2.0 at 4398 d4fa192b-c00b-0410-8231-f00ffab90ce4 diff --git a/varnish-cache/bin/varnishd/cache_center.c b/varnish- cache/bin/varnishd/cache_center.c index ef54b32..87e1566 100644 --- a/varnish-cache/bin/varnishd/cache_center.c +++ b/varnish-cache/bin/varnishd/cache_center.c @@ -105,6 +105,7 @@ cnt_wait(struct sess *sp) if (i == 0) { WSL(sp->wrk, SLT_Debug, sp->fd, "herding"); VSL_stats->sess_herd++; + SES_Charge(sp); sp->wrk = NULL; vca_return_session(sp); return (1); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 4 21:36:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 Jan 2010 21:36:01 -0000 Subject: [Varnish] #602: server.hostname and server.identity are not documented in vcl(7) In-Reply-To: <051.2c451a342587525e715b0d0ec03b0b1f@projects.linpro.no> References: <051.2c451a342587525e715b0d0ec03b0b1f@projects.linpro.no> Message-ID: <060.0fd61d837425d8e57eebe2d96b1eaf36@projects.linpro.no> #602: server.hostname and server.identity are not documented in vcl(7) ---------------------------+------------------------------------------------ Reporter: fgsch | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4421]) Document server.identity and server.hostname (and -i to varnishd) Fixes #602 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 5 08:05:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 05 Jan 2010 08:05:04 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> References: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> Message-ID: <060.cc67b58788b7d8ea79b1dc5364c360c4@projects.linpro.no> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I belive this problem is already solved in trunk, as part of the change to eliminate storing the unhashed hash input string. For 2.x I think a better way to solve it, is to make the first codeblock in cache_center.c:cnt_lookup() conditional on sp->objhead == NULL. In fact, I don't think the "if (sp->obj == NULL)" makes any sense now that I look at it, it was probably a mistake for that to not have been changed to "if (sp->objhead == NULL)" at some point in the past. Can I get you to test that change, and see if it solves the problem ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 5 08:10:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 05 Jan 2010 08:10:04 -0000 Subject: [Varnish] #605: Unix socket support In-Reply-To: <051.8e447d3e209fa5e928bb8ae0061b16e6@projects.linpro.no> References: <051.8e447d3e209fa5e928bb8ae0061b16e6@projects.linpro.no> Message-ID: <060.a512b4873b38b69a248e62c926727a7e@projects.linpro.no> #605: Unix socket support -------------------------+-------------------------------------------------- Reporter: ash2k | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This is a feature request, I have moved it to our PostTwoShoppingList -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 6 15:29:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 06 Jan 2010 15:29:38 -0000 Subject: [Varnish] #612: ESI includes are broken in -trunk Message-ID: <049.e4801658da7cd2cacf6ac661a5084e25@projects.linpro.no> #612: ESI includes are broken in -trunk ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- workspace for url gets overwritten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 6 15:53:58 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 06 Jan 2010 15:53:58 -0000 Subject: [Varnish] #612: ESI includes are broken in -trunk In-Reply-To: <049.e4801658da7cd2cacf6ac661a5084e25@projects.linpro.no> References: <049.e4801658da7cd2cacf6ac661a5084e25@projects.linpro.no> Message-ID: <058.08e5b82b0c90829454e456a63b0be107@projects.linpro.no> #612: ESI includes are broken in -trunk ----------------------+----------------------------------------------------- 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 r4423 and r4424 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 6 17:12:40 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 06 Jan 2010 17:12:40 -0000 Subject: [Varnish] #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "& " evaluation in URLs In-Reply-To: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> References: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> Message-ID: <058.5e0b0461b7c6c03b2c06f12eac8de3f6@projects.linpro.no> #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "&" evaluation in URLs ----------------------+----------------------------------------------------- Reporter: niz | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: esi | ----------------------+----------------------------------------------------- Comment (by phk): I have added the entity references in r4426 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 6 17:38:54 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 06 Jan 2010 17:38:54 -0000 Subject: [Varnish] #609: use more efficient implementation for TIM_mono on Solaris (if gethrtime() exists) In-Reply-To: <051.337d8b55936583877f6dd99d9c0e7293@projects.linpro.no> References: <051.337d8b55936583877f6dd99d9c0e7293@projects.linpro.no> Message-ID: <060.0054125111c2ac32335d5b77f6cae5bf@projects.linpro.no> #609: use more efficient implementation for TIM_mono on Solaris (if gethrtime() exists) -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4427]) Use gethrtimer rather than clock_gettime if available gethrtimer does not use a syscall on Solaris and is therefore faster. Prefer gethrtimer if it exists Fixes #609 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 6 22:36:44 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 06 Jan 2010 22:36:44 -0000 Subject: [Varnish] #613: Efficiency figure for varnishstat Message-ID: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> #613: Efficiency figure for varnishstat -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- In some deployment scenarios, the (cache) hit ratio of varnishstat suggests that the cache was providing great benefit and really the cache itself probably is, but still (too) many requests hit the backend in the form of passes or even piped sessions. I am suggesting to add an efficiency measure to varnishstat, defined as the ratio of client requests minus backend requests by client requests. efficiency = client requests - passes - pipes - fetches / client requests While one could argue that cache hits by client requests would do as well, at least as of now I believe that this measure is more accurate because it also takes into account that one client request may trigger multiple backend requests. With the attached patch, varnishstat will look something like this {{{ 2+12:13:01 HOSTNAME Hitrate ratio: 10 100 1000 Hitrate avg: 0.9721 0.9721 0.9731 Efficiency ratio: 10 100 1000 Efficiency avg: 0.9505 0.9522 0.9533 55697963 200.97 256.93 Client connections accepted 402992210 1518.81 1858.98 Client requests received 390022582 1471.82 1799.15 Cache hits 1549 0.00 0.01 Cache hits for pass 9053637 22.00 41.76 Cache misses }}} Two notes on the patch * I've chosen to implement a macro rather than a function, but I'll be happy to make this a function if core team members prefer * One might want to exclude the additional "ratio" line because users may find it redundant. And in fact it's probably not very likely that the two sets of numbers will ever differ. At any rate, I think state for the number of samples should be kept even if it's not printed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 7 11:29:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 07 Jan 2010 11:29:57 -0000 Subject: [Varnish] #207: Varnishlog core dumps In-Reply-To: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> References: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> Message-ID: <061.ffac8ceb7257078e8b56a73d8def8cb9@projects.linpro.no> #207: Varnishlog core dumps -----------------------------------+---------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: varnish log core dump | -----------------------------------+---------------------------------------- Comment (by phk): (In [4434]) Correctly check the XML 1.0 names for illegal characters. Fixes #207 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 7 11:32:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 07 Jan 2010 11:32:03 -0000 Subject: [Varnish] #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "& " evaluation in URLs In-Reply-To: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> References: <049.16465d721c8397862566be8a6d9abbc1@projects.linpro.no> Message-ID: <058.8b3eb2c4c00621e65b0c47201dc9b625@projects.linpro.no> #607: Varnish 2.0.6 -- fixes for ESI tag parsing when xmlns:esi attribute present; plus issues with "&" evaluation in URLs ----------------------+----------------------------------------------------- Reporter: niz | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: esi | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: And the check for legal characters is fixed in r4434 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 08:40:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 08:40:05 -0000 Subject: [Varnish] #225: VCL: Allow "Expires" time to be easily specified / calculated In-Reply-To: <055.0cde52996ac6ba2ef45b86c02b1cf8be@projects.linpro.no> References: <055.0cde52996ac6ba2ef45b86c02b1cf8be@projects.linpro.no> Message-ID: <064.825be2a40a3f5b67f141e195cd4071e9@projects.linpro.no> #225: VCL: Allow "Expires" time to be easily specified / calculated -------------------------+-------------------------------------------------- Reporter: cyberduck | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: It should now be possible to do: {{{ set resp.http.expires = obj.ttl; }}} This was fixed in r4428. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 08:41:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 08:41:06 -0000 Subject: [Varnish] #100: Setting the TTL does not adjust Expires: header In-Reply-To: <049.f779265ea82196cf4acaa40d47ee6ca5@projects.linpro.no> References: <049.f779265ea82196cf4acaa40d47ee6ca5@projects.linpro.no> Message-ID: <058.a19a48661deb3a6f2b1d0dd5ff64d0b3@projects.linpro.no> #100: Setting the TTL does not adjust Expires: header ----------------------+----------------------------------------------------- Reporter: des | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: You can now change it in VCL by just setting the Expires header to the value of ttl, like set resp.http.expires = obj.ttl Fixed in r4428. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 08:42:47 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 08:42:47 -0000 Subject: [Varnish] #388: make gives errors when xsltproc is not installed In-Reply-To: <054.ee8df78fba05cd4856a6b9bb05182d1c@projects.linpro.no> References: <054.ee8df78fba05cd4856a6b9bb05182d1c@projects.linpro.no> Message-ID: <063.043aef19ab39de038450be5884773904@projects.linpro.no> #388: make gives errors when xsltproc is not installed ----------------------+----------------------------------------------------- Reporter: mtempels | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r4330: {{{ commit 489a2188f75c80f777ce19bc12f9b43d263cae13 Author: tfheen Date: Tue Oct 13 15:26:18 2009 +0000 Skip building documentation when we lack xsltproc Previously, trying to build from SVN without xsltproc installed would get you errors like: --xinclude -o changes-2.0.1.html changes-2.0.1.xml --xinclude:No such file or directory which is quite confusing. We now rather just skip the docs completely if we can't find any xsltproc. If we actually do need to rebuild the docs (which should only happen when running make dist), we error out with a useful error message. git-svn-id: svn+ssh://projects.linpro.no/svn/varnish/trunk at 4330 d4fa192b-c00b-0410-8231-f00ffab90ce4 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 09:36:18 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 09:36:18 -0000 Subject: [Varnish] #334: GLIBC asprintf() incompatibility In-Reply-To: <049.eb670f007963f38db8298ad614a26f5c@projects.linpro.no> References: <049.eb670f007963f38db8298ad614a26f5c@projects.linpro.no> Message-ID: <058.838b7dfd36e9dabf4cfc3d559ab55745@projects.linpro.no> #334: GLIBC asprintf() incompatibility ---------------------+------------------------------------------------------ Reporter: phk | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: After Varnish 2.1 Component: build | Version: trunk Severity: trivial | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4436]) asprintf cleanup glibc and FreeBSD libc differ in how they handle asprintf allocation failures. Make sure we handle both cases properly and clean up the includes a bit. Fixes #334 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 10:06:54 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 10:06:54 -0000 Subject: [Varnish] #611: Websockets support In-Reply-To: <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> References: <053.714c9943e160c430d748fe95d32b2341@projects.linpro.no> Message-ID: <062.48d5f1a17cc74047e78e68b86dc966bd@projects.linpro.no> #611: Websockets support -------------------------+-------------------------------------------------- Reporter: wesnoth | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Feature request, moved to PostTwoShoppingList -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 8 10:17:33 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 Jan 2010 10:17:33 -0000 Subject: [Varnish] #604: n_vbe_conn corrupted In-Reply-To: <051.43ce56a29404685d4382fdd7e6e174e7@projects.linpro.no> References: <051.43ce56a29404685d4382fdd7e6e174e7@projects.linpro.no> Message-ID: <060.52624202eb096d3965f126d0dca20c45@projects.linpro.no> #604: n_vbe_conn corrupted --------------------+------------------------------------------------------- Reporter: fpapa | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4437]) Break down and lock the n_vbe_conn counter to avoid over & underflows. Fixes #604 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 10 22:06:45 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 10 Jan 2010 22:06:45 -0000 Subject: [Varnish] #614: thread_pool_add_delay not in varnishd(1) Message-ID: <051.5c9221b59b616dab3bf84da737d52879@projects.linpro.no> #614: thread_pool_add_delay not in varnishd(1) -------------------+-------------------------------------------------------- Reporter: domas | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- documentation about thread_pool_add_delay (and whatever can be there else) is missing in varnishd(1) list of run-time parameters in 2.0.6 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 06:49:56 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 06:49:56 -0000 Subject: [Varnish] #614: thread_pool_add_delay not in varnishd(1) In-Reply-To: <051.5c9221b59b616dab3bf84da737d52879@projects.linpro.no> References: <051.5c9221b59b616dab3bf84da737d52879@projects.linpro.no> Message-ID: <060.05cb49ab3295ae94a102672733d2eb36@projects.linpro.no> #614: thread_pool_add_delay not in varnishd(1) ---------------------------+------------------------------------------------ Reporter: domas | Owner: Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by ssm): I've committed some changes to the documentation in r4444 that should fix this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 09:57:13 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 09:57:13 -0000 Subject: [Varnish] #614: thread_pool_add_delay not in varnishd(1) In-Reply-To: <051.5c9221b59b616dab3bf84da737d52879@projects.linpro.no> References: <051.5c9221b59b616dab3bf84da737d52879@projects.linpro.no> Message-ID: <060.98adcf0c6834de542014b2298fde6acd@projects.linpro.no> #614: thread_pool_add_delay not in varnishd(1) ---------------------------+------------------------------------------------ Reporter: domas | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by ssm): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 11:31:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 11:31:01 -0000 Subject: [Varnish] #590: Assert error in ESI_Parse(), cache_esi.c line 822: Condition(st->len < st->space) not true. In-Reply-To: <050.18b8c0fcb73b96bb78d3b132f35e6485@projects.linpro.no> References: <050.18b8c0fcb73b96bb78d3b132f35e6485@projects.linpro.no> Message-ID: <059.28f982ecd9de2f20352c91a9b2e9d10d@projects.linpro.no> #590: Assert error in ESI_Parse(), cache_esi.c line 822: Condition(st->len < st->space) not true. ------------------------------+--------------------------------------------- Reporter: kali | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: esi parser crash | ------------------------------+--------------------------------------------- Comment (by phk): Can you please mail me (phk at phk.freebsd.dk) the file that crashes this every time ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 11:48:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 11:48:39 -0000 Subject: [Varnish] #294: Missing variables In-Reply-To: <048.969f63a67f29a55a7ae1f06e107a7ef1@projects.linpro.no> References: <048.969f63a67f29a55a7ae1f06e107a7ef1@projects.linpro.no> Message-ID: <057.c6676e5df2b387dd7eb746d4d7f17c36@projects.linpro.no> #294: Missing variables --------------------+------------------------------------------------------- Reporter: ay | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This was fixed in r4428 where we can now represent times as a string. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 11:50:20 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 11:50:20 -0000 Subject: [Varnish] #413: Incorect handling of escape in esi:include src attribute In-Reply-To: <057.f4223b8d94bfb88f09d673e93f736e06@projects.linpro.no> References: <057.f4223b8d94bfb88f09d673e93f736e06@projects.linpro.no> Message-ID: <066.d0f277aa9364ab42c88f6a54953b13da@projects.linpro.no> #413: Incorect handling of escape in esi:include src attribute -------------------------+-------------------------------------------------- Reporter: andrewmcnnz | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: esi escape | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This is now fixed in r4426. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 12:04:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 12:04:37 -0000 Subject: [Varnish] #520: check_varnish parameters truncated to signed int In-Reply-To: <048.662d5ec30a8056ba3f757638023873bd@projects.linpro.no> References: <048.662d5ec30a8056ba3f757638023873bd@projects.linpro.no> Message-ID: <057.97e2e082c19010d6145dbee86b96a628@projects.linpro.no> #520: check_varnish parameters truncated to signed int --------------------+------------------------------------------------------- Reporter: kb | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: nagios | Version: 2.0 Severity: major | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: It seems like you have been trying using the nagios plugin on sourceforge, rather than the one in the repositories? We haven't done a release for ages, something we should probably do something about. I'm closing this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 12:54:10 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 12:54:10 -0000 Subject: [Varnish] #579: check_varnish fails to compile in 2.0.5 In-Reply-To: <048.fc77c855f804212f8e17a8ff29ea4015@projects.linpro.no> References: <048.fc77c855f804212f8e17a8ff29ea4015@projects.linpro.no> Message-ID: <057.e6459d835abe88b9bba346c426f2deaa@projects.linpro.no> #579: check_varnish fails to compile in 2.0.5 --------------------+------------------------------------------------------- Reporter: kb | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: nagios | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: MAC_STAT in 2.0 only requires four arguments, not five, and to me it certainly looks like check_varnish in the 2.0 branch and in trunk are in sync with their respective branches, but you can't mix them. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 11 19:40:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 Jan 2010 19:40:32 -0000 Subject: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 Message-ID: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 ----------------------+----------------------------------------------------- Reporter: jhayter | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am testing Varnish 2.0.6 on Solaris 10. I setup Varnish using the suggestions at http://letsgetdugg.com/2009/12/04/varnish-on-solaris/. I have attached my command line to start varnish. Every few (3-6) minutes, the child process dies and is restarted. Varnishd output[[BR]] ---------------[[BR]] ...[[BR]] Child (21784) said ", 1, 3)[[BR]] Child (21784) not responding to ping, killing it.[[BR]] Child (21784) not responding to ping, killing it.[[BR]] Child (21784) not responding to ping, killing it.[[BR]] Child (21784) died signal=6 (core dumped)[[BR]] Child (21784) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 148: Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) == 0) not true. errno = 9 (Bad file number) thread = (cache-worker) sp = 8f29974 { fd = 84, id = 84, xid = 0, client = 66.68.180.213:2086, step = STP_FIRST, handling = error, restarts = 0, esis = 0 ws = 8f299c0 { id = "sess", {s,f,r,e} = {8f2a470,+19,0,+32768}, }, http[req] = { ws = 0[] }, worker = 731cdee0 }, [[BR]] Child cleanup complete[[BR]] child (21816) Started[[BR]] Child (21816) said Closed fds: 4 5 25 26 28 29[[BR]] ...[[BR]] ---- This error looked similar to ticket #547. I tried a quick fix similar to the fix done for that ticket.[[BR]] # diff cache_acceptor.c.2.0.6 cache_acceptor.c[[BR]] 127a128[[BR]] > int i; 146,148c147,151[[BR]] {{{ < if (need_linger) < AZ(setsockopt(sp->fd, SOL_SOCKET, SO_LINGER, < &linger, sizeof linger)); }}} ---[[BR]] {{{ > if (need_linger) { > i = setsockopt(sp->fd, SOL_SOCKET, SO_LINGER, > &linger, sizeof linger); > assert(i == 0 || errno == EBADF); > if (i != 0) return; > } }}} #[[BR]] Unfortunately, it must be more complex than I thought. With the change above in place, varnish still stops running every few minutes. But now both the manager and child processes die. [[BR]] The varnish output is:[[BR]] NB: Storage size limited to 2GB on 32 bit architecture,[[BR]] NB: otherwise we could run out of address space.[[BR]] storage_file: filename: /usr/local/varnish/var/varnish.cache size 2047 MB.[[BR]] Using old SHMFILE[[BR]] bind(): Cannot assign requested address[[BR]] child (26778) Started[[BR]] Child (26778) said Closed fds: 4 5 25 26 28 29[[BR]] Child (26778) said Child starts[[BR]] Child (26778) said managed to mmap 2147475456 bytes of 2147475456[[BR]] Child (26778) said Ready[[BR]] Child (26778) said Probe("HEAD /favicon.ico HTTP/1.1[[BR]] Child (26778) said[[BR]] Child (26778) said Host: www.manta.com[[BR]] Child (26778) said[[BR]] Child (26778) said User-Agent: varnish health probe[[BR]] Child (26778) said[[BR]] Child (26778) said Connection: close[[BR]] Child (26778) said[[BR]] Child (26778) said[[BR]] Child (26778) said[[BR]] Child (26778) said ", 1, 3)[[BR]] Manager got SIGINT[[BR]] Stopping Child[[BR]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 12 10:20:07 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 12 Jan 2010 10:20:07 -0000 Subject: [Varnish] #616: Persistent crash (sig11) in trunk 4434 Message-ID: <052.bea17b1d59c11964d1c0bfd2a72fd360@projects.linpro.no> #616: Persistent crash (sig11) in trunk 4434 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Running Varnish trunk 4434 w/persistent on FreeBSD/amd64 7.2-RELEASE, after a while I get: Jan 11 19:51:57 cache12 varnishd[52496]: Child (94670) died signal=11 (core dumped) Backtrace: {{{ (gdb) bt #0 0x00000008009cf35f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 #1 0x00000008009cf394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 #2 0x0000000000421ac8 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000421e77 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:329 #4 0x000000000041aad0 in hsh_rush (oh=0x174e5357f0) at cache_hash.c:459 #5 0x000000000041aef5 in HSH_Unbusy (sp=Variable "sp" is not available. ) at cache_hash.c:512 #6 0x0000000000412fb6 in cnt_fetch (sp=0x17319c0008) at cache_center.c:641 #7 0x0000000000413f2a in CNT_Session (sp=0x17319c0008) at steps.h:41 #8 0x0000000000423d01 in wrk_do_cnt_sess (w=0x7fffd7abd800, priv=Variable "priv" is not available. ) at cache_pool.c:277 #9 0x000000000042300d in wrk_thread_real (qp=0x80110f6a0, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:173 #10 0x0000000800bf04d1 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffd7abf000 (gdb) frame 4 #4 0x000000000041aad0 in hsh_rush (oh=0x174e5357f0) at cache_hash.c:459 459 CHECK_OBJ_NOTNULL(sp, SESS_MAGIC); (gdb) print *sp $1 = {magic = 1294996226, fd = 0, id = 1773809856, xid = 17, restarts = 1314095232, esis = 23, disable_esi = -1276544418, wrk = 0x24bd0900000019, sockaddrlen = 0, mysockaddrlen = 0, sockaddr = 0x174e538098, mysockaddr = 0x174e5381d0, mylsock = 0x174e536ee8, addr = 0x174e6055f0 "\002\0230M", port = 0x174e535838 "\220oSN\027", doclose = 0x170dda56c0 "\225\030?E", http = 0x801125160, http0 = 0x0, ws = {{ magic = 5682088, id = 0x1
, s = 0x0, f = 0x0, r = 0x0, e = 0x0, overflow = 0}}, ws_ses = 0x0, ws_req = 0x7b86c8a5
, digest = "?DSN\027", '\0' , "?+\020\001\b\000\000\000\000??N\027\000\000", htc = {{magic = 1312807648, fd = 23, ws = 0x4420c9, rxbuf = { b = 0x0, e = 0x7b86c8a5
}, pipeline = {b = 0x174e534510 "", e = 0x0}}}, t_open = 4.904156330378895e-313, t_req = 4.9504296017825474e-313, t_resp = 4.9224499275078666e-313, t_end = 2.2059245522434771e-317, connect_timeout = 0, first_byte_timeout = 1.0239168404184685e-314, between_bytes_timeout = 4.9455145023518631e-313, grace = 0, step = 17836960, cur_method = 8, handling = 1314091264, sendbody = 23 '\027', wantbody = 0 '\0', err_code = 1312807776, err_reason = 0x4420c9 "&oh->mtx", list = {vtqe_next = 0x0, vtqe_prev = 0x7b86c8a5}, director = 0x174e5345b0, vbe = 0x0, obj = 0x801102ba0, objcore = 0x174e537140, objhead = 0x174e5370e0, vcl = 0x4420c9, mem = 0x0, workreq = {list = { vtqe_next = 0x7b86c8a5, vtqe_prev = 0x174e534600}, func = 0, priv = 0x801102ba0}, acct = {first = 4.9455150604484166e-313, sess = 100098339104, req = 4464841, pipe = 0, pass = 2072430757, fetch = 100098328144, hdrbytes = 0, bodybytes = 34377575328}, acct_req = { first = 4.9454516429726214e-313, sess = 100098339168, req = 4464841, pipe = 0, pass = 2072430757, fetch = 100098328224, hdrbytes = 0, bodybytes = 34377575328}} }}} ESI is not in use. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 12 21:10:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 12 Jan 2010 21:10:24 -0000 Subject: [Varnish] #540: X-Forwarded-For created and not appended. In-Reply-To: <055.5449af7e5b7e33441d8b0f9e65fb0fac@projects.linpro.no> References: <055.5449af7e5b7e33441d8b0f9e65fb0fac@projects.linpro.no> Message-ID: <064.d7a3cbcc14001b5e060c45aa717fd446@projects.linpro.no> #540: X-Forwarded-For created and not appended. -----------------------+---------------------------------------------------- Reporter: bmfurtado | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by David Strauss): I've posted a workaround here for users of Pressflow: https://wiki.fourkitchens.com/display/PF/Workaround+for+Varnish+X -Forwarded-For+bug -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 12 22:53:26 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 12 Jan 2010 22:53:26 -0000 Subject: [Varnish] #617: Odd output in varnishncsa Message-ID: <052.9397a7c1997da9c6a9784c50147564e6@projects.linpro.no> #617: Odd output in varnishncsa --------------------+------------------------------------------------------- Reporter: jelder | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- Some requests are presented with all fields as null (including 0 epoch seconds). This is often (always?) associated with a backend request. Backend requests are logged with the wrong timezone. I don't know if this is necessarily related but I noticed them at the same time. This is Varnish 2.0.6. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 13 08:17:29 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 Jan 2010 08:17:29 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> References: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> Message-ID: <060.9b27d25c3b412b3fa868cef653a568db@projects.linpro.no> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Hi Paul, thanks for looking into this. Maybe I should clarify that this bug is really about two different issues 1. HSH_rush being called too often (when the obj being waited for is not necessarily ready) 2. Exhaustion of the session workspace when cnt_lookup->HSH_Prepare is beging called to often. 2) is a consequence of 1). But I agree that changing if (sp->obj == NULL) into if (sp->objhead == NULL) at the top of cnt_lookup would also make sense: The only way sp->objhead ever gets set is when we wait for a busy object, and IIUC waiting for a busy object is the only case when we reenter cnt_lookup. (We probably could also check for sp->hashptr as that is being set in HSH_Prepare) I will test this suggestion, but this will probably take some more time. Having said that, I still think that my suggested change (which targets issue 1) is an important fix/improvement even if it did not have the consequence of workspace exhaustion: * Waking up waiting sessions unnecessarily may lead to extremely high peak load In particular, HSH_Drop calls HSH_Deref (which would rush), so whenever we decide or are being forced to give up in cnt_fetch, we rush all the other waiters (which will end up waiting again). On the production system I am working on, we've seen cases where, with a slow backend, the load on varnish servers would suddenly raise to the thousands and this scenario would explain the effect. * I would like to have better control over restarts Another change which I've made for production use (and which I still need to document) is to increment sp->restarts in hsh_rush, following the idea that a session which has waited for a busy object has effectively been (internally) restarted. At any rate, it has waited (probably quite a while) for the busy object, so we might want to chose different parameters for the second fetch (like increasing the grace time). In order to get an exact figure for the restarts (with this new semantics), I need to make sure that hsh_rush is only called when a busy object becomes available. Maybe it is of interest that my suggested changes are running in production without any issues since january 4th. To conclude, I think changing the test in cnt_lookup makes sense, but I also think we still need the changes which I suggested. I must say that I still haven't looked at the trunk because, at this point, I need to focus on improving the stability of production versions. Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 13 14:11:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 Jan 2010 14:11:03 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> References: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> Message-ID: <060.b158f0b3b3930e4666c66c4558187c58@projects.linpro.no> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I agree in most of your observations, but I prefer to deal with bugs and improvements as separate things, so lets find out if the s/obj/objhdr/ fixes the bug, the rush policy is less critical. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 13 14:12:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 Jan 2010 14:12:39 -0000 Subject: [Varnish] #576: Feature request: make check; better timing or more stable tests In-Reply-To: <052.ea532920bf3dd49821b6ebf7a71a7573@projects.linpro.no> References: <052.ea532920bf3dd49821b6ebf7a71a7573@projects.linpro.no> Message-ID: <061.12fe0dae8034b9d5697444dfe4f45e49@projects.linpro.no> #576: Feature request: make check; better timing or more stable tests -------------------------+-------------------------------------------------- Reporter: ingvar | Owner: kristian Type: enhancement | Status: closed Priority: low | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: I have changed varnishtest to no longer rely on fixed TCP port numbers. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 13 17:28:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 Jan 2010 17:28:19 -0000 Subject: [Varnish] #618: obj.cacheable should consider no-cache in addition to s-maxage Message-ID: <052.3415b974e62135ca20f54d99d4f67ac2@projects.linpro.no> #618: obj.cacheable should consider no-cache in addition to s-maxage ----------------------+----------------------------------------------------- Reporter: jelder | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- You currently need to check for no-cache in a custom vcl or have the backend send s-maxage=0. It would be reasonable to consider no-cache in the default vcl. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 13 17:44:55 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 Jan 2010 17:44:55 -0000 Subject: [Varnish] #619: Varnish stalled connections Message-ID: <053.e844cef13dc2e3cce139a62d8f8ddc3e@projects.linpro.no> #619: Varnish stalled connections ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ specs: opensolaris / poll event handler (eventports is broken on opensolaris). Issue: Connections seem to stall out on builds r4445 and up. Last known trunk build that worked well was r4443. I think the changes done in r4445 have had a negative impact on functionality. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 14 02:39:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 Jan 2010 02:39:57 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" Message-ID: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Type: defect Status: new | Priority: highest Milestone: | Component: website Version: 2.0 | Severity: critical Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Something happened with the varnish instance and it went down with the following error message, but it seems from the error message that it started back again. It was failing to proxy to Apache and resulting on a 404 till it was restarted. unfortunately no coredumps. I am running varnishd (varnish-2.0.4). compiled. uname -a 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux CentOS release 5.3 (Final) Jan 11 03:50:17 web2 varnishd[8785]: Child (8786) died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush(), shmlog.c line 196: Condition(loghead->ptr < loghead->size) not true. thread = (cache-worker)sp = 0x2aaaeb317008 { fd = 10, id = 10, xid = 0, client = 10.4.4.5:60313, step = STP_DONE, handling = deliver, ws = 0x2aaaeb317078 { id = "sess", {s,f,r,e} = {0x2aaaeb317808,,+256,(nil),+16384}, }, worker = 0x40adcbe0 { }, }, Jan 11 03:50:17 web2 varnishd[8785]: child (24840) Started Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Closed fds: 4 5 6 11 12 14 15 Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Child starts Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said managed to mmap 1073741824 bytes of 1073741824 Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Ready Please help! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 14 09:34:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 Jan 2010 09:34:50 -0000 Subject: [Varnish] #616: Persistent crash (sig11) in trunk 4434 In-Reply-To: <052.bea17b1d59c11964d1c0bfd2a72fd360@projects.linpro.no> References: <052.bea17b1d59c11964d1c0bfd2a72fd360@projects.linpro.no> Message-ID: <061.3d6fe6e3d1e57d19aad521d70dfbbd86@projects.linpro.no> #616: Persistent crash (sig11) in trunk 4434 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Another sig 11 core dump today: {{{ (gdb) bt #0 0x00000008009cf35f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 #1 0x00000008009cf394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 #2 0x0000000000421ac8 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000421e77 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:329 #4 0x0000000000423fef in RES_WriteObj (sp=0x174dd89008) at cache_response.c:230 #5 0x000000000041322c in cnt_deliver (sp=0x174dd89008) at cache_center.c:204 #6 0x0000000000413f06 in CNT_Session (sp=0x174dd89008) at steps.h:42 #7 0x0000000000423d01 in wrk_do_cnt_sess (w=0x7fffa773c800, priv=Variable "priv" is not available. ) at cache_pool.c:277 #8 0x000000000042300d in wrk_thread_real (qp=0x80110f9c0, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:173 #9 0x0000000800bf04d1 in pthread_getprio () from /lib/libthr.so.3 #10 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffa773e000 (gdb) frame 4 #4 0x0000000000423fef in RES_WriteObj (sp=0x174dd89008) at cache_response.c:230 230 assert(u == sp->obj->len); (gdb) print *sp $1 = {magic = 741317722, fd = 183, id = 183, xid = 1490837284, restarts = 0, esis = 0, disable_esi = 0, wrk = 0x7fffa773c800, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x174dd89b50, mysockaddr = 0x174dd89bd0, mylsock = 0x80111be80, addr = 0x174dd89c50 "91.186.78.4", port = 0x174dd89c5c "5170", doclose = 0x44262c "Connection: close", http = 0x174dd89258, http0 = 0x174dd896c8, ws = {{magic = 905626964, id = 0x446688 "sess", s = 0x174dd89c50 "91.186.78.4", f = 0x174dd89e49 "", r = 0x0, e = 0x174dd8dc50 '?' ..., overflow = 0}}, ws_ses = 0x174dd89c61 "GET", ws_req = 0x174dd89e49 "", digest = "k?\200????\227?]:?9\224]\t?h?c?b|B??:V\223?\225\027", htc = {{ magic = 1041886673, fd = 183, ws = 0x174dd89078, rxbuf = { b = 0x174dd89c61 "GET", e = 0x174dd89e49 ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1263444485.1270056, t_req = 1263444485.1270394, t_resp = 1263444485.1270812, t_end = 1263444485.1270056, connect_timeout = 0.40000000000000002, first_byte_timeout = 60, between_bytes_timeout = 60, grace = 300, step = STP_DELIVER, cur_method = 0, handling = 0, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x0, vbe = 0x0, obj = 0x8516d8970, objcore = 0x0, objhead = 0x0, vcl = 0x1710372328, mem = 0x174dd89000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x423c40 , priv = 0x174dd89008}, acct = {first = 1263444485.1270056, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 341, bodybytes = 22672}} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 15 23:42:02 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 15 Jan 2010 23:42:02 -0000 Subject: [Varnish] #621: Varnish pooling feature - ala memcached like Varnish(es) Message-ID: <060.59fe95b6c136e51ad80e8a3c29dac25a@projects.linpro.no> #621: Varnish pooling feature - ala memcached like Varnish(es) ----------------------------+----------------------------------------------- Reporter: pubcrawler.com | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------------+----------------------------------------------- Have we considered adding pooling functionality to Varnish much like what they have in memcached? Run multiple Varnish(es) and load distributed amongst the identified Varnish server pool.... So an element in Varnish gets hashed and the hash identifies the server in the pool it's on. If the server isn't there or the element isn't there cold lookup to the backend server then we store it where it should be. Seems like an obvious feature - unsure of the performance implications though. The recommendation of load balancers in front on Varnish to facilitate this feature seems costly when talking about F5 gear. The open source solutions require at least two severs dedicated to this load balancing function for sanity sake (which is costly). Finally, Vanish already offers load balancing (although limited) to the back end servers - so lets do the same within Varnish to make sure Varnish scales horizontally and doesn't require these other aids to be deemed totally reliable. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 17 01:03:09 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 17 Jan 2010 01:03:09 -0000 Subject: [Varnish] #503: Assertion failure when trying to fetch a large object In-Reply-To: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> References: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> Message-ID: <060.1735fbc952ee04fd14d4d7ddfec10efc@projects.linpro.no> #503: Assertion failure when trying to fetch a large object --------------------+------------------------------------------------------- Reporter: Sesse | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | --------------------+------------------------------------------------------- Comment (by danros): Could you not simply pipe objects which have a content length in excess of the storage space? Also, it's news to me that Varnish is not suitable for caching any kind of large media or other large files. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 17 13:49:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 17 Jan 2010 13:49:00 -0000 Subject: [Varnish] #621: Varnish pooling feature - ala memcached like Varnish(es) In-Reply-To: <060.59fe95b6c136e51ad80e8a3c29dac25a@projects.linpro.no> References: <060.59fe95b6c136e51ad80e8a3c29dac25a@projects.linpro.no> Message-ID: <069.1ef6d68796bc29f293694630ed781faf@projects.linpro.no> #621: Varnish pooling feature - ala memcached like Varnish(es) ----------------------------+----------------------------------------------- Reporter: pubcrawler.com | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Comment (by slink): Varnish should already provide all you need to do this, except load balancing based on a hash of the content. I have implemented a simple variant of such a director already and hope to publish a nicer version soon. If you have f5 gear available already, you've certainly got all you need to do this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 09:46:58 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 09:46:58 -0000 Subject: [Varnish] #582: Varhish crash with no error code In-Reply-To: <054.6288692149fe22877a0c7692d2babcec@projects.linpro.no> References: <054.6288692149fe22877a0c7692d2babcec@projects.linpro.no> Message-ID: <063.ef24f3e5e41a8a234ebfbb6581acafb9@projects.linpro.no> #582: Varhish crash with no error code ------------------------------------------------------------------------------------------+ Reporter: doserror | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: varnishd (varnish-2.0.4) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS | ------------------------------------------------------------------------------------------+ Comment (by tfheen): Have you had a chance to get us any core dumps? Also, do you see the same problem with 2.0.6? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 09:51:20 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 09:51:20 -0000 Subject: [Varnish] #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> References: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> Message-ID: <068.f0120513e9b5926098e1fecae9adf83a@projects.linpro.no> #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 ---------------------------+------------------------------------------------ Reporter: erik.berglund | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by tfheen): Given this suddenly appeared, did it go away too or are you still seeing it? Can you reproduce it with 2.0.6? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 11:37:26 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 11:37:26 -0000 Subject: [Varnish] #621: Varnish pooling feature - ala memcached like Varnish(es) In-Reply-To: <060.59fe95b6c136e51ad80e8a3c29dac25a@projects.linpro.no> References: <060.59fe95b6c136e51ad80e8a3c29dac25a@projects.linpro.no> Message-ID: <069.228751914e66c1ce31ad6c6d7e24e797@projects.linpro.no> #621: Varnish pooling feature - ala memcached like Varnish(es) ----------------------------+----------------------------------------------- Reporter: pubcrawler.com | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------------+----------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This is a feature-request, we generally do not use tickets for that, in order to not bury the bug-reports in piles of good, but not quite actionable suggestions. The topic was discussed on the varnish-misc mailing list, and absent concrete proposals, there is nothing more we can do here right now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 11:39:40 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 11:39:40 -0000 Subject: [Varnish] #217: varnishtop freeze In-Reply-To: <049.a5bcd9b08e2b26a91152e804621bfcd7@projects.linpro.no> References: <049.a5bcd9b08e2b26a91152e804621bfcd7@projects.linpro.no> Message-ID: <058.b7246f98bac9d24ce904f5cd463186f0@projects.linpro.no> #217: varnishtop freeze ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: I went over the shmlog code in libvarnishapi, and there were a number of scalability issues fixed. Hopefully that takes care of this problem, once/if it gets merged to 2.x -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 11:58:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 11:58:21 -0000 Subject: [Varnish] #582: Varhish crash with no error code In-Reply-To: <054.6288692149fe22877a0c7692d2babcec@projects.linpro.no> References: <054.6288692149fe22877a0c7692d2babcec@projects.linpro.no> Message-ID: <063.b7266a7cd16da2aa5f3cd92183427b32@projects.linpro.no> #582: Varhish crash with no error code ------------------------------------------------------------------------------------------+ Reporter: doserror | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: varnishd (varnish-2.0.4) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS | ------------------------------------------------------------------------------------------+ Comment (by kristian): Can you see if you have an assert error in /var/log/syslog ? On debian- based systems, /var/log/messages doesn't contain the actual assert error, while /var/log/syslog do. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 12:03:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 12:03:57 -0000 Subject: [Varnish] #619: Varnish stalled connections In-Reply-To: <053.e844cef13dc2e3cce139a62d8f8ddc3e@projects.linpro.no> References: <053.e844cef13dc2e3cce139a62d8f8ddc3e@projects.linpro.no> Message-ID: <062.ec9c61839089d14111855c74677973af@projects.linpro.no> #619: Varnish stalled connections ----------------------+----------------------------------------------------- Reporter: victori | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: Sounds like the fd-passing pipe is blocking. Will investigate once I get my hands on a opensolaris account. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 12:21:22 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 12:21:22 -0000 Subject: [Varnish] #617: Odd output in varnishncsa In-Reply-To: <052.9397a7c1997da9c6a9784c50147564e6@projects.linpro.no> References: <052.9397a7c1997da9c6a9784c50147564e6@projects.linpro.no> Message-ID: <061.b2842795de102972314910a08fe509ef@projects.linpro.no> #617: Odd output in varnishncsa -------------------------+-------------------------------------------------- Reporter: jelder | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * owner: => kristian * status: new => assigned Comment: At the time being, varnishncsa doesn't _really_ support backend requests. Obviously it should say so. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 12:42:35 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 12:42:35 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.b8ce759c0287cc83da1a33fedee0d8b3@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: website | Version: 2.0 Severity: critical | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Comment (by tfheen): Is this reproducible? Also, if you could try with 2.0.6 that'd be appreciated as there is a fix there that I believe fixes this problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 13:30:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 13:30:49 -0000 Subject: [Varnish] #540: X-Forwarded-For created and not appended. In-Reply-To: <055.5449af7e5b7e33441d8b0f9e65fb0fac@projects.linpro.no> References: <055.5449af7e5b7e33441d8b0f9e65fb0fac@projects.linpro.no> Message-ID: <064.4ea4fd6bc64ebbae08281e88c04c15eb@projects.linpro.no> #540: X-Forwarded-For created and not appended. -----------------------+---------------------------------------------------- Reporter: bmfurtado | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4467]) Produce the X-Forwarded-For: header in vcl_recv, so people can tweak as they want. Append to already existing header if possible. NB: If you return early from your own vcl_recv, without pasting these lines in top of your vcl_recv, your backend gets no X-F-F header. Fixes #601 Fixes #540 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 13:30:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 13:30:50 -0000 Subject: [Varnish] #601: adding the X-Forwarded-For Header should be optional In-Reply-To: <050.553044ee4ef2849ec7a5fff487fbf81e@projects.linpro.no> References: <050.553044ee4ef2849ec7a5fff487fbf81e@projects.linpro.no> Message-ID: <059.7ee5d718d381e1282cc3e1cf415381dd@projects.linpro.no> #601: adding the X-Forwarded-For Header should be optional -------------------------+-------------------------------------------------- Reporter: Elfe | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4467]) Produce the X-Forwarded-For: header in vcl_recv, so people can tweak as they want. Append to already existing header if possible. NB: If you return early from your own vcl_recv, without pasting these lines in top of your vcl_recv, your backend gets no X-F-F header. Fixes #601 Fixes #540 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 13:33:23 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 13:33:23 -0000 Subject: [Varnish] #618: obj.cacheable should consider no-cache in addition to s-maxage In-Reply-To: <052.3415b974e62135ca20f54d99d4f67ac2@projects.linpro.no> References: <052.3415b974e62135ca20f54d99d4f67ac2@projects.linpro.no> Message-ID: <061.1c80d93baea5116daada8334ebb15c29@projects.linpro.no> #618: obj.cacheable should consider no-cache in addition to s-maxage ----------------------+----------------------------------------------------- Reporter: jelder | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: I have moved this to the feature wish list and started a discussion on varnish-misc about it. Please chime in there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 14:53:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 14:53:01 -0000 Subject: [Varnish] #613: Efficiency figure for varnishstat In-Reply-To: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> References: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> Message-ID: <060.71ae56b1a68b70b393cf2789ce50246b@projects.linpro.no> #613: Efficiency figure for varnishstat -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: While I see the point in having something like this, I don't think we want to add it. The reason is people already are confused enough by the hit ratio and what it means. I'd be willing to discuss replacing the current hit ratio with your new measure if you can drum up support for it on varnish-misc. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 18 16:24:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 Jan 2010 16:24:32 -0000 Subject: [Varnish] #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> References: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> Message-ID: <068.c55599e81a9532bb6319e04256a72203@projects.linpro.no> #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 ---------------------------+------------------------------------------------ Reporter: erik.berglund | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by zagl0ba): Hello, i run varnish trunk 4468 on opensolaris. I observe same behavior, varnish crashes after about 1-2 hours of run. Regards, Pawel -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 19 20:10:15 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 19 Jan 2010 20:10:15 -0000 Subject: [Varnish] #613: Efficiency figure for varnishstat In-Reply-To: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> References: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> Message-ID: <060.3c0bf6308e52813597b4ba7af9e9a08c@projects.linpro.no> #613: Efficiency figure for varnishstat -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Comment (by slink): good point, Tollef, posting is out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 20 14:57:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 20 Jan 2010 14:57:49 -0000 Subject: [Varnish] #622: restart of varnishd sometimes fails on busy server Message-ID: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> #622: restart of varnishd sometimes fails on busy server ----------------------+----------------------------------------------------- Reporter: nicholas | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Sometimes we unfortunately need to restart varnishd. Running redhat and on a busy server, the normal stop/start routines doesn't always succeed. /etc/init.d/varnish restart says OK twice, but no varnish is running afterwoods. This of course only happens sometimes. Our theory is: stop() uses killproc -p $pidfile $prog, which in turn sends SIGTERM to pid of mother-process. Mother-process goes away nicely, but children linger on trying to finnish their work. When the start routine does daemon --pidfile $pidfile $exec -P $pidfile "$DAEMON_OPTS" - the mother-process starts successful, but the port in use is still busy which children finnishing their work, so the new child fails to bind to port. The mother-process succeds enough for the start script to say OK though, so if you don't watch out it will go unnoticed by the sysadmin until nagios starts making noise. This is probably logged in syslog, but I forgot to save. If possible, we would like to see this fixed in varnishd, and not by making spesial start/stop routines in redhat. Any way to make restart smoother, without breaking too many http sessions or introducing unnecessary sleeps? Nicholas -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 08:21:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 08:21:17 -0000 Subject: [Varnish] #622: restart of varnishd sometimes fails on busy server In-Reply-To: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> References: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> Message-ID: <063.e4359c4a9fa4ce09888a90a7da7807ad@projects.linpro.no> #622: restart of varnishd sometimes fails on busy server ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ingvar): Had a chat with Kristian. There may be at least two possible ways to solve this: 1) Make the mother process wait for its children to end before dying 2) At receiving SIGTERM, make the varnishd child processes stop using system resources that prevents a new varnishd from forking new children (ie. shut down its port immediately). Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 11:02:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 11:02:19 -0000 Subject: [Varnish] #623: Should use TIM_mono rather than TIM_real in most places Message-ID: <051.3bde70cd61a1544c928573f302745281@projects.linpro.no> #623: Should use TIM_mono rather than TIM_real in most places ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- (Please assign this ticket to me if you like - I'd be happy to care about this, but I'd also appreciate anyone else working on this - but let's coordinate) Various internal timers and timeouts are based upon TIM_real (CLOCK_REALTIME) and as such are not invariant of adjustments to the "wall clock" time. Varnish will behave erroneously if the clock is stepped, in particular if it is stepped backwards. TIM_mono should be used for internal timers and timeouts. Care must be taken to preserve correct output for externally visible or referenced timestamps, so I don't expect this to be a trivial change. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 13:00:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 13:00:19 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly Message-ID: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- I'm running Varnish 2.0.6 on Linux and seeing random but regular "FetchError c http read error: 0" errors on my varnishlog with 503 responded to the client. backend_http11 feature is turned on (by default), and so requests to the backend should be HTTP/1.1. However, it seems the Varnish does the requests with HTTP/1.0 header, backend closes the connection after response as keep-alive is not requested and after all this Varnish tries to re-use the connection and assumes the connection to be open (as it would be if HTTP version was 1.1) As a workaround, everything seems to work just fine with following configuration: sub vcl_recv { set req.proto = "HTTP/1.1"; -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 13:08:13 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 13:08:13 -0000 Subject: [Varnish] #622: restart of varnishd sometimes fails on busy server In-Reply-To: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> References: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> Message-ID: <063.40a50e8dfd36699876f4e3c44e05b58e@projects.linpro.no> #622: restart of varnishd sometimes fails on busy server ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by nicholas): Got bitten by it just now: Jan 21 12:58:13 bambu varnish-v3front[15631]: Manager got SIGINT Jan 21 12:58:13 bambu varnish-v3front[6201]: Child start failed: could not open sockets -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 14:24:12 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 14:24:12 -0000 Subject: [Varnish] #613: Efficiency figure for varnishstat In-Reply-To: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> References: <051.0922663f50fb028281c5fa9edde16c4c@projects.linpro.no> Message-ID: <060.61045d5362e4ba46923c9c18b79e73cd@projects.linpro.no> #613: Efficiency figure for varnishstat -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Comment (by slink): The current implementation needs another review. Looks like we need to sanitize some numbers not to get odd results like this: {{{ Hitrate ratio: 10 14 14 Hitrate avg: 0.9793 0.9794 0.9794 Efficiency ratio: 10 14 14 Efficiency avg: -252.4640 -250.5249 -250.5249 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 21 21:36:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 21 Jan 2010 21:36:31 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.72da21a802bcbd7b9a093186771839b4@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by lomic): I can confirm the problem too. Is there any solution or workaround? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 00:11:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 00:11:41 -0000 Subject: [Varnish] #625: Glitch in poll waiter recycle batch logic (changeset 4445) Message-ID: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> #625: Glitch in poll waiter recycle batch logic (changeset 4445) ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- http://varnish.projects.linpro.no/changeset/4445 : {{{ #!C for (j = 0; j * sizeof ss[0] < i; j += sizeof ss[0]) { }}} should read: {{{ #!C for (j = 0; j * sizeof ss[0] < i; j++) { }}} (ARGL. It's taken me far too long to spot this) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 01:05:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 01:05:38 -0000 Subject: [Varnish] #625: Glitch in poll waiter recycle batch logic (changeset 4445) In-Reply-To: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> References: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> Message-ID: <060.94d4fc9111811bff3427ff26e962d7fb@projects.linpro.no> #625: Glitch in poll waiter recycle batch logic (changeset 4445) ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Slink thanks for the fix, I knew something was off with r4445 and up. http://varnish.projects.linpro.no/ticket/619 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 01:16:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 01:16:57 -0000 Subject: [Varnish] #625: Glitch in poll waiter recycle batch logic (changeset 4445) In-Reply-To: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> References: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> Message-ID: <060.f356d6c8bcbe7868d709072d75f1915a@projects.linpro.no> #625: Glitch in poll waiter recycle batch logic (changeset 4445) ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Slink, your my new solaris patch-fixing hero. Updated solaris blog documentation so people apply your patch to avoid stalled connections. http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 08:23:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 08:23:03 -0000 Subject: [Varnish] #623: Should use TIM_mono rather than TIM_real in most places In-Reply-To: <051.3bde70cd61a1544c928573f302745281@projects.linpro.no> References: <051.3bde70cd61a1544c928573f302745281@projects.linpro.no> Message-ID: <060.96b70fa7575b696916e74e0c31a7eddb@projects.linpro.no> #623: Should use TIM_mono rather than TIM_real in most places ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: I originally created TIM_mono() for exactly that purpose, but have since realized that varnish is so royally screwed that there is no beginning or end, if the clock is changed in any significant way, because most cache content is handled on an absolute UTC timescale. If anything, I think we need to restart the worker thread if we detect a time-step, because we may have to resort our hash, and the code complexity for that is certainly not warranted, just for people who cannot get /etc/ntp.conf right. So I think the answer is "thanks, but no thanks", this is a problem that needs to be solved outside Varnish. Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 08:23:45 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 08:23:45 -0000 Subject: [Varnish] #619: Varnish stalled connections In-Reply-To: <053.e844cef13dc2e3cce139a62d8f8ddc3e@projects.linpro.no> References: <053.e844cef13dc2e3cce139a62d8f8ddc3e@projects.linpro.no> Message-ID: <062.00fef6af94897b16ecbd2d1f28440ed5@projects.linpro.no> #619: Varnish stalled connections ----------------------+----------------------------------------------------- Reporter: victori | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: See #625, I botched up that commit. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 08:25:26 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 08:25:26 -0000 Subject: [Varnish] #625: Glitch in poll waiter recycle batch logic (changeset 4445) In-Reply-To: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> References: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> Message-ID: <060.22bd98a640ccce1052ec817b7f8df78e@projects.linpro.no> #625: Glitch in poll waiter recycle batch logic (changeset 4445) ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4478]) Fix the poll-waiter after I botched it in r4445. Fixes #625 Submitted by: slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 09:24:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 09:24:59 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c Message-ID: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Here is the trace # /opt/startvarnish.sh storage_file: filename: /sessions/varnish_cache.bin size 512 MB. Message from C-compiler: "./vcl.hndxcCNb.c", line 355: warning: initializer will be sign-extended: -1 Using old SHMFILE child (16367) Started Child (16367) said Closed fds: 3 5 6 9 10 12 13 Child (16367) said Child starts Child (16367) said managed to mmap 536870912 bytes of 536870912 Child (16367) died signal=6 Child (16367) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 149: Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) == 0) not true. errno = 9 (Bad file number) thread = (cache-worker) Backtrace: 42e3c5: /opt/extra/sbin/varnishd'pan_ic+0x95 [0x42e3c5] 10: [0x10] sp = b95018 { fd = 16, id = 16, xid = 0, client = 78.155.225.100:50256, step = STP_FIRST, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = b95088 { id = "sess", {s,f,r,e} = {b95da8,+21,0,+65536}, }, http[req] = { ws = b95088[sess] "", "/question/id/4786", "HTTP/1.1", "Accept: */*", "Host: fabulously40.com", "If-Modified-Since: Tue, 12 Jan 2010 07:15:17 GMT", "User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm)", "Connection: Keep-Alive", "Cache-Control: no-cache", "Pragma: no-cache", "X-Forwarded-For: 65.55.106.163", "Accept-Encoding: gzip", }, worker = fffffd7fc7889d20 { ws = fffffd7fc7889e68 { id = "wrk", {s,f,r,e} = {fffffd7fc7877cb0,fffffd7fc7877cb0,0,+65536}, }, }, }, Child cleanup complete child (19587) Started Child (19587) said Closed fds: 3 5 6 9 10 12 13 Child (19587) said Child starts Child (19587) said managed to mmap 536870912 bytes of 536870912 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 09:25:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 09:25:27 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c In-Reply-To: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> References: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> Message-ID: <062.2b0f710c20d9daa3ff4a7aca22f25ee1@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by victori): Err sorry for the formatting, here is a link to the raw snippet. http://pastie.org/789516.txt This is on opensolaris. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 18:44:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 18:44:41 -0000 Subject: [Varnish] #623: Should use TIM_mono rather than TIM_real in most places In-Reply-To: <051.3bde70cd61a1544c928573f302745281@projects.linpro.no> References: <051.3bde70cd61a1544c928573f302745281@projects.linpro.no> Message-ID: <060.b4a265f47c7c455f3d1d9e4a5cfaf9af@projects.linpro.no> #623: Should use TIM_mono rather than TIM_real in most places ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Poul-Henning, thanks for your explanations. I probably haven't understood enough about how tightly varnish data structures are bound to wallclock time. I'd still be interested though to revisit this topic, but, yes, I can always reopen the ticket should I dare to. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 18:46:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 18:46:16 -0000 Subject: [Varnish] #627: Missing ticket change notifications Message-ID: <051.2b19f9d32b9d21489dda63774a5fbf3c@projects.linpro.no> #627: Missing ticket change notifications -------------------+-------------------------------------------------------- Reporter: slink | Type: enhancement Status: new | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- As discussed with phk: It would be great if you could implement/fix change notifications. I do get email for my own changes to tickets, but not for those of others. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 18:47:45 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 18:47:45 -0000 Subject: [Varnish] #625: Glitch in poll waiter recycle batch logic (changeset 4445) In-Reply-To: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> References: <051.f230c21c6af5184111e76c70ef121f91@projects.linpro.no> Message-ID: <060.de498e6e9fe5cf9a512c70ed64fe0031@projects.linpro.no> #625: Glitch in poll waiter recycle batch logic (changeset 4445) ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Thanks for your nice feedback, victori, more fixes are to be exptected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 18:52:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 18:52:03 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> References: <051.2c223427ba1546d13326db79182cfdb2@projects.linpro.no> Message-ID: <060.27e6aedba5bbb54c51a86fc66f64a8ea@projects.linpro.no> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Just for completeness: I am happy with not integrating the complete change for the time being, but I would like to add that rushing too often is simply a bug. That I also see it as enabler for other improvements is another side of the same story. (But really no bad feelings here, I'm with you Paul-Henning) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 19:15:44 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 19:15:44 -0000 Subject: [Varnish] #628: Least privileges for Varnish: no privileges Message-ID: <051.14a25568fa21b7191fc98b94f24cadad@projects.linpro.no> #628: Least privileges for Varnish: no privileges -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- I've implemented a very simple change so Varnish "worker children" will waive all privileges on Solaris, which can help to minimize to hypothetical impact of attacks against Varnish as the children are handling client connections. I don't think a varnish worker child should need any privileges, so I have implemented just that, but one might want to add config options to specify the privilege sets. Please note that I consider this patch experimental still, though I haven't noted any negative side effects. With this patch, running ppriv on the varnish control process and its child looks nice: {{{ 25477: /tmp/sbin/varnishd -a 0.0.0.0:80 -T localhost:6082 -p rush_exponent=6 flags = E: file_link_any,net_privaddr,proc_exec,proc_fork,proc_lock_memory,proc_setid I: file_link_any,net_privaddr,proc_exec,proc_fork,proc_lock_memory,proc_setid P: file_link_any,net_privaddr,proc_exec,proc_fork,proc_lock_memory,proc_setid L: file_link_any,net_privaddr,proc_exec,proc_fork,proc_lock_memory,proc_setid 25478: /tmp/sbin/varnishd -a 0.0.0.0:80 -T localhost:6082 -p rush_exponent=6 flags = PRIV_AWARE E: none I: none P: none L: none }}} The patch is for 2.0.3 but should be easily applicable to other versions as well. Note that you need to run autoconf & autoheader to apply configure.ac changes -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 22 19:52:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 Jan 2010 19:52:59 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor Message-ID: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Hi, I've implemented a couple of fixes for the event port acceptor and the results look promising - I couldn't reproduce hanging client connections with these. Bug fixes are: * Upon HTC_Rx(sp->htc) == 0, we need to wait for more (header) data, so we need to vca_add again (because with event ports, we need to reasssociate to get another event) * port_getn may even deliver events if (errno == EINTR) || (errno == ETIME), so we need to check nevents even if the return value is < 0. Otherwise we'll see hanging client connections Cosmetic changes: * POLLERR is not an event, but just an revent * I don't think we need to register for POLLPRI events Others: * Increase port_getn timeout from 50ms to 100ms to match the poll acceptor/waiter * No need to call vca_del once we've received an event for the respective fd I'll attach the cache_acceptor_ports.c file as of 2.x Please note: * For older 2.x versions, you'll need to remove the TCP_linger call * For trunc, apply s:acceptor:waiter: Cheers, Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 23 12:47:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 23 Jan 2010 12:47:50 -0000 Subject: [Varnish] #630: helpers to convert varnish time into struct timespec/timeval Message-ID: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> #630: helpers to convert varnish time into struct timespec/timeval -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- I needed a way to convert varnish double float time into struct timespect/timeval, and so I implemented this generically. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 23 13:02:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 23 Jan 2010 13:02:38 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.2d2261413baaf4cbaa99f36d3ac4833b@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): I've thought about the port_getn timeout again: For nevents == 1 the only purpose is to wake up again to check for session timeouts, so I've made the timeout dynamic. I have done tests with max_ts set to 60 and all went smoothly. Note that if one wants to increase efficiency by batching up more requests with (nevents > 1), min_ts and max_ts actually get more important as they then define not only the tolerance for session expiry, but also a range of additional latency for processing of keepalive requests. In short, if you always want best latency, stick to nevents == 1, if you set nevets > 1, i'd recommend something like 5ms / 20ms for min/max (if 20ms is the max additional latency you want to experience for a client). {{{ #!C const struct timespec min_ts = {0L, 5L /*ms*/ * 1000L /*us*/ * 1000L /*ns*/}; const double min_t = 0.005;/* 5 ms*/ const struct timespec max_ts = {0L, 20L /*ms*/ * 1000L /*us*/ * 1000L /*ns*/}; const double max_t = 0.02;/* 20 ms*/ }}} Note: The new version depends on #630 for TIM_t2ts() -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 23 13:33:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 23 Jan 2010 13:33:27 -0000 Subject: [Varnish] #630: helpers to convert varnish time into struct timespec/timeval In-Reply-To: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> References: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> Message-ID: <060.1fa30edfd62f7a02075539889990a532@projects.linpro.no> #630: helpers to convert varnish time into struct timespec/timeval -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by slink): Ooops I wonder how I got the version to compile with autoconf. Uploading corrected version. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 23 21:59:48 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 23 Jan 2010 21:59:48 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.9f608a93994cdec65bf1430439aa75c6@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by lomic): I think esi includes are a great feature of varnish.[[BR]] Actual i use varnish version '''2.06'''.[[BR]] So why has this bug only the priority normal?[[BR]] Many proxies still uses the HTTP/1.0 protocol.[[BR]] For now i can not use esi includes for my website and [[BR]] i have to simulate the includes in the backend application.[[BR]] I hope this bug will get a higher priority and will be fixed within the next varnish version. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 24 05:23:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 24 Jan 2010 05:23:03 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.d1a6504bc24fc5a5df14d35306061ae3@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Seems broken on OpenSolaris SNV98 Here is the tracelog. It keeps restarting the child processes over and over in a tight loop. Build: Varnish from trunk. http://pastie.org/791964 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 24 05:29:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 24 Jan 2010 05:29:17 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.3d6b43b2d5d4cb75e15548a2c0988a7b@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): It seems to work with the assert line removed. I will post it up on our site, see if it causes any issues and report back. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 24 11:10:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 24 Jan 2010 11:10:04 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.39676ee61123a8df74574e39186bf784@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): After a few hours of testing, eventports seem to still stall on connections, but a lot less. Poll seems to be the only solution here on SNV98. It might be just SNV98 with a broken eventports implementation? who knows, but I am stuck with it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 12:19:23 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 12:19:23 -0000 Subject: [Varnish] #617: Odd output in varnishncsa In-Reply-To: <052.9397a7c1997da9c6a9784c50147564e6@projects.linpro.no> References: <052.9397a7c1997da9c6a9784c50147564e6@projects.linpro.no> Message-ID: <061.d4230563f8af1b5cb210a8064920f732@projects.linpro.no> #617: Odd output in varnishncsa -------------------------+-------------------------------------------------- Reporter: jelder | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * status: assigned => closed * resolution: => fixed Comment: (In [4480]) Only handle client requests (-c) for varnishncsa Fixes #617 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 12:19:28 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 12:19:28 -0000 Subject: [Varnish] #548: Sig 11 crash in trunk 4199 In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> Message-ID: <061.b0cb157517b180febe2f6c1fd7788c73@projects.linpro.no> #548: Sig 11 crash in trunk 4199 ---------------------------------------------+------------------------------ Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: sig 11 segmentation fault trunk | ---------------------------------------------+------------------------------ Comment (by anders): This is still happening with trunk/4434, any chance for a resolution: {{{ (gdb) bt #0 0x00000008009cf35f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 #1 0x00000008009cf394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 #2 0x0000000000421ac8 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000421e77 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:329 #4 0x000000000041c82d in HSH_Lookup (sp=0x10eacf2008, poh=0x7fffadb68720) at cache_hash.c:407 #5 0x0000000000411ba4 in cnt_lookup (sp=0x10eacf2008) at cache_center.c:780 #6 0x0000000000413f96 in CNT_Session (sp=0x10eacf2008) at steps.h:38 #7 0x0000000000423d01 in wrk_do_cnt_sess (w=0x7fffadb6e800, priv=Variable "priv" is not available. ) at cache_pool.c:277 #8 0x000000000042300d in wrk_thread_real (qp=0x80110f4c0, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:173 #9 0x0000000800bf04d1 in pthread_getprio () from /lib/libthr.so.3 #10 0x00007fffad970000 in ?? () Cannot access memory at address 0x7fffadb70000 (gdb) frame 4 #4 0x000000000041c82d in HSH_Lookup (sp=0x10eacf2008, poh=0x7fffadb68720) at cache_hash.c:407 407 CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC); (gdb) print *sp $1 = {magic = 741317722, fd = 3699, id = 3699, xid = 1480106783, restarts = 0, esis = 0, disable_esi = 0, wrk = 0x7fffadb6e800, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x10eacf2b50, mysockaddr = 0x10eacf2bd0, mylsock = 0x80111be80, addr = 0x10eacf2c50 "80.213.121.208", port = 0x10eacf2c5f "4747", doclose = 0x0, http = 0x10eacf2258, http0 = 0x10eacf26c8, ws = {{magic = 905626964, id = 0x446688 "sess", s = 0x10eacf2c50 "80.213.121.208", f = 0x10eacf3011 "tion: Keep-Alive, TE", r = 0x0, e = 0x10eacf6c50 '?' ..., overflow = 0}}, ws_ses = 0x10eacf2c64 "GET", ws_req = 0x10eacf2ffa "Accept-Encoding: gzip", digest = "T?WMW?\tX.????EC\035V\002?\f\201?s?G\031\221Cm'??", htc = {{ magic = 1041886673, fd = 3699, ws = 0x10eacf2078, rxbuf = { b = 0x10eacf2c64 "GET", e = 0x10eacf2ffa "Accept-Encoding: gzip"}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1264365582.6530151, t_req = 1264365582.7233465, t_resp = nan(0x8000000000000), t_end = 1264365582.6530151, connect_timeout = 0.40000000000000002, first_byte_timeout = 60, between_bytes_timeout = 60, grace = 300, step = STP_LOOKUP, cur_method = 0, handling = 3, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = { vtqe_next = 0x80e0cf008, vtqe_prev = 0xee38bb170}, director = 0x80bbeeec8, vbe = 0x0, obj = 0x0, objcore = 0x0, objhead = 0x0, vcl = 0x80bbf90e8, mem = 0x10eacf2000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x423c40 , priv = 0x10eacf2008}, acct = { first = 1264365582.6346316, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 345, bodybytes = 1135}, acct_req = {first = 0, sess = 0, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}} (gdb) print *oc $2 = {magic = 1294996226, obj = 0x0, objhead = 0xfa6ab4a90, timer_when = 1264888298.0438495, flags = 0, timer_idx = 0, list = { vtqe_next = 0x0, vtqe_prev = 0xfa6ab4aa8}, lru_list = { vle_next = 0x12b0aad2e0, vle_prev = 0x80112b688}, ban_list = { vtqe_next = 0x10e4efc580, vtqe_prev = 0x15ef767478}, smp_seg = 0x0, ban = 0x0} }}} Some lines around line 407, cache_hash.c: {{{ if (oc != NULL) { o = oc->obj; CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC); /* We found an object we like */ o->refcnt++; if (o->hits < INT_MAX) o->hits++; assert(oh->refcnt > 1); Lck_Unlock(&oh->mtx); assert(hash->deref(oh)); *poh = oh; return (oc); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 12:22:33 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 12:22:33 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.413d50d1d380d3edd1313ddfcd28a35b@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * owner: phk => kristian * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 12:37:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 12:37:39 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.16b8a42ff3bf66d4a4654567cc653d9e@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Changes (by kristian): * owner: => kristian * priority: highest => normal * status: new => assigned * component: website => varnishd * severity: critical => normal Comment: Did you by any chance compile by hand, and/or get a chance to test this for 2.0.6? Or if it's happened again? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 12:46:15 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 12:46:15 -0000 Subject: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> References: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> Message-ID: <062.a7c97715f95ebc0961e023b68240092b@projects.linpro.no> #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 ----------------------+----------------------------------------------------- Reporter: jhayter | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Notice similarity to #588. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 14:04:34 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 14:04:34 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c In-Reply-To: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> References: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> Message-ID: <062.5ef2e89545f65151bd02d32001f1d367@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Old description: > Here is the trace > > # /opt/startvarnish.sh > storage_file: filename: /sessions/varnish_cache.bin size 512 MB. > Message from C-compiler: > "./vcl.hndxcCNb.c", line 355: warning: initializer will be sign-extended: > -1 > Using old SHMFILE > child (16367) Started > Child (16367) said Closed fds: 3 5 6 9 10 12 13 > Child (16367) said Child starts > Child (16367) said managed to mmap 536870912 bytes of 536870912 > Child (16367) died signal=6 > Child (16367) Panic message: Assert error in VCA_Prep(), cache_acceptor.c > line 149: > Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) > == 0) not true. > errno = 9 (Bad file number) > thread = (cache-worker) > Backtrace: > 42e3c5: /opt/extra/sbin/varnishd'pan_ic+0x95 [0x42e3c5] > 10: [0x10] > sp = b95018 { > fd = 16, id = 16, xid = 0, > client = 78.155.225.100:50256, > step = STP_FIRST, > handling = deliver, > err_code = 200, err_reason = (null), > restarts = 0, esis = 0 > ws = b95088 { > id = "sess", > {s,f,r,e} = {b95da8,+21,0,+65536}, > }, > http[req] = { > ws = b95088[sess] > "", > "/question/id/4786", > "HTTP/1.1", > "Accept: */*", > "Host: fabulously40.com", > "If-Modified-Since: Tue, 12 Jan 2010 07:15:17 GMT", > "User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm)", > "Connection: Keep-Alive", > "Cache-Control: no-cache", > "Pragma: no-cache", > "X-Forwarded-For: 65.55.106.163", > "Accept-Encoding: gzip", > }, > worker = fffffd7fc7889d20 { > ws = fffffd7fc7889e68 { > id = "wrk", > {s,f,r,e} = {fffffd7fc7877cb0,fffffd7fc7877cb0,0,+65536}, > }, > }, > }, > > Child cleanup complete > child (19587) Started > Child (19587) said Closed fds: 3 5 6 9 10 12 13 > Child (19587) said Child starts > Child (19587) said managed to mmap 536870912 bytes of 536870912 New description: Here is the trace {{{ # /opt/startvarnish.sh;svcadm enable nginx-master storage_file: filename: /sessions/varnish_cache.bin size 512 MB. Message from C-compiler: "./vcl.hndxcCNb.c", line 355: warning: initializer will be sign-extended: -1 Using old SHMFILE child (16367) Started Child (16367) said Closed fds: 3 5 6 9 10 12 13 Child (16367) said Child starts Child (16367) said managed to mmap 536870912 bytes of 536870912 Child (16367) died signal=6 Child (16367) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 149: Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) == 0) not true. errno = 9 (Bad file number) thread = (cache-worker) Backtrace: 42e3c5: /opt/extra/sbin/varnishd'pan_ic+0x95 [0x42e3c5] 10: [0x10] sp = b95018 { fd = 16, id = 16, xid = 0, client = 78.155.225.100:50256, step = STP_FIRST, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = b95088 { id = "sess", {s,f,r,e} = {b95da8,+21,0,+65536}, }, http[req] = { ws = b95088[sess] "", "/question/id/4786", "HTTP/1.1", "Accept: */*", "Host: fabulously40.com", "If-Modified-Since: Tue, 12 Jan 2010 07:15:17 GMT", "User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm)", "Connection: Keep-Alive", "Cache-Control: no-cache", "Pragma: no-cache", "X-Forwarded-For: 65.55.106.163", "Accept-Encoding: gzip", }, worker = fffffd7fc7889d20 { ws = fffffd7fc7889e68 { id = "wrk", {s,f,r,e} = {fffffd7fc7877cb0,fffffd7fc7877cb0,0,+65536}, }, }, }, Child cleanup complete child (19587) Started Child (19587) said Closed fds: 3 5 6 9 10 12 13 Child (19587) said Child starts Child (19587) said managed to mmap 536870912 bytes of 536870912 }}} Comment (by phk): Edit trace in. See also #615, #588 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 14:47:30 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 14:47:30 -0000 Subject: [Varnish] #628: Least privileges for Varnish: no privileges In-Reply-To: <051.14a25568fa21b7191fc98b94f24cadad@projects.linpro.no> References: <051.14a25568fa21b7191fc98b94f24cadad@projects.linpro.no> Message-ID: <060.747b675b76ece0dca659258161cd28b9@projects.linpro.no> #628: Least privileges for Varnish: no privileges -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4482]) Drop all privileges in worker children on Solaris Fixes #628 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 15:01:29 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 15:01:29 -0000 Subject: [Varnish] #627: Missing ticket change notifications In-Reply-To: <051.2b19f9d32b9d21489dda63774a5fbf3c@projects.linpro.no> References: <051.2b19f9d32b9d21489dda63774a5fbf3c@projects.linpro.no> Message-ID: <060.1cdddc85abe6eb0b531b9beaecc63677@projects.linpro.no> #627: Missing ticket change notifications -------------------------+-------------------------------------------------- Reporter: slink | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I have fixed this now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 15:01:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 15:01:52 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.36ae04c0d57f7f62dfdec983413ce633@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kristian): Ok, after a hurdle of tinkering, I've discovered what's happening here. It's a series of corner-cases comming together, so stick with it: First of all, the backend_http11 option doesn't do anything in 2.0.6, and has since been removed. Varnish will behave as if it's set to 'on'. However, in the case of pass or pipe, varnish will use the protocol- and request-field the client sent, so this is how Varnish suddenly sent HTTP/1.0, even though you told it not to, and it doesn't do it by default. Next is your backend: It replies with a HTTP/1.1 protocol header to a HTTP/1.0 request - this itself is fairly common - but it seems to be in a limbo between HTTP/1.0 and HTTP/1.1: It doesn't set "Connection: close", but it is obviously not in keep-alive mode. Looking at nginx - which is what I had available - it also replies with HTTP/1.1 to HTTP/1.0-requests, but it sets "Connection: close". There is some confusion in this code, so I'll continue to work on it, but your backend is definitely not handling this right either. It is probably best for Varnish to assume that a connection will be closed if it sends a HTTP/1.0 request, but at the same time, it's not obvious.... Somewhat off-topic (I'm a curious guy): If you send a HTTP/1.1 request to your backend without a Connection:-header, how does it respond? Does it do keep-alive, or does it close? Does it supply a Connection: header? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 15:36:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 15:36:53 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.9ce7f3327e5df13648e32cb7f481824e@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by janne): Yeah, that backend HTTP version mismatch was the first thing I noticed when started to debug the problem. The backend is running Jetty 6.1.x, and seems to always act as the client requests even if it fails to return the proper response string. Requests with HTTP/1.1 are served as keep-alive, and without Connection header. Requests with HTTP/1.1 + Connection:close are returned with Connection- header and closed. According the HTTP/1.1 spec (8.1.4) connections may be closed at any point, and the client should just take an another connection and retry. If Varnish would handle this properly, there would not be any problem with Jetty behaving badly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 15:55:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 15:55:21 -0000 Subject: [Varnish] #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> References: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> Message-ID: <068.f3c9144d945b6c521e05f65a09a65813@projects.linpro.no> #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 ---------------------------+------------------------------------------------ Reporter: erik.berglund | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by tfheen): (repeating my earlier question as I believe the submitter did not get the mail due to silly mail setup in trac.) Given this suddenly appeared, did it go away too or are you still seeing it? Can you reproduce it with 2.0.6? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 16:43:14 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 16:43:14 -0000 Subject: [Varnish] #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> References: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> Message-ID: <068.0c308aa9119318f522ecb9a7ccd9acaf@projects.linpro.no> #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 ---------------------------+------------------------------------------------ Reporter: erik.berglund | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by phk): Please also try to set "waiter" parameter set to "poll", so see if that shows the same problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 16:44:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 16:44:05 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c In-Reply-To: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> References: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> Message-ID: <062.eff64158737b59f5b5e90aa0a120479a@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by phk): Please report of setting parameter "waiter" to "poll" changes things. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 16:44:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 16:44:57 -0000 Subject: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> References: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> Message-ID: <062.5d0a75139fc8ecb183811b3589e6b955@projects.linpro.no> #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 ----------------------+----------------------------------------------------- Reporter: jhayter | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Please try to set parameter "waiter" to "poll" and report if that makes a difference. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 17:03:10 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 17:03:10 -0000 Subject: [Varnish] #627: Missing ticket change notifications In-Reply-To: <051.2b19f9d32b9d21489dda63774a5fbf3c@projects.linpro.no> References: <051.2b19f9d32b9d21489dda63774a5fbf3c@projects.linpro.no> Message-ID: <060.106cf288f260d11e60cfe856efc4895b@projects.linpro.no> #627: Missing ticket change notifications -------------------------+-------------------------------------------------- Reporter: slink | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Comment (by slink): Thank you ! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 21:48:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 21:48:00 -0000 Subject: [Varnish] #630: helpers to convert varnish time into struct timespec/timeval In-Reply-To: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> References: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> Message-ID: <060.e74b9886d1b9513bc64e3275eae41143@projects.linpro.no> #630: helpers to convert varnish time into struct timespec/timeval -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Sorry, but this is way more code than I'm prepared to introduce for something that can be done perfectly well with a couple of lines of C-code: {{{ struct timeval timeout; timeout.tv_sec = (int)floor(seconds); timeout.tv_usec = (int)(1e6 * (seconds - timeout.tv_sec)); }}} (From lib/libvarnish/tcp.c) Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 22:54:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 22:54:06 -0000 Subject: [Varnish] #631: oc->objhead pointer trouble Message-ID: <049.b5662a49875a5cedd6ab6f7c71b5e612@projects.linpro.no> #631: oc->objhead pointer trouble ----------------------+----------------------------------------------------- Reporter: phk | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Find out if r4491+r4492 apply to 2.x and patch if so. I'm not sure if the failure to set oc->objhead corrected in r4491 is present in v2 or not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 25 22:57:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 Jan 2010 22:57:24 -0000 Subject: [Varnish] #548: Sig 11 crash in trunk 4199 In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> Message-ID: <061.97e8ec52442342146de294f90cff37e7@projects.linpro.no> #548: Sig 11 crash in trunk 4199 ---------------------------------------------+------------------------------ Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: sig 11 segmentation fault trunk | ---------------------------------------------+------------------------------ Comment (by phk): Can you try a post r4492 trunk ? I found a consistenty problem with objcores not pointing back to their objheads which could possibly explain this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 26 20:52:44 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 26 Jan 2010 20:52:44 -0000 Subject: [Varnish] #632: Varnish fails to accept connections in deamon mode. Message-ID: <053.46f7b7bb7c412713a926a10d2a281828@projects.linpro.no> #632: Varnish fails to accept connections in deamon mode. ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ OS: opensolaris / snv98 - (Higher revisions of opensolaris also affected) Varnish can only be run with the varnishd -F flag. If you run varnish in deamon mode it fails to accept connections from telnet and web requests. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 26 20:56:15 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 26 Jan 2010 20:56:15 -0000 Subject: [Varnish] #633: varnishncsa segfaults Message-ID: <053.3fe84c47e21693296422d51486362696@projects.linpro.no> #633: varnishncsa segfaults ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ OS: opensolaris snv98 varnishncsa segfaults after a few seconds of use. I have a suspicion it could potentially be tied to bad requests, since the uptime varies from run to run. Here is some sample output; The sample below has run less than 3 or 5 seconds before it segfaulted. http://pastie.org/795632.txt -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 27 13:00:56 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 27 Jan 2010 13:00:56 -0000 Subject: [Varnish] #631: oc->objhead pointer trouble In-Reply-To: <049.b5662a49875a5cedd6ab6f7c71b5e612@projects.linpro.no> References: <049.b5662a49875a5cedd6ab6f7c71b5e612@projects.linpro.no> Message-ID: <058.438a1cdd79783cad3ef375bf3001243b@projects.linpro.no> #631: oc->objhead pointer trouble ----------------------+----------------------------------------------------- Reporter: phk | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: Given we don't have object cores at all in 2.0, I'm just closing this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 04:09:48 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 04:09:48 -0000 Subject: [Varnish] #634: Race between HSH_Lookup and EXP_NukeOne Message-ID: <051.9ed4e0cd975a3a4a4492f75bc9da6753@projects.linpro.no> #634: Race between HSH_Lookup and EXP_NukeOne ----------------------+----------------------------------------------------- Reporter: mpage | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- There is a race that we are encountering frequently when running varnish trunk with the file store. The race occurs between HSH_Lookup() and EXP_NukeOne(). Here is a brief narrative of what happens: Thread T1 is executing HSH_Lookup(). It finds an objcore oc it likes but is descheduled prior to line 406. Another thread T2 is scheduled and executes EXP_NukeOne(). It finds the objcore oc about to be returned by HSH_Lookup() at the head of the LRU with an object of refcnt 1 (since T1 was descheduled before it could increment the refcnt on oc->obj). It then calls HSH_Deref(sp->wrk, &(oc->obj)); When T1 is rescheduled and wakes up oc->obj is now NULL (because of T2) and the assert on 408 (of cache_hash.c) is triggered. I'm not sure why EXP_NukeOne needs to call HSH_Deref with a pointer to oc->obj. The objcore oc is what is stored in the objhead, so nulling oc->obj seems like a bad idea. I've attached a diff with a possible fix. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 11:08:15 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 11:08:15 -0000 Subject: [Varnish] #635: Varnish restarting children on every request Message-ID: <053.4acf005cf40c1bcc90aa437d0404776d@projects.linpro.no> #635: Varnish restarting children on every request ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ OS: opensolaris / SNV98 Recent trunk build restarts children on assert: Child (27101) Panic message: Assert error in vbe_TryConnect(), cache_backend.c line 129: http://pastie.org/798585.txt -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 11:14:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 11:14:52 -0000 Subject: [Varnish] #635: Varnish restarting children on every request In-Reply-To: <053.4acf005cf40c1bcc90aa437d0404776d@projects.linpro.no> References: <053.4acf005cf40c1bcc90aa437d0404776d@projects.linpro.no> Message-ID: <062.4ef94f159f9bb9691c2db9b5c3661d0d@projects.linpro.no> #635: Varnish restarting children on every request ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by victori): {{{ # ./bin/varnishd/varnishd -f /opt/extra/etc/varnish/default.vcl -a 0.0.0.0:82 -p listen_depth=8192 -p thread_pool_max=2000 -p thread_pool_min=50 -p thread_pools=4 -p cc_command='cc -Kpic -G -m64 -o %o %s' -s file,/sessions/vtest/varnish_cache.bin,512M -p sess_timeout=10s -p session_linger=120ms -p connect_timeout=0s -p lru_interval=20s -p thread_pool_add_delay=2ms -p waiter=poll -p cli_timeout=25s -p sess_workspace=65536 -T 0.0.0.0:8087 -n /sessions/vtest -u webservd -F storage_file: filename: /sessions/vtest/varnish_cache.bin size 512 MB. Message from C-compiler: "./vcl.ORk8t3RP.c", line 355: warning: initializer will be sign-extended: -1 Creating new SHMFILE child (27101) Started Child (27101) said Closed fds: 3 5 6 9 10 12 13 Child (27101) said Child starts Child (27101) said managed to mmap 536870912 bytes of 536870912 Child (27101) died signal=6 Child (27101) Panic message: Assert error in vbe_TryConnect(), cache_backend.c line 129: Condition(tmod > 0.0) not true. errno = 9 (Bad file number) thread = (cache-worker) ident = -sfile,-hclassic,poll Backtrace: 42eca3: /software/work/varnish- cache/bin/varnishd/.libs/varnishd'pan_ic+0xc3 [0x42eca3] sp = 7e6018 { fd = 6, id = 6, xid = 494596955, client = 75.80.141.237:52623, step = STP_FETCH, handling = fetch, restarts = 0, esis = 0 ws = 7e6088 { id = "sess", {s,f,r,e} = {7e6d90,+219,0,+65536}, }, http[req] = { ws = 7e6088[sess] "GET", "/", "HTTP/1.1", "User-Agent: curl/7.19.7 (i386-apple-darwin10.2.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3", "Host: fabulously40.com:82", "Accept: */*", "X-Forwarded-For: 75.80.141.237", }, worker = fffffd7fcca61d10 { ws = fffffd7fcca61e58 { id = "wrk", {s,f,r,e} = {fffffd7fcca4fca0,+21,0,+65536}, }, http[bereq] = { ws = fffffd7fcca61e58[wrk] "GET", "/", "HTTP/1.1", "User-Agent: curl/7.19.7 (i386-apple-darwin10.2.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3", "Host: fabulously40.com:82", "Accept: */*", "X-Forwarded-For: 75.80.141.237", "X-Varnish: 494596955", }, http[beresp] = { ws = fffffd7fcca61e58[wrk] }, }, vcl = { srcname = { "input", "Default", }, }, }, Child cleanup complete child (27107) Started Child (27107) said Closed fds: 3 5 6 9 10 12 13 Child (27107) said Child starts Child (27107) said managed to mmap 536870912 bytes of 536870912 ^CManager got SIGINT Stopping Child }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 11:21:26 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 11:21:26 -0000 Subject: [Varnish] #635: Varnish restarting children on every request In-Reply-To: <053.4acf005cf40c1bcc90aa437d0404776d@projects.linpro.no> References: <053.4acf005cf40c1bcc90aa437d0404776d@projects.linpro.no> Message-ID: <062.cf6e497caa01c1d59fa5f02ab99cc3aa@projects.linpro.no> #635: Varnish restarting children on every request ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4508]) Allow backend timeouts to be zero. Fixes #635 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 12:40:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 12:40:49 -0000 Subject: [Varnish] #636: Varnish crash in trunk 4492 Message-ID: <052.b3b04170667d1339a9de111bd59e3095@projects.linpro.no> #636: Varnish crash in trunk 4492 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am running Varnish trunk 4492 in FreeBSD/amd64 7.2-RELEASE. I get this crash: Jan 28 01:00:34 cache12 kernel: pid 18726 (varnishd), uid 0: exited on signal 11 (core dumped) Backtrace: {{{ (gdb) bt #0 0x00000008009d235f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 #1 0x00000008009d2394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 #2 0x0000000000422438 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000422815 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:332 #4 0x000000000041d0d2 in HSH_Lookup (sp=0x80d557008, poh=0x7fffa2d11640) at cache_hash.c:408 #5 0x0000000000412374 in cnt_lookup (sp=0x80d557008) at cache_center.c:784 #6 0x00000000004147e6 in CNT_Session (sp=0x80d557008) at steps.h:38 #7 0x0000000000424781 in wrk_do_cnt_sess (w=0x7fffa2d18d30, priv=Variable "priv" is not available. ) at cache_pool.c:294 #8 0x0000000000423a7d in wrk_thread_real (qp=0x80110f790, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:183 #9 0x0000000800bf44d1 in pthread_getprio () from /lib/libthr.so.3 #10 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffa2d19000 (gdb) frame 4 #4 0x000000000041d0d2 in HSH_Lookup (sp=0x80d557008, poh=0x7fffa2d11640) at cache_hash.c:408 408 CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC); (gdb) print *sp $1 = {magic = 741317722, fd = 569, id = 569, xid = 1860907167, restarts = 0, esis = 0, disable_esi = 0, wrk = 0x7fffa2d18d30, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x80d557288, mysockaddr = 0x80d557308, mylsock = 0x80111c2b0, addr = 0x80d557c98 "85.167.107.115", port = 0x80d557ca7 "6784", doclose = 0x0, http = 0x80d557388, http0 = 0x80d557810, ws = {{magic = 905626964, id = 0x4478fd "sess", s = 0x80d557c98 "85.167.107.115", f = 0x80d55802c "64622200.1264622200.1; __utmb=165597608.3.10.1264622200; __utmc=165597608; __utmz=165597608.1264622200.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __lt=13ebbc2518cb1b83f110aa2da87b96057d8406a1d"..., r = 0x0, e = 0x80d55bc98 '?' ..., overflow = 0}}, ws_ses = 0x80d557cac "GET", ws_req = 0x80d558015 "Accept-Encoding: gzip", digest = "M\237?x?DHt:\026\211 w\0163?A?k\221?Ib?\220?\2143???h", htc = {{ magic = 1041886673, fd = 569, ws = 0x80d557078, rxbuf = { b = 0x80d557cac "GET", e = 0x80d558015 "Accept-Encoding: gzip"}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1264622324.7004681, t_req = 1264622324.7194371, t_resp = nan(0x8000000000000), t_end = 1264622324.7004681, connect_timeout = 0.40000000000000002, first_byte_timeout = 60, between_bytes_timeout = 60, grace = 300, step = STP_LOOKUP, cur_method = 0, handling = 3, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 200, err_reason = 0x0, list = { vtqe_next = 0x80ef52008, vtqe_prev = 0x550130}, director = 0x80bbebec8, vbe = 0x0, obj = 0x0, objcore = 0x0, objhead = 0x0, vcl = 0x80bbf20e8, mem = 0x80d557000, workreq = {list = {vtqe_next = 0x13f69de1b8, vtqe_prev = 0x80110f530}, func = 0x4246c0 , priv = 0x80d557008}, acct = {first = 1264622324.7004681, sess = 10174, req = 36504, pipe = 0, pass = 0, fetch = 1395, hdrbytes = 12131383, bodybytes = 258031616}, acct_req = {first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}} (gdb) print *oc $2 = {magic = 1294996226, obj = 0x0, objhead = 0x145e38aac0, timer_when = 1265129819.9851763, flags = 0, timer_idx = 0, list = { vtqe_next = 0x0, vtqe_prev = 0x145e38aad8}, lru_list = { vle_next = 0xe507d2ba0, vle_prev = 0x80112c688}, ban_list = { vtqe_next = 0x1460970ac0, vtqe_prev = 0x1450e1ba68}, smp_seg = 0x0, ban = 0x0} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 28 14:14:14 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 Jan 2010 14:14:14 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page Message-ID: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Type: task Status: new | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Keywords: svn authentication | --------------------------------+------------------------------------------- When I tried to checkout the source code via svn, it asked me for a password. There is no authentication requirements mentioned in the "Using Subversion" Wiki page and I believe it was not required before. Please check it out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 29 07:58:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 29 Jan 2010 07:58:01 -0000 Subject: [Varnish] #638: Assert error in VRT_ESI Message-ID: <053.1a058ad76c409bcb807363e643479c33@projects.linpro.no> #638: Assert error in VRT_ESI ----------------------+----------------------------------------------------- Reporter: bertjan | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: ----------------------+----------------------------------------------------- I'm trying to experiment with ESI but even the simplest setup crashes. My setup is FreeBSD 7.2, apache 2.2.14, varnish 2.0.6 from ports. I have a simple page: index.html {{{ }}} include.html {{{

Test

}}} When I open it through Varnish the connection is reset. Requesting include.html directly is no problem. My default.vcl: {{{ backend dev { .host = "192.168.2.10"; .port = "80"; } sub vcl_recv { if (req.url ~ "\.(js|css|gif|jpg|png|ico|txt|swf|mp3)(\?.*)?$") { unset req.http.cookie; } if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } if (req.url == "/index.html") { esi; } } }}} What happens: {{{ # varnishd -d -d -f /usr/local/etc/varnish/default.vcl -a 192.168.2.15:80 storage_file: filename: ./varnish.2adBfM (unlinked) size 1346836 MB. Using old SHMFILE Debugging mode, enter "start" to start child start child (57004) Started 200 0 Child (57004) said Closed fds: 4 8 9 11 12 Child (57004) said Child starts Child (57004) said managed to mmap 1412260429824 bytes of 1412260429824 Child (57004) said Ready Child (57004) died signal=6 Child (57004) Panic message: Assert error in VRT_ESI(), cache_vrt_esi.c line 658: Condition((sp->obj) != NULL) not true. thread = (cache-worker) sp = 0x806572008 { fd = 9, id = 9, xid = 678967366, client = 192.168.2.24:57004, step = STP_RECV, handling = error, restarts = 0, esis = 0 ws = 0x806572080 { id = "sess", {s,f,r,e} = {0x806572810,+523,0x0,+16384}, }, http[req] = { ws = 0x806572080[sess] "GET", "/index.html", "HTTP/1.1", "Host: dutchcowboys.bert-jan.bug", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Connection: keep-alive", "Cookie: __unam=c4094e2-124e7db5c01-3e94d73-153; PHPSESSID=36e043ec7c9710545523e4e04c538734", "Accept-Encoding: gzip", }, worker = 0x7ffffdff0a70 vcl = { srcname = { "input", "Default", }, }, }, Child cleanup complete child (57005) Started Child (57005) said Closed fds: 4 8 9 11 12 Child (57005) said Child starts Child (57005) said managed to mmap 1412260429824 bytes of 1412260429824 Child (57005) said Ready }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 29 08:37:33 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 29 Jan 2010 08:37:33 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page In-Reply-To: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> References: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> Message-ID: <065.761735c5d98215645e2dcd95aab42a20@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Owner: Type: task | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: svn authentication | --------------------------------+------------------------------------------- Comment (by tfheen): Exactly which command line did you use to check out? I am unable to reproduce what you're describing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 29 14:41:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 29 Jan 2010 14:41:24 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.6ebf3b4f0de394582ac6c9cecd2915a9@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Comment (by malte): Jan 25 10:54:58 RESCUE varnishd[23193]: Child (16886) said Closed fds: 3 4 5 9 10 12 13 Jan 25 10:54:58 RESCUE varnishd[23193]: Child (16886) said Child starts Jan 25 10:54:58 RESCUE varnishd[23193]: Child (16886) said Ready Jan 25 20:42:32 RESCUE varnishd[23193]: Child (16886) died signal=6 Jan 25 20:42:32 RESCUE varnishd[23193]: child (3719) Started Jan 25 20:42:32 RESCUE varnishd[23193]: Child (3719) said Closed fds: 3 4 5 9 10 12 13 Jan 25 20:42:32 RESCUE varnishd[23193]: Child (3719) said Child starts Jan 25 20:42:32 RESCUE varnishd[23193]: Child (3719) said Ready Jan 26 09:31:25 RESCUE varnishd[23193]: Child (3719) died signal=6 Jan 26 09:31:25 RESCUE varnishd[23193]: child (28911) Started Jan 26 09:31:25 RESCUE varnishd[23193]: Child (28911) said Closed fds: 3 4 5 9 10 12 13 Jan 26 09:31:25 RESCUE varnishd[23193]: Child (28911) said Child starts Jan 26 09:31:25 RESCUE varnishd[23193]: Child (28911) said Ready Jan 26 14:21:26 RESCUE varnishd[23193]: Child (28911) died signal=6 Jan 26 14:21:26 RESCUE varnishd[23193]: child (13806) Started Jan 26 14:21:26 RESCUE varnishd[23193]: Child (13806) said Closed fds: 3 4 5 9 10 12 13 Jan 26 14:21:26 RESCUE varnishd[23193]: Child (13806) said Child starts Jan 26 14:21:26 RESCUE varnishd[23193]: Child (13806) said Ready Jan 27 13:56:21 RESCUE varnishd[23193]: Child (13806) died signal=6 Jan 27 13:56:21 RESCUE varnishd[23193]: child (16155) Started Jan 27 13:56:21 RESCUE varnishd[23193]: Child (16155) said Closed fds: 3 4 5 9 10 12 13 Jan 27 13:56:21 RESCUE varnishd[23193]: Child (16155) said Child starts Jan 27 13:56:21 RESCUE varnishd[23193]: Child (16155) said Ready Jan 27 17:54:22 RESCUE varnishd[23193]: Child (16155) died signal=6 Jan 27 17:54:22 RESCUE varnishd[23193]: child (4576) Started Jan 27 17:54:22 RESCUE varnishd[23193]: Child (4576) said Closed fds: 3 4 5 9 10 12 13 Jan 27 17:54:22 RESCUE varnishd[23193]: Child (4576) said Child starts Jan 27 17:54:22 RESCUE varnishd[23193]: Child (4576) said Ready Jan 27 19:11:58 RESCUE varnishd[23193]: Child (4576) died signal=6 Jan 27 19:11:58 RESCUE varnishd[23193]: child (18905) Started Jan 27 19:11:58 RESCUE varnishd[23193]: Child (18905) said Closed fds: 3 4 5 9 10 12 13 Jan 27 19:11:58 RESCUE varnishd[23193]: Child (18905) said Child starts Jan 27 19:11:58 RESCUE varnishd[23193]: Child (18905) said Ready For me it happens regularly... lb1:/# varnishd -V varnishd (varnish-2.0.6) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS lb1:/# uname -a Linux lb1 2.6.30-bpo.2-686-bigmem #1 SMP Fri Dec 11 20:33:34 UTC 2009 i686 GNU/Linux lb1:/# our vcl includes nothing really special. ( 2 Backendpools & switching accordingly + setting file specific cache control headers ) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 29 15:58:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 29 Jan 2010 15:58:19 -0000 Subject: [Varnish] #639: Assert on writing to CLI when child process dies Message-ID: <049.774ff00582bdc8c382ad6786fed4376c@projects.linpro.no> #639: Assert on writing to CLI when child process dies ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: 2.0.6 CLI assert ----------------------+----------------------------------------------------- varnishd 2.0.6 on Debian Lenny amd64. When a child dies: Jan 29 10:51:10 webcache4 varnishd[24741]: Child (24742) not responding to ping, killing it. Jan 29 10:51:12 webcache4 varnishd[24741]: Child (24742) not responding to ping, killing it. and there's a CLI command being written to the child, an xxxassert() is raised: #3 0x000000000042ef64 in mgt_cli_vlu (priv=0x7fb112813c00, p=0x7fb1128d3000 "debug.health") at mgt_cli.c:270 270 xxxassert(i == strlen(p)); The master process should handle the unfinished write(), rather than aborting. As a dirty interim fix, it *should* be OK to ignore the unfinished write, like in the attached patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 30 01:53:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 Jan 2010 01:53:27 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.573802411a8c96ac721f933837bec2f4@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Comment (by chawl): Similar on: Centos 5.4 x86_64, Apache/2.2.3 (no keepalive) backend, 2.0.6 compiled from source(forge). {{{ Jan 29 18:22:45 ns1 varnishd[11028]: Child (11029) not responding to ping, killing it. Jan 29 18:23:18 ns1 last message repeated 7 times Jan 29 18:23:18 ns1 varnishd[11028]: Child (11029) died signal=3 Jan 29 18:23:18 ns1 varnishd[11028]: child (6119) Started Jan 29 18:23:18 ns1 varnishd[11028]: Child (6119) said Closed fds: 4 5 6 10 11 13 14 Jan 29 18:23:18 ns1 varnishd[11028]: Child (6119) said Child starts Jan 29 18:23:18 ns1 varnishd[11028]: Child (6119) said managed to mmap 10737418240 bytes of 10737418240 Jan 29 18:23:18 ns1 varnishd[11028]: Child (6119) said Ready }}} no core dumps, and my simple vcl {{{ backend default { .host = "127.0.0.1"; .port = "8080"; .first_byte_timeout = 300s; .between_bytes_timeout = 120s; .max_connections = 35; } sub vcl_recv { set req.grace = 30s; if (req.url ~ "cron.php") { return (pass); } if (req.url ~ ".*/server-status$") { error 403 "Hmmm..."; } if (req.url ~ "(/wp-login.php|/munin/localhost/)") { return (pipe); } if (req.request == "GET" && req.url ~ "(\.[gG][iI][fF])|(\.[jJ][pP][eE]?[gG])|(\.[pP][nN][gG])|(\.[fF][lL][vV])|(\.[mM][pP]4)|(\.[zZ][iI][pP])|(\.[rR][aA][rR])|(\.[cC][sS][sS])|(\.[sS][wW][fF])|(\.[wW][mM][vV])|(\.[sS][wW][fF])|(\.[jJ][sS])$") { unset req.http.cookie; lookup; } } sub vcl_hash { if (req.http.Cookie) { set req.hash += req.http.Cookie; } } sub vcl_hit { if (!obj.cacheable) { pass; } if (req.url ~ "__REFRESH__$") { set obj.ttl = 0s; return (restart); } deliver; } sub vcl_fetch { set obj.grace = 30s; if (req.request == "GET" && req.url ~ "(\.[gG][iI][fF])|(\.[jJ][pP][eE]?[gG])|(\.[pP][nN][gG])|(\.[fF][lL][vV])|(\.[mM][pP]4)|(\.[zZ][iI][pP])|(\.[rR][aA][rR])|(\.[cC][sS][sS])|(\.[sS][wW][fF])|(\.[wW][mM][vV])|(\.[sS][wW][fF])|(\.[jJ][sS])$") { unset obj.http.Set-Cookie; set obj.cacheable = true; } if (obj.cacheable) { unset obj.http.expires; set obj.http.cache-control = "max-age = 900"; set obj.ttl = 1w; set obj.http.magicmarker = "1"; deliver; } } sub vcl_deliver { if (resp.http.magicmarker) { unset resp.http.magicmarker; set resp.http.age = "0"; } } }}} Crashes once or twice a day and have no correlation with loads, crons, backend restart etc. I suspect "set obj.ttl = 0s;return (restart);" without hard evidence anyway, but a crash occurred once just then I called this line to refresh an object in the cache. May be a coincidence, but a daily crash is hard to be coincided with such a rare call. What's next? Same crash was happened many times with 2.0.5 which is installed from rpmforge repo, and that's why I attempted to compile a fresh 2.0.6 from source. Tx. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 30 02:16:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 Jan 2010 02:16:32 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.ed07bc9c1dc582504d19d2e2edfb9d7e@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Comment (by chawl): And my sysconfig/varnish. {{{ NFILES=131072 MEMLOCK=82000 DAEMON_OPTS="-a :80 \ -f /etc/varnish/default.vcl \ = -T 127.0.0.1:6082 \ -t 120 \ -w 1,1000,120 \ -u varnish -g varnish \ -s /var/lib/varnish/varnish_storage.bin \ -p thread_pools=4 \ -h classic,50021 \ -p thread_pool_add_delay=10 \ -p listen_depth=2048 \ -p lru_interval=5" }}} and varnishadm -T localhost:6082 param.show {{{ accept_fd_holdoff 50 [ms] acceptor default (epoll, poll) auto_restart on [bool] backend_http11 on [bool] between_bytes_timeout 60.000000 [s] cache_vbe_conns off [bool] cc_command "exec cc -fpic -shared -Wl,-x -o %o %s" cli_buffer 8192 [bytes] cli_timeout 5 [seconds] client_http11 off [bool] clock_skew 10 [s] connect_timeout 0.400000 [s] default_grace 10 default_ttl 120 [seconds] diag_bitmap 0x0 [bitmap] err_ttl 0 [seconds] esi_syntax 0 [bitmap] fetch_chunksize 128 [kilobytes] first_byte_timeout 60.000000 [s] group varnish (103) listen_address :80 listen_depth 2048 [connections] log_hashstring off [bool] log_local_address off [bool] lru_interval 5 [seconds] max_esi_includes 5 [includes] max_restarts 4 [restarts] obj_workspace 8192 [bytes] overflow_max 100 [%] ping_interval 3 [seconds] pipe_timeout 60 [seconds] prefer_ipv6 off [bool] purge_dups on [bool] purge_hash on [bool] rush_exponent 3 [requests per request] send_timeout 600 [seconds] sess_timeout 5 [seconds] sess_workspace 16384 [bytes] session_linger 50 [ms] session_max 100000 [sessions] shm_reclen 255 [bytes] shm_workspace 8192 [bytes] srcaddr_hash 1049 [buckets] srcaddr_ttl 0 [seconds] thread_pool_add_delay 10 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_fail_delay 200 [milliseconds] thread_pool_max 1000 [threads] thread_pool_min 1 [threads] thread_pool_purge_delay 1000 [milliseconds] thread_pool_stack unlimited [bytes] thread_pool_timeout 120 [seconds] thread_pools 4 [pools] user varnish (101) vcl_trace off [bool] }}} and sorry for double post. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 30 02:37:11 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 Jan 2010 02:37:11 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page In-Reply-To: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> References: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> Message-ID: <065.87531ff23aac0f56753ce78eee284d97@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Owner: Type: task | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: svn authentication | --------------------------------+------------------------------------------- Comment (by gladandong): I have tried to checkout using the svn command {{{ wfrank at wfrank-thinkpad:~$ svn co svn+ssh://projects.linpro.no/svn/varnish/trunk varnish Password: }}} and Eclipse with Subversive plugin. Both asked me for the password. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 30 03:32:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 Jan 2010 03:32:16 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page In-Reply-To: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> References: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> Message-ID: <065.f978bbde859c592bd9d6596ad2911cd2@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Owner: Type: task | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: svn authentication | --------------------------------+------------------------------------------- Comment (by kbvarnish): Do you have read-write privileges to the tree? Do you understand what svn+ssh implies? If not, review http://varnish-cache.org/wiki/Repository use the right URL: svn co http://varnish-cache.org/svn/trunk Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 30 09:17:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 Jan 2010 09:17:37 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page In-Reply-To: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> References: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> Message-ID: <065.0f03d0b2015f082e038dd6d7afa9fbc2@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Owner: Type: task | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: svn authentication | --------------------------------+------------------------------------------- Comment (by gladandong): Thanks, I think I was following the wrong URL... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 31 03:45:54 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 31 Jan 2010 03:45:54 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.a36d335280452644f4668c68e3b9fe26@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Comment (by chawl): Hmm... ignore "sub vcl_hit" part in my previous vcl. Actually it is logically erroneous and I omitted it, but still getting crashes. -- Ticket URL: Varnish The Varnish HTTP Accelerator