From varnish-bugs at projects.linpro.no Tue Jul 7 12:19:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Jul 2009 12:19:13 -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.d1ae12f88ab8e2b6080b3b19b31a9e71@projects.linpro.no> #503: Assertion failure when trying to fetch a large object --------------------+------------------------------------------------------- Reporter: Sesse | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by witsch): another update: i can reliably reproduce the issue with files larger then a certain value. the only response headers sent are {{{ Date: Tue, 07 Jul 2009 08:04:00 GMT Last-Modified: Mon, 22 Jun 2009 08:54:11 GMT Content-Length: 687948038 Content-Type: application/x-tar Content-Disposition: attachment; filename=foo.tar }}} apparently varnish runs into the above described problem of not being able to allocate a "stovedore" in the middle of fetching the object from the backend and then simply return a successfull (i.e. 200), but otherwise completely empty response... ps: this is using 2.0.4 with a storage size of 16gb and the threshold size doesn't change when adding more storage -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 8 11:44:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Jul 2009 11:44:44 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 Message-ID: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 -------------------+-------------------------------------------------------- Reporter: are | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Missing http headers when returning a 304-code. According to RFC 2616, pt 10.3.5: "The response MUST include the following header fields:" ... "ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request" The http headers are wiped then creating a 304, including etag. Our current problem is that we set Cache-Control with max-age, public, post-check and pre-check, all to make IE happy, but when the client refreshes the page and get a 304 the cache-control is missing and that makes IE forget the original caching orders. -- Ticket URL: Varnish The Varnish HTTP Accelerator From sahil.cooner at gmx.com Mon Jul 13 02:38:10 2009 From: sahil.cooner at gmx.com (Sahil Cooner) Date: Sun, 12 Jul 2009 21:38:10 -0500 Subject: bug with nuking objects based on TTL and obj reference Message-ID: <4A5A9E12.20909@gmx.com> I'm using redhat with version 2.0.3 of varnish. Discovered some race condition issues and had assertions and segfaults thrown with stevedore. stevedore.c:71, where it's checking the st struct for NULL and it is null. here is the patch for 2.0.3 that has resolved this issue for us, this issues also exists in the 2.0.4 stable release of the software. This is a nasty patch, but makes the software work. I know there's a deeper issue here, and I'll try and sift through more code and try and determine what the root cause is, but it has to do with the TTL and obj reference counting not allowing objects to be cleared out. There also appears to concurrency issues with content. Thanks, Sahil R Cooner -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stevedore.c.diff URL: From varnish-bugs at projects.linpro.no Wed Jul 15 22:02:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 15 Jul 2009 22:02:04 -0000 Subject: [Varnish] #522: Odd TCP reset problems with trunk 4080 In-Reply-To: <052.9e4f22a7767a39fc57cd165effa2904d@projects.linpro.no> References: <052.9e4f22a7767a39fc57cd165effa2904d@projects.linpro.no> Message-ID: <061.e6a2bd92b97fed63bfcc635d4b20247a@projects.linpro.no> #522: Odd TCP reset problems with trunk 4080 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Reverting 4047 also seems to be necessary. Otherwise Varnish gets thread pileups/hickups. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 17 08:57:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Jul 2009 08:57:14 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.1b554f470764207ff06ce67c76659c91@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): phk: your fix in r4087 apparently did the trick! Even though you can't see how we could get into that situation, we haven't experienced any more instabilities on this hosting! I consider this issue SOLVED, the ticket can be closed. Thank you very much for your help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 19 05:05:52 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 19 Jul 2009 05:05:52 -0000 Subject: [Varnish] #532: reference to uninitialized variable Message-ID: <048.241b8e67532a5a03a594ed63e911d713@projects.linpro.no> #532: reference to uninitialized variable ----------------------+----------------------------------------------------- Reporter: ow | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- An uninitialized variable o is being accessed as a result of some previous code restructuring work. varnishd/cache_expire.c 4100, function EXP_NukeOne, Line 301 WSL(sp->wrk, SLT_ExpKill, 0, "%u LRU", o->xid); -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 19 16:40:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 19 Jul 2009 16:40:42 -0000 Subject: [Varnish] #532: reference to uninitialized variable In-Reply-To: <048.241b8e67532a5a03a594ed63e911d713@projects.linpro.no> References: <048.241b8e67532a5a03a594ed63e911d713@projects.linpro.no> Message-ID: <057.caee31ac0081b6f1a5022926697ad318@projects.linpro.no> #532: reference to uninitialized variable ----------------------+----------------------------------------------------- Reporter: ow | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ow): varnishd/cache_expire.c 4128 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 20 11:36:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Jul 2009 11:36:28 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message Message-ID: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> #533: Varnishncsa stucks after error vcl message --------------------+------------------------------------------------------- Reporter: Tarick | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 2.0 | Severity: major Keywords: | --------------------+------------------------------------------------------- We are using varnish-2.0.4-1.el5 on CentOS 5.3 x86_64 and have following in our config: {{{ vcl_recv { ---skipped--- if (req.url == "/!ServerStatus") { error 200 "ONLINE"; } lookup; } }}} We are using that as a keepalive check for Cisco CSS balancer. The problem is that varnishncsa logs only the first !ServerStatus request and stop logging, until it receives different from ServerStatus request (e.g. !ServerStatus1, or just common request). This request unfreezes varnishncsa, but is lost from logging also - only the second after that request is logged, even if it is !ServerStatus again. I'm trying to figure out the different method for checking cache server, but this error is better to be fixed. This problem should be easily reproduced, so additional debugging information is not needed, I guess. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 20 17:54:11 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Jul 2009 17:54:11 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message In-Reply-To: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> References: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> Message-ID: <061.ce052b5389ac3f0e920659026cef9d6e@projects.linpro.no> #533: Varnishncsa stucks after error vcl message -------------------------+-------------------------------------------------- Reporter: Tarick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 2.0 Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Tarick): Sorry, there is a typo in VCL description, should be {{{ if (req.url == "/ServerStatus") { }}} , i.e. without exclamation mark. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 22 07:14:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 22 Jul 2009 07:14:20 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message In-Reply-To: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> References: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> Message-ID: <061.3ba58620b4fc20465a892f9c1ea43ea1@projects.linpro.no> #533: Varnishncsa stucks after error vcl message -------------------------+-------------------------------------------------- Reporter: Tarick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 2.0 Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Tarick): I've took varnishncsa from the 1.1.2 version and symlinked 2.0.4 libraries to libvarnish.so.0, etc. This version works, but doesn't log client ip, having minus instead of address: {{{ - - - [22/Jul/2009:01:54:31 -0500] "GET http://stg-c2-cache2/ServerStatus HTTP/1.1" 200 427 "-" "curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5" }}} We cannot use it therefore, but this confirms that the problem is in the new version of varnishncsa. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 22 08:11:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 22 Jul 2009 08:11:15 -0000 Subject: [Varnish] #485: Virtualhost logging for varnishncsa In-Reply-To: <052.ad49d79f82c60083d4971a3f23a8564c@projects.linpro.no> References: <052.ad49d79f82c60083d4971a3f23a8564c@projects.linpro.no> Message-ID: <061.8c00b7976c708c50da66d884cb6b1afa@projects.linpro.no> #485: Virtualhost logging for varnishncsa ---------------------------------------------------------+------------------ Reporter: rhalff | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: Keywords: varnishncsa, virtual hosts, apache, logging | ---------------------------------------------------------+------------------ Comment (by rhalff): Could this patch be applied ? It seems like gentoo is allready supplying this patch: http://gentoo-portage.com/www-servers/varnish/ChangeLog -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 23 18:11:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Jul 2009 18:11:40 -0000 Subject: [Varnish] #534: Threads stuck in trunk Message-ID: <052.0e28aca60f88a160e1d7f78d585e88f5@projects.linpro.no> #534: Threads stuck in trunk ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Keywords: threads stuck ----------------------+----------------------------------------------------- I am running Varnish trunk/4144 in FreeBSD/amd64 7.2-RELEASE, with no additional patches. For some time I have had problems with Varnish suddenly going to the maximum of allowed threads, and staying there. This means Varnish stops responding to new connections. Symptoms: 1) Lots of connections, most of which are in CLOSED or CLOSE_WAIT state: {{{ root at cache11:~# netstat -aln | grep ^tcp | awk '{print $1, $4, $6}' | sort | uniq -c | sort -n 1 tcp4 *.22 LISTEN 1 tcp4 *.4949 LISTEN 1 tcp4 *.5666 LISTEN 1 tcp4 *.80 LISTEN 1 tcp4 127.0.0.1.25 LISTEN 1 tcp4 127.0.0.1.49787 FIN_WAIT_2 1 tcp4 127.0.0.1.8080 LISTEN 2 tcp4 80.91.39.151.22 ESTABLISHED 2 tcp4 80.91.39.151.80 LAST_ACK 4 tcp4 127.0.0.1.80 CLOSE_WAIT 1177 tcp4 80.91.39.151.80 ESTABLISHED 2126 tcp4 80.91.39.151.80 CLOSE_WAIT 4476 tcp4 80.91.39.151.80 CLOSED }}} 2) varnishlog output: {{{ root at cache11:~# varnishlog 7806 SessionClose - dropped 7806 StatSess - (null) (null) 1248368086 0 0 0 0 0 0 0 0 Debug - "Create worker thread failed 67 Too many processes" 7807 SessionClose - dropped 7807 StatSess - (null) (null) 1248368090 0 0 0 0 0 0 0 7807 SessionClose - dropped 7807 StatSess - (null) (null) 1248368092 0 0 0 0 0 0 0 7807 SessionClose - dropped ^C }}} 3) process status: root at cache11:~# ps axwwH -o pid,wchan,state,command | grep Varnish-Chld | grep -v grep | sort | uniq -c 1 84804 kqread S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 nanslp S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 select I varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 select S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 ucond I varnishd: Varnish-Chld cache11.finn.no (varnishd) 3995 84804 umtxn I varnishd: Varnish-Chld cache11.finn.no (varnishd) If I enable mutex contest/logging (diag_bitmap set to 0x18), I get more varnishlog output: {{{ root at cache11:~# varnishlog 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(SES_New,cache_session.c,181,&ses_mem_mtx)" 0 Debug - "MTX_UNLOCK(SES_New,cache_session.c,183,&ses_mem_mtx)" 0 Debug - "MTX_LOCK(WRK_Queue,cache_pool.c,242,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(WRK_Queue,cache_pool.c,257,&wq[u]->mtx)" 8014 SessionClose - dropped 8014 StatSess - (null) (null) 1248372198 0 0 0 0 0 0 0 0 Debug - "MTX_LOCK(SES_Delete,cache_session.c,231,&ses_mem_mtx)" 0 Debug - "MTX_UNLOCK(SES_Delete,cache_session.c,233,&ses_mem_mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" 0 Debug - "MTX_UNLOCK(wrk_decimate_flock,cache_pool.c,367,&wq[u]->mtx)" 0 Debug - "MTX_LOCK(wrk_decimate_flock,cache_pool.c,354,&wq[u]->mtx)" }}} I will attach a graph that shows the sudden growth in number of threads. Only a full restart makes Varnish deliver normally again, with stuck connections and threads gone. The problem occurs on several servers, but somehow more often on this machine. PS: Yes, this is on finn.no, on the production cache servers. It happens after some hours, with at the current freeze 2,42 million objects and 40 GB data in the cache. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 23 18:14:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Jul 2009 18:14:34 -0000 Subject: [Varnish] #534: Threads stuck in trunk In-Reply-To: <052.0e28aca60f88a160e1d7f78d585e88f5@projects.linpro.no> References: <052.0e28aca60f88a160e1d7f78d585e88f5@projects.linpro.no> Message-ID: <061.f333a88bc9eb756391de9ef0948f684e@projects.linpro.no> #534: Threads stuck in trunk ---------------------------+------------------------------------------------ Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Resolution: Keywords: threads stuck | ---------------------------+------------------------------------------------ Comment (by anders): The process status info came garbled, so I send it again here: {{{ root at cache11:~# ps axwwH -o pid,wchan,state,command | grep Varnish-Chld | grep -v grep | sort | uniq -c 1 84804 kqread S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 nanslp S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 select I varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 select S varnishd: Varnish-Chld cache11.finn.no (varnishd) 1 84804 ucond I varnishd: Varnish-Chld cache11.finn.no (varnishd) 3995 84804 umtxn I varnishd: Varnish-Chld cache11.finn.no (varnishd) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From tarickr at gmail.com Fri Jul 24 20:19:31 2009 From: tarickr at gmail.com (Tarick) Date: Fri, 24 Jul 2009 23:19:31 +0300 Subject: Varnishncsa stucks after error vcl message Message-ID: <27e497970907241319q315f1b82icb9d2e59a272dcec@mail.gmail.com> Hello, fellows. I have a problem with varnishncsa on V2.0.4 on CentOS 5.3 x86_64, depicted in http://varnish.projects.linpro.no/ticket/533 I didn't include anyone in CC of that ticket, so I guess it will stay unanswered for a while. The problem is as follows: 1. we have the code in vcl config that is used as a keepalive functionality of Varnish itself. vcl_recv { ---skipped--- if (req.url == "/ServerStatus") { error 200 "ONLINE"; } lookup; } Therefore if we call http://cache/ServerStatus, we'll get HTTP 200 OK and some text. 2. Starting from Varnish 2.0.3 (the version we've upgraded to from 1.1.2), varnishncsa stopped logging any second request after that ServerStatus request. The third request is logged as it should. As this is the keepalive check, it occurs every 5 seconds, and therefore we are losing big part of our requests from logs. 3. I've tried using the first version of varnishncsa from Varnish 1.1.2 and it logged properly every request, though without client address. Of course we cannot use it thereof. But this confirms that the problem is in varnishncsa, not our config or environment. I suspect that the fix is easy, so I'd like to ask anyone who can fix that to look at it. Thank you, Tarick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb+varnish at slide.com Sat Jul 25 00:33:18 2009 From: kb+varnish at slide.com (Ken Brownfield) Date: Fri, 24 Jul 2009 17:33:18 -0700 Subject: Varnishncsa stucks after error vcl message In-Reply-To: <27e497970907241319q315f1b82icb9d2e59a272dcec@mail.gmail.com> References: <27e497970907241319q315f1b82icb9d2e59a272dcec@mail.gmail.com> Message-ID: The following seems to stop this behavior, but honestly I don't know enough (yet) about the bogus marker and /why/ it's causing a future request to be dropped. Varnishlog output seems correct. I'm not sure the "error 200" method is an especially clean way of doing this, but silently dropping logs is pretty evil. Error 403 seemed to also cause this in my testing... which I use :( --- bin/varnishncsa/varnishncsa.c.O 2009-07-24 17:00:56.000000000 -0700 +++ bin/varnishncsa/varnishncsa.c 2009-07-24 17:01:35.000000000 -0700 @@ -330,8 +330,7 @@ break; case SLT_SessionClose: - if (strncmp(ptr, "pipe", len) == 0 || - strncmp(ptr, "error", len) == 0) + if (strncmp(ptr, "pipe", len) == 0 ) lp->bogus = 1; break; -- Ken On Jul 24, 2009, at 1:19 PM, Tarick wrote: > Hello, fellows. > I have a problem with varnishncsa on V2.0.4 on CentOS 5.3 x86_64, > depicted in http://varnish.projects.linpro.no/ticket/533 > I didn't include anyone in CC of that ticket, so I guess it will > stay unanswered for a while. > The problem is as follows: > 1. we have the code in vcl config that is used as a keepalive > functionality of Varnish itself. > vcl_recv { > ---skipped--- > if (req.url == "/ServerStatus") { > > error 200 "ONLINE"; > } > lookup; > } > > Therefore if we call http://cache/ServerStatus, we'll get HTTP 200 > OK and some text. > > 2. Starting from Varnish 2.0.3 (the version we've upgraded to from > 1.1.2), varnishncsa stopped logging any second request after that > ServerStatus request. The third request is logged as it should. As > this is the keepalive check, it occurs every 5 seconds, and > therefore we are losing big part of our requests from logs. > > 3. I've tried using the first version of varnishncsa from Varnish > 1.1.2 and it logged properly every request, though without client > address. Of course we cannot use it thereof. But this confirms that > the problem is in varnishncsa, not our config or environment. > > I suspect that the fix is easy, so I'd like to ask anyone who can > fix that to look at it. > > Thank you, > > Tarick. > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-bugs From kb+varnish at slide.com Sat Jul 25 00:48:54 2009 From: kb+varnish at slide.com (Ken Brownfield) Date: Fri, 24 Jul 2009 17:48:54 -0700 Subject: Varnishncsa stucks after error vcl message In-Reply-To: References: <27e497970907241319q315f1b82icb9d2e59a272dcec@mail.gmail.com> Message-ID: <4B953EA1-D756-42E8-83B0-039A40FF9B02@slide.com> I /believe/ this is the proper fix. This replaces my hack. diff -u bin/varnishncsa/varnishncsa.c.O bin/varnishncsa/varnishncsa.c --- bin/varnishncsa/varnishncsa.c.O 2009-07-24 17:00:56.000000000 -0700 +++ bin/varnishncsa/varnishncsa.c 2009-07-24 17:45:39.000000000 -0700 @@ -378,6 +378,7 @@ assert(ll[fd] != NULL); } lp = ll[fd]; + lp->bogus = 0; if (spec & VSL_S_BACKEND) { if (collect_backend(lp, tag, spec, ptr, len)) -- Ken On Jul 24, 2009, at 5:33 PM, Ken Brownfield wrote: > The following seems to stop this behavior, but honestly I don't know > enough (yet) about the bogus marker and /why/ it's causing a future > request to be dropped. Varnishlog output seems correct. > > I'm not sure the "error 200" method is an especially clean way of > doing this, but silently dropping logs is pretty evil. Error 403 > seemed to also cause this in my testing... which I use :( > > --- bin/varnishncsa/varnishncsa.c.O 2009-07-24 17:00:56.000000000 > -0700 > +++ bin/varnishncsa/varnishncsa.c 2009-07-24 17:01:35.000000000 -0700 > @@ -330,8 +330,7 @@ > break; > > case SLT_SessionClose: > - if (strncmp(ptr, "pipe", len) == 0 || > - strncmp(ptr, "error", len) == 0) > + if (strncmp(ptr, "pipe", len) == 0 ) > lp->bogus = 1; > break; > > -- > Ken > > On Jul 24, 2009, at 1:19 PM, Tarick wrote: > >> Hello, fellows. >> I have a problem with varnishncsa on V2.0.4 on CentOS 5.3 x86_64, >> depicted in http://varnish.projects.linpro.no/ticket/533 >> I didn't include anyone in CC of that ticket, so I guess it will >> stay unanswered for a while. >> The problem is as follows: >> 1. we have the code in vcl config that is used as a keepalive >> functionality of Varnish itself. >> vcl_recv { >> ---skipped--- >> if (req.url == "/ServerStatus") { >> >> error 200 "ONLINE"; >> } >> lookup; >> } >> >> Therefore if we call http://cache/ServerStatus, we'll get HTTP 200 >> OK and some text. >> >> 2. Starting from Varnish 2.0.3 (the version we've upgraded to from >> 1.1.2), varnishncsa stopped logging any second request after that >> ServerStatus request. The third request is logged as it should. As >> this is the keepalive check, it occurs every 5 seconds, and >> therefore we are losing big part of our requests from logs. >> >> 3. I've tried using the first version of varnishncsa from Varnish >> 1.1.2 and it logged properly every request, though without client >> address. Of course we cannot use it thereof. But this confirms that >> the problem is in varnishncsa, not our config or environment. >> >> I suspect that the fix is easy, so I'd like to ask anyone who can >> fix that to look at it. >> >> Thank you, >> >> Tarick. >> _______________________________________________ >> varnish-bugs mailing list >> varnish-bugs at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-bugs > > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-bugs From varnish-bugs at projects.linpro.no Sat Jul 25 00:52:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Jul 2009 00:52:24 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message In-Reply-To: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> References: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> Message-ID: <061.5e53d6f637188b31aa2bc86c6d997c90@projects.linpro.no> #533: Varnishncsa stucks after error vcl message -------------------------+-------------------------------------------------- Reporter: Tarick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 2.0 Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by kb): I've attached what I think to be the proper fix, or at least a decent attempt at one. ;) (varnishncsa-bogus-fix.patch) Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jul 25 03:51:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Jul 2009 03:51:31 -0000 Subject: [Varnish] #518: Default backend health right after launch In-Reply-To: <049.e1162e9b4de6546075bcb636c7657920@projects.linpro.no> References: <049.e1162e9b4de6546075bcb636c7657920@projects.linpro.no> Message-ID: <058.85d879ba2832150e6c22b3f7024088ea@projects.linpro.no> #518: Default backend health right after launch --------------------+------------------------------------------------------- Reporter: rts | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kb): FWIW, this has been stable (no crashes) since I started using health- checked backends in production a month ago. Ken. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 02:40:32 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 02:40:32 -0000 Subject: [Varnish] #337: varnish doesn't work if compiled as 64bit in MacOSX In-Reply-To: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> References: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> Message-ID: <061.f1bdd3a3420048d9234cd0214761e49e@projects.linpro.no> #337: varnish doesn't work if compiled as 64bit in MacOSX ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kb): FWIW, there are other issues now; this specific ticket may no longer be useful. {{{ Child (31591) died signal=6 Child (31591) Panic message: Assert error in sock_test(), cache_acceptor.c line 96: Condition(l == sizeof tv) not true. thread = (cache-worker) Backtrace: 0x100000c89: _VCA_Prep+289 0x100008adc: 01 0000 FUN _cnt_first+5c 0x10000b06d: 01 0000 FUN _CNT_Session+8bd 0x10001cb47: 01 0000 FUN _wrk_do_cnt_sess+e7 0x10001c36a: _wrk_thread_real+29a 0x7fff846c8e8b: _params+7ffe846636e3 0x7fff846c8d4d: _params+7ffe846635a5 sp = 0x1000d3008 { fd = 11, id = 11, xid = 0, client = 127.0.0.1:59276, step = STP_FIRST, handling = error, restarts = 0, esis = 0 ws = 0x1000d3078 { id = "sess", {s,f,r,e} = {0x1000d3808,+16,0x0,+16384}, }, http[req] = { ws = 0x0[] }, worker = 0x1070151f0 { ws = 0x1070156e0 { id = "wrk", {s,f,r,e} = {0x10700f1b0,0x10700f1b0,0x0,+16384}, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 03:13:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 03:13:34 -0000 Subject: [Varnish] #527: String representation of 'obj.ttl' not implemented yet. In-Reply-To: <048.41d80f2a68c7fedd71fd1a5c4f6d3db6@projects.linpro.no> References: <048.41d80f2a68c7fedd71fd1a5c4f6d3db6@projects.linpro.no> Message-ID: <057.f74a8030d65289cf6c220cab6c7039db@projects.linpro.no> #527: String representation of 'obj.ttl' not implemented yet. ----------------------+----------------------------------------------------- Reporter: aj | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kb): Your first problem will be: {{{ Variable 'obj.ttl' not accessible in method 'vcl_deliver'. At: (input Line 218 Pos 39) set resp.http.X-Varnish-TTL = obj.ttl; --------------------------------------#######- }}} You can access it in vcl_fetch, but then you can only set an obj header. Which is not thread safe and will eventually crash the child (been there, done that). Also, varnish trunk seems to remove most obj access, both read and write. So this ability won't likely last, anyway. But if you like living on the dangerous side: {{{ --- lib/libvcl/vcc_string.c.O 2009-07-26 20:02:09.000000000 -0700 +++ lib/libvcl/vcc_string.c 2009-07-26 20:02:27.000000000 -0700 @@ -174,6 +174,9 @@ case BACKEND: Fb(tl, 0, "VRT_backend_string(sp)"); break; + case TIME: + Fb(tl, 0, "VRT_int_string(sp, %s)", vp->rname); + break; default: vsb_printf(tl->sb, "String representation of '%s'" " not implemented yet.\n", vp->name); }}} (just my US$0.02! YMMV, not heavily tested) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 04:28:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 04:28:43 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.e6f5884c3335052cba7205d153fde712@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kb): I've attached a patch as an RFC... this removes the special 304 path and integrates 304 handling in the normal 200 path. This is barely tested and may not be the right solution, but if you're in a pinch it may help? If you're interested, test it (thoroughly!) and see if it solves your issue? I also noticed that this behavior seems unchanged in trunk. Ken. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 14:05:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 14:05:20 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.bbd046ccbcfbb5890e5163cb06b9f4d4@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by stockrt): Let the patches war begin :) I have uploaded another patch (patch- bin_varnishd_cache_response.c-another-304-rfc-compliance-r4146.diff) that I believe to be more RFC compliant, since it only delivers the right headers when responding a 304 status code. The Ken's patch also delivers extra headers, like 'Content-Type:' and 'Age:', which are not desired for a 304 response. I believe my patch is simpler, too. Let's see how Varnish is delivering 304 headers today (without our patches): {{{ < HTTP/1.1 304 Not Modified < Date: Mon, 27 Jul 2009 13:43:51 GMT < Last-Modified: Wed, 10 Jun 2009 22:41:45 GMT < Connection: keep-alive }}} This is how it would be for Ken's patch: {{{ < HTTP/1.1 304 Not Modified < Last-Modified: Wed, 10 Jun 2009 22:41:45 GMT < Cache-Control: max-age=60 < Expires: Mon, 27 Jul 2009 13:44:49 GMT < Vary: Accept-Encoding < Content-Type: text/html < Date: Mon, 27 Jul 2009 13:43:51 GMT < Age: 1 < Connection: keep-alive }}} And this how it would be with my patch: {{{ < HTTP/1.1 304 Not Modified < Date: Mon, 27 Jul 2009 13:43:52 GMT < Last-Modified: Wed, 10 Jun 2009 22:41:45 GMT < Cache-Control: max-age=60 < Expires: Mon, 27 Jul 2009 13:44:48 GMT < Vary: Accept-Encoding < Connection: keep-alive }}} Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 So now, it is up to you (Varnish guys, phk, sky, anyone else?) to accept or decline our patches. Thanks, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 18:46:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 18:46:19 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.36de5dab90d3958783befb20d7efcd9f@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kb): Your patch is definitely cleaner. 10.3.5 wasn't clear /to me/ about what should be returned and what shouldn't. My first thought was to by default pass everything except those explicitly forbidden (X- headers might be useful in a 304 case), in which case the 200 path was already there. But: "If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers." I don't believe I was fully grokking this paragraph; if your interpretation is correct (which I now believe) then IMHO I think your patch is the better solution. Have you used this in "production" yet? I'll likely incrementally roll this into production and see how it fares. Thanks! Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 19:49:47 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 19:49:47 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.9a25cadce321cff3def9005d7241cecb@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kb): I ported your patch to 2.0.4 (including the small Last-Modified tweak from trunk) and attached it. I'm assuming P3P headers shouldn't be emitted on a 304, but I'm having a hard time finding anything concrete. Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 27 20:30:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Jul 2009 20:30:44 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.c0f1a82d5e1a1607a05ccbffcd403fd1@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by stockrt): As a matter of fact I have just finished rolling it into our production servers, and I can see a little decrease of cond GETs (304 responses) as expected! Now we are getting more Browser Cache Hits (client-side) then before, because now, when the browser refreshes the object, it gets 304 plus cache headers :) Regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 00:16:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 00:16:02 -0000 Subject: [Varnish] #535: Backend enver receives request... Message-ID: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: solaris ----------------------+----------------------------------------------------- Trying to use Varnish 2.0.4 on Solaris and have been less than successful. Using the most basic of startup flags, I get the following: {{{ # varnishd -b 192.168.13.34:80 -F -p vcl_trace=on Message from C-compiler: NB: Storage size limited to 2GB on 32 bit architecture, NB: otherwise we could run out of address space. storage_file: filename: ./varnish.JPaG6B (unlinked) size 2047 MB. Using old SHMFILE child (14297) Started Child (14297) said Closed fds: 3 5 9 10 12 13 Child (14297) said Child starts Child (14297) said managed to mmap 2147352576 bytes of 2147352576 Child (14297) said Ready }}} Log output: {{{ 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1248739212 1.0 5 SessionOpen c 192.168.12.83 56397 :80 5 ReqStart c 192.168.12.83 56397 980594 5 RxRequest c GET 5 RxURL c / 5 RxProtocol c HTTP/1.1 5 RxHeader c Host: example.org 5 VCL_call c recv 1 42.14 2 43.9 10 53.5 11 53.9 14 57.5 15 57.9 16 57.35 18 61.5 lookup 5 VCL_call c hash 21 78.14 22 80.9 23 80.24 hash 5 VCL_call c miss 29 95.14 fetch 5 VCL_call c error 41 129.15 deliver 5 Length c 462 5 VCL_call c deliver 37 110.17 deliver 5 TxProtocol c HTTP/1.1 5 TxStatus c 503 5 TxResponse c Service Unavailable 5 TxHeader c Server: Varnish 5 TxHeader c Retry-After: 0 5 TxHeader c Content-Type: text/html; charset=utf-8 5 TxHeader c Content-Length: 462 5 TxHeader c Date: Tue, 28 Jul 2009 00:00:12 GMT 5 TxHeader c X-Varnish: 980594 5 TxHeader c Age: 0 5 TxHeader c Via: 1.1 varnish 5 TxHeader c Connection: close 5 ReqEnd c 980594 1248739212.850627899 1248739212.850875139 0.000241041 0.000213623 0.000033617 5 SessionClose c error 5 StatSess c 192.168.12.83 56397 0 1 1 0 0 0 231 462 0 StatAddr - 192.168.12.83 0 2749 6 6 0 2 0 1386 2772 ^C }}} I was hoping that this was an event ports vs. poll(2) issue but that doesn't seem to change the result. {{{ # uname -a SunOS solaris.example.org 5.11 snv_89 i86pc i386 i86pc # gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} I've attached the output from `varnishd -C` for further diagnosis. It looks like VGC_function_vcl_fetch is failing, but I have been unsuccessful in determining why. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 11:21:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 11:21:28 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.be07a8905e977ded0234f38c3baf7b31@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Comment (by whocares): I can't see any obvious flaw in what you're doing there. But I can tell you that I successfully run 6 big varnish 2.0.4 installations on Solaris machines without any problems so far. If you could provide a bit more info about your setup, maybe we can find out what the problem is. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 11:24:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 11:24:43 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.d3211410c7e7c0719c009aa9f0e8d5b7@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Comment (by whocares): As an afterthought: I see froum your "uname -a" that you're *not* running Solaris 10 but a rather dated version of OpenSolaris. Maybe upgrading to a newer release would fix some of the problems? Also I have to say that I'm not using GCC but prefer to use SunStudio 12/12u1 on Solaris instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 13:42:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 13:42:39 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.86a9b32d27ca1826106bda694022f119@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4150]) Emit more headers when hitting 304 When hitting 304, ETag, Content-Location, Expires, Cache-control and Vary should all be sent to the client. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 for some more details Thanks to Rog?\195?\169rio Schneider for the patch. Fixes #529 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 13:54:37 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 13:54:37 -0000 Subject: [Varnish] #531: Varnish fails to compile on AIX 4.3 (Patch included) In-Reply-To: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> References: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> Message-ID: <060.284445be3f8e8777a6f8afbad449973d@projects.linpro.no> #531: Varnish fails to compile on AIX 4.3 (Patch included) --------------------+------------------------------------------------------- Reporter: demik | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [4151]) Add #ifdef for WCOREDUMP AIX doesn't have WCOREDUMP, so compilation failed there. Add #ifdef. Partially addresses #531. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 13:54:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 13:54:40 -0000 Subject: [Varnish] #531: Varnish fails to compile on AIX 4.3 (Patch included) In-Reply-To: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> References: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> Message-ID: <060.49b8ed98db00f69fb974956327849dd4@projects.linpro.no> #531: Varnish fails to compile on AIX 4.3 (Patch included) --------------------+------------------------------------------------------- Reporter: demik | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4152]) Rename struct thread to struct replay_thread in varnishreplay AIX has a "struct thread" in pthread.h, which conflicts with our struct thread. Rename ours to replay_thread. Fixes #531 Thanks to demik for patch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 14:11:17 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 14:11:17 -0000 Subject: [Varnish] #528: varnishlog doesn't show the full length of rxheaders In-Reply-To: <049.d33517d7209aa68a9a09955b1e5f00f0@projects.linpro.no> References: <049.d33517d7209aa68a9a09955b1e5f00f0@projects.linpro.no> Message-ID: <058.4a30af051a03fe33d186ea9589a3be83@projects.linpro.no> #528: varnishlog doesn't show the full length of rxheaders ------------------------+--------------------------------------------------- Reporter: rts | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: By default, the maximum record length is 255 bytes. You can increase shm_reclen either by passing -p on the varnish command line or using param.set in the command line interface. I'm closing this bug as I think this is, feel free to reopen if you think I am in error. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 14:13:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 14:13:15 -0000 Subject: [Varnish] #523: How to stop varnish ? In-Reply-To: <050.9b142a981cab998af7ce19c0361c8e4f@projects.linpro.no> References: <050.9b142a981cab998af7ce19c0361c8e4f@projects.linpro.no> Message-ID: <059.cdec4ae6bda0e5cd28d9ac05e0c8ffbd@projects.linpro.no> #523: How to stop varnish ? --------------------+------------------------------------------------------- Reporter: ovi1 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: Just using kill is a fine and traditional way of killing UNIX processes, so please just do that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 14:27:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 14:27:02 -0000 Subject: [Varnish] #517: Syntax failure in VCLExampleLongerCaching In-Reply-To: <057.8e19e80de3196cd7fb5df0aa38d40020@projects.linpro.no> References: <057.8e19e80de3196cd7fb5df0aa38d40020@projects.linpro.no> Message-ID: <066.61b5ee61d4ad477fc7f4324c8e60d009@projects.linpro.no> #517: Syntax failure in VCLExampleLongerCaching -------------------------+-------------------------------------------------- Reporter: mark.breyer | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by tfheen): Thanks a lot, fixed now! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 16:55:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 16:55:53 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.a71c17af1b76826a8ba2a4ba6937d1de@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Comment (by victori): I am on snv98 and I experience the same issue that the original poster has written about. I get 503 responses on healthy backends. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 18:29:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 18:29:57 -0000 Subject: [Varnish] #521: Sig 11 crash in trunk 4102 In-Reply-To: <052.e505c5dbe831127d825da5676e317109@projects.linpro.no> References: <052.e505c5dbe831127d825da5676e317109@projects.linpro.no> Message-ID: <061.97a2aebbca47556c4211e462b513ecf2@projects.linpro.no> #521: Sig 11 crash in trunk 4102 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by sky): * status: reopened => closed * resolution: => fixed Comment: Should be fixed with r4153 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 21:04:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 21:04:04 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.5804d509c1745bc28ad9fded3e160284@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Comment (by victori): Just a heads up, when I see varnish respond with 503 responses, I noticed an error popping up via dtrace. connect 150 operation now in progress From the solaris docs: Operation now in progress Cause An operation that takes a long time to complete (such as a connect) was attempted on a non-blocking object. Technical Notes The symbolic name for this error is EINPROGRESS, errno=150. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 28 22:47:48 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Jul 2009 22:47:48 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.c611163090b481fb54b4125ac2007291@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Comment (by victori): Finally resolved the issue on solaris thanks to the help of sky on irc. TCP_connect() with its blocking/unblocking code causes the issue. Setting connect_timeout to 0s will fix the issue by avoiding TCP_connect() and using connect() directly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 29 12:17:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Jul 2009 12:17:40 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.64b44c92a622549b0abe523385868abf@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Changes (by sky): * owner: phk => sky -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 29 12:19:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Jul 2009 12:19:13 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.ec83b46e662569b951bc3a2789f52655@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by sky): * owner: phk => sky -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 29 12:43:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Jul 2009 12:43:34 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.98a4e648f78fb528485f5c239fc9e91c@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: solaris | ----------------------+----------------------------------------------------- Changes (by sky): * status: new => closed * resolution: => fixed Comment: (In [4161]) On Solaris we occasionally get EBADF when we use the ioctl to toggle blocking. This then results in the connects failing. The way Solaris seems to want it to be done is using fcntl over two syscalls. So make it so conditionally for Solaris. Should fix #482 and #535 Compiled on Solaris and Victori tested a prelminary version of the patch that solved it. Sadly test cases don't seem to run at all on my solaris dev zone. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 29 12:43:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Jul 2009 12:43:34 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.8388e16306f6bb49ee60fa40faf579f1@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by sky): * status: new => closed * resolution: => fixed Comment: (In [4161]) On Solaris we occasionally get EBADF when we use the ioctl to toggle blocking. This then results in the connects failing. The way Solaris seems to want it to be done is using fcntl over two syscalls. So make it so conditionally for Solaris. Should fix #482 and #535 Compiled on Solaris and Victori tested a prelminary version of the patch that solved it. Sadly test cases don't seem to run at all on my solaris dev zone. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 30 07:12:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Jul 2009 07:12:28 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.b7e54fa28537a4e2da9945900fc13b8f@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: sky Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by sky): * status: closed => reopened * resolution: fixed => Comment: Apparently that didn't fix it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 30 07:12:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Jul 2009 07:12:39 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.f37763e582901ee55cedd2f15e32590b@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: sky Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: solaris | ----------------------+----------------------------------------------------- Changes (by sky): * status: closed => reopened * resolution: fixed => Comment: Apparently that didn't fix it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 30 11:17:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Jul 2009 11:17:45 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux In-Reply-To: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> References: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> Message-ID: <061.bf93d0ff120d5f785789cd90bab142a3@projects.linpro.no> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by sky): When I tried this patch it had massive performance problems. Should it still be merged in? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 30 14:43:35 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Jul 2009 14:43:35 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message In-Reply-To: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> References: <052.9a7cc08a6df41c87cf3a9e3a3743eb44@projects.linpro.no> Message-ID: <061.8e019b1b99388f625e1ec0814f4e87d9@projects.linpro.no> #533: Varnishncsa stucks after error vcl message -------------------------+-------------------------------------------------- Reporter: Tarick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 2.0 Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Tarick): Yes, this works, many thanks for that. Hope this will be in 2.0.5. -- Ticket URL: Varnish The Varnish HTTP Accelerator