From varnish-bugs at varnish-cache.org Tue Apr 1 11:45:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Apr 2014 11:45:15 -0000 Subject: [Varnish] #1468: Failed objects aren't removed from the cache Message-ID: <044.1a87336de50a6fac8bd9061f4a132869@varnish-cache.org> #1468: Failed objects aren't removed from the cache ----------------------+--------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+--------------------------------- On streamed fetch, and failure after HSH_Unbusy has been called, the object is marked with OC_F_FAILED so that subsequent lookups will fail. But it is not EXP_Rearmed to zero TTL to make the expiry release it, causing it to hang around for the original TTL. See attached test case. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 1 11:49:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Apr 2014 11:49:38 -0000 Subject: [Varnish] #1468: Failed objects aren't removed from the cache In-Reply-To: <044.1a87336de50a6fac8bd9061f4a132869@varnish-cache.org> References: <044.1a87336de50a6fac8bd9061f4a132869@varnish-cache.org> Message-ID: <059.f6869194466e54f8f9a3862007ad7c2f@varnish-cache.org> #1468: Failed objects aren't removed from the cache ----------------------+---------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by martin): Attached a patch that should fix this. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 2 16:43:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Apr 2014 16:43:10 -0000 Subject: [Varnish] #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 Message-ID: <044.f6209c53d1f0c51325cb59b2f6166f3f@varnish-cache.org> #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 ----------------------+--------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0-beta1 Severity: normal | Keywords: ----------------------+--------------------------------- When I build varnish-4.0.0-beta1 on rhel6/ppc64, p00007.vtc fails. See build log attached. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 7 10:38:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Apr 2014 10:38:04 -0000 Subject: [Varnish] #1465: Empty chunked response on storage failure In-Reply-To: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> References: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> Message-ID: <061.312a0cdb844a6d765f73fa1d36e6373e@varnish-cache.org> #1465: Empty chunked response on storage failure ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Discussed during bugwash today. * we can't change this into a 503, since we've already sent the headers down the tube. * is a missing chunked header an accepted indication of failure per the RFC? For now, the conclusion is that it needs more thought. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 7 11:33:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Apr 2014 11:33:16 -0000 Subject: [Varnish] #1461: Missing build dependency: ncurses devel In-Reply-To: <045.1fa8456432142e146bc39a8ea67285a5@varnish-cache.org> References: <045.1fa8456432142e146bc39a8ea67285a5@varnish-cache.org> Message-ID: <060.ecf230c0a81635cb5008ec3e78ce9988@varnish-cache.org> #1461: Missing build dependency: ncurses devel -------------------------+---------------------------------- Reporter: espebra | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: trunk Severity: trivial | Resolution: fixed Keywords: | -------------------------+---------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Fixed by 669197cdc246221d4bf599b41396a3860afd662e -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 7 12:03:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Apr 2014 12:03:14 -0000 Subject: [Varnish] #1462: ReqURL is emitted twice In-Reply-To: <043.4c15f0afe4e6c22dd922a9ce48ae670c@varnish-cache.org> References: <043.4c15f0afe4e6c22dd922a9ce48ae670c@varnish-cache.org> Message-ID: <058.91d5ec5452aba6038d4320b4c89dbc08@varnish-cache.org> #1462: ReqURL is emitted twice --------------------+----------------------------------------------- Reporter: scoof | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP2 Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [acd718f04215a8ca0cca4cd0d7997aceaf73c5a9]: {{{ #!CommitTicketReference repository="" revision="acd718f04215a8ca0cca4cd0d7997aceaf73c5a9" Only grab the first matched fragment in varnishncsa Fixes: #1462 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 8 09:03:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Apr 2014 09:03:29 -0000 Subject: [Varnish] #1468: Failed objects aren't removed from the cache In-Reply-To: <044.1a87336de50a6fac8bd9061f4a132869@varnish-cache.org> References: <044.1a87336de50a6fac8bd9061f4a132869@varnish-cache.org> Message-ID: <059.35aab9888cb25da0dc0071db5d96f7f7@varnish-cache.org> #1468: Failed objects aren't removed from the cache ----------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [a43326dd93b9a37428b9aecf72e785ed7675afef]: {{{ #!CommitTicketReference repository="" revision="a43326dd93b9a37428b9aecf72e785ed7675afef" Rearm at zero TTL on failed objects Fixes: #1468 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 8 12:59:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Apr 2014 12:59:20 -0000 Subject: [Varnish] #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 In-Reply-To: <044.f6209c53d1f0c51325cb59b2f6166f3f@varnish-cache.org> References: <044.f6209c53d1f0c51325cb59b2f6166f3f@varnish-cache.org> Message-ID: <059.cad75668a34549fd86b914f0ae66c18b@varnish-cache.org> #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 ----------------------+----------------------------------------------- Reporter: ingvar | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0-beta1 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [9f3100e298e079d75fe4e448d5b1b4e26cb2606e]: {{{ #!CommitTicketReference repository="" revision="9f3100e298e079d75fe4e448d5b1b4e26cb2606e" Take offset rounding into account when rounding the length of segment size. Fixes: #1469 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 8 22:17:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Apr 2014 22:17:48 -0000 Subject: [Varnish] #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 In-Reply-To: <044.f6209c53d1f0c51325cb59b2f6166f3f@varnish-cache.org> References: <044.f6209c53d1f0c51325cb59b2f6166f3f@varnish-cache.org> Message-ID: <059.a03c77da383a0bc1becb2595197b2f4a@varnish-cache.org> #1469: p00007.vtc fails, Assert error in smp_new_seg(), varnish-4.0.0-beta1 on rhel6/ppc64 ----------------------+----------------------------------------------- Reporter: ingvar | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0-beta1 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by ingvar): Seems fixed now, thank you. rhel6/ppc64 build of beta1: http://koji.fedoraproject.org/koji/taskinfo?taskID=6719367 Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 9 10:30:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Apr 2014 10:30:22 -0000 Subject: [Varnish] #1470: Ban lurker would spin on busy objects Message-ID: <044.1201bb24a90a2c0eec70369c05b3c680@varnish-cache.org> #1470: Ban lurker would spin on busy objects ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Keywords: ----------------------+------------------- The pass bits of the oc's flags isn't cleared before or'ing the new pass on failing the busy object test in the ban lurker. This would cause the pass not to be matched later, making the lurker spin on the busy object. When the busy flag was cleared, things would resume to normal. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 9 10:30:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Apr 2014 10:30:41 -0000 Subject: [Varnish] #1470: Ban lurker would spin on busy objects In-Reply-To: <044.1201bb24a90a2c0eec70369c05b3c680@varnish-cache.org> References: <044.1201bb24a90a2c0eec70369c05b3c680@varnish-cache.org> Message-ID: <059.daae200dd775a16a8959d8d4e9e9b71c@varnish-cache.org> #1470: Ban lurker would spin on busy objects ----------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [dec9098a2ac760d7ba4765a9a1a1091103b6eb05]: {{{ #!CommitTicketReference repository="" revision="dec9098a2ac760d7ba4765a9a1a1091103b6eb05" Clear the pass oc flag bits earlier in the ban lurker The pass bits of the oc's flags wasn't cleared before or'ing the new pass on failing the busy object test in the ban lurker. This would cause the pass not to be matched later, making the lurker spin on the busy object. Fixes: #1470 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 9 12:48:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Apr 2014 12:48:10 -0000 Subject: [Varnish] #1471: Assert error with persistent storage Message-ID: <046.385d53525338dce61ea8f1e5b97f7250@varnish-cache.org> #1471: Assert error with persistent storage ---------------------------------------------+---------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0-beta1 | Severity: normal Keywords: assert persistent smp_oc_getobj | ---------------------------------------------+---------------------- Hi, While stress testing persistent storage (around 300req/s, 99% miss), I get regular panics, from every minute to every 5 minutes depending on the storage type (local disk, nfs). Assert is the following : {{{ varnish> panic.show 200 Last panic at: Wed, 09 Apr 2014 11:56:57 GMT Assert error in smp_oc_getobj(), storage/storage_persistent_silo.c line 437: Condition((o)->magic == 0x32851d42) not true. thread = (cache-timeout) ident = Linux,3.9.3,x86_64,-spersistent,-smalloc,-hcritbit,epoll Backtrace: 0x433515: /usr/sbin/varnishd() [0x433515] 0x45ce08: /usr/sbin/varnishd() [0x45ce08] 0x41e63d: /usr/sbin/varnishd() [0x41e63d] 0x44812e: /usr/sbin/varnishd() [0x44812e] 0x7fb11fa3db50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fb11fa3db50] 0x7fb11f7880ed: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb11f7880ed] }}} Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 9 21:54:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Apr 2014 21:54:28 -0000 Subject: [Varnish] #1472: Varnish 4.0.0 packages for el6 are not signed Message-ID: <044.b98708cf1481f1c020f64c48202670a8@varnish-cache.org> #1472: Varnish 4.0.0 packages for el6 are not signed ---------------------------------+----------------------- Reporter: mortsa | Type: defect Status: new | Priority: high Milestone: Varnish 4.0 release | Component: packaging Version: 4.0.0-beta1 | Severity: major Keywords: gpg rpm security | ---------------------------------+----------------------- None of the packages available at http://repo.varnish- cache.org/redhat/varnish-4.0/el6/x86_64/varnish/ are signed with a GPG key. When trying to to install varnish with gpgcheck=1 in the yum repository configuration file, I get the following error message: "Package varnish-4.0.0-0.20140328beta1.el6.x86_64.rpm is not signed" A similiar ticket (#906) [1] was created 3 years ago and it was closed with resolution set to "wontfix". [1]: https://www.varnish-cache.org/trac/ticket/906 Most of the software that is packaged and distributed as RPM packages by software vendors, are (or should be) signed by a GPG key from the software vendor by well-known reasons. The GPG key itself is commonly distributed as part of the release package (varnish-release), and the yum repository configuration file should contain "gpgcheck=1" to enable GPG signature checking on all packages in the repository. I hope you will prioritize this bug before Varnish 4.0.0 is released as stable. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 10 12:28:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Apr 2014 12:28:45 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement Message-ID: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------------------+-------------------- Reporter: jpotter | Type: defect Status: new | Priority: high Milestone: Varnish 4.0 release | Component: build Version: 4.0.0 | Severity: major Keywords: | ---------------------------------+-------------------- It looks like going from 3.0.5 to 4.0.0 that rst2man is now required to be installed to build varnish. In 3.0.5, configure would skip over man pages and changelog when it wasn't present: {{{ checking for rst2man... no checking for rst2man.py... no configure: WARNING: rst2man not found ? not building man pages checking for rst2html... no checking for rst2html.py... no configure: WARNING: rst2html not found ? not building change log }}} Whereas in 4.0.0: {{{ checking for rst2man... no checking for rst2man.py... no configure: error: rst2man is needed to build Varnish, please install python-docutils. }}} Running configure with the flag "--without-rst2man" doesn't work, either: configure is okay, but then make errors out: {{{ Making all in man CC vsc2rst.o CCLD vsc2rst ./vsc2rst | no - varnish-counters.7 /bin/sh: no: command not found make[3]: *** [varnish-counters.7] Error 127 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 }}} Can this either be reverted to the old behavior, or can the --without- rst2man flag be checked to skip building the man pages and html docs? We can't built varnish currently as OS X doesn't have rst2man, and there's no package for it (or python-docutils) in brew, etc. Thanks, Jeff -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 10 13:14:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Apr 2014 13:14:08 -0000 Subject: [Varnish] #1388: Length is 0 for most responses In-Reply-To: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> References: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> Message-ID: <058.059224541d0107948b43b80e0adf84da@varnish-cache.org> #1388: Length is 0 for most responses --------------------+---------------------------------- Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------- Changes (by scoof): * status: new => closed * resolution: => fixed Comment: Fixed by the move to ReqAcct -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 10 13:20:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Apr 2014 13:20:09 -0000 Subject: [Varnish] #1474: Unclear how to migrate uses of sess_timeout Message-ID: <045.79bcd308bf84f0a905265638886390a5@varnish-cache.org> #1474: Unclear how to migrate uses of sess_timeout ---------------------+--------------------------- Reporter: jpotter | Type: documentation Status: new | Priority: low Milestone: | Component: documentation Version: 4.0.0 | Severity: minor Keywords: | ---------------------+--------------------------- It looks like sess_timeout is no longer used in Varnish 4, but the documentation isn't clear about it being dropped or what replaces it: https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#sess- timeout Also, ./varnish-4.0.0/doc/sphinx/index.rst mentions it as an example variable, might want to change that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 10 20:06:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Apr 2014 20:06:58 -0000 Subject: [Varnish] #1474: Unclear how to migrate uses of sess_timeout In-Reply-To: <045.79bcd308bf84f0a905265638886390a5@varnish-cache.org> References: <045.79bcd308bf84f0a905265638886390a5@varnish-cache.org> Message-ID: <060.c4c70f0c07480565f576a7d2789b08f7@varnish-cache.org> #1474: Unclear how to migrate uses of sess_timeout ---------------------------+-------------------------------------- Reporter: jpotter | Owner: Andreas Plesner Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: 4.0.0 Severity: minor | Resolution: fixed Keywords: | ---------------------------+-------------------------------------- Changes (by Andreas Plesner ): * owner: => Andreas Plesner * status: new => closed * resolution: => fixed Comment: In [77524d922370f72037ac41d7980be2294c72817a]: {{{ #!CommitTicketReference repository="" revision="77524d922370f72037ac41d7980be2294c72817a" Add some text about some of the changed parameters, fixes #1474 Introduce new section for new parameters }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 08:40:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 08:40:08 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.feaabf28b9ee8632152a7c259aed9142@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgs Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Changes (by lkarsten): * owner: => fgs -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 08:41:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 08:41:04 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.adc45e6f3a5ad27907abc2e923634a5e@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Changes (by lkarsten): * owner: fgs => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 09:17:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 09:17:42 -0000 Subject: [Varnish] #1475: varnishncsa's ttfb is potentially dishonest Message-ID: <043.e80b008761b52f4c1e00a4729b526848@varnish-cache.org> #1475: varnishncsa's ttfb is potentially dishonest ----------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Time to first byte in varnishncsa is taken from the VSL timestamp record tagged 'Process', which is taken /before/ vcl_deliver has been executed. Hence any significant processing in vcl_deliver will not impact the reported ttfb as one might expect, and it will simply be inaccurate .. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 09:40:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 09:40:22 -0000 Subject: [Varnish] #1476: Build failures on Debian GNU/kFreeBSD Message-ID: <041.70dfa72ba3eef70143ec6b80ce0ffc03@varnish-cache.org> #1476: Build failures on Debian GNU/kFreeBSD --------------------+------------------- Reporter: ssm | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Keywords: --------------------+------------------- Build fails on the GNU/kFreeBSD architectures on Debian. Complete build logs at: https://buildd.debian.org/status/fetch.php?pkg=varnish&arch=kfreebsd- amd64&ver=4.0.0-1&stamp=1397135882 https://buildd.debian.org/status/fetch.php?pkg=varnish&arch=kfreebsd-i386&ver=4.0.0-1&stamp=1397135858 Relevant excerpt from the build log: {{{ vsha256.c:40:0: error: "VBYTE_ORDER" redefined [-Werror] #define VBYTE_ORDER __BYTE_ORDER ^ vsha256.c:34:0: note: this is the location of the previous definition #define VBYTE_ORDER _BYTE_ORDER ^ vsha256.c:41:0: error: "VBIG_ENDIAN" redefined [-Werror] #define VBIG_ENDIAN __BIG_ENDIAN ^ vsha256.c:35:0: note: this is the location of the previous definition #define VBIG_ENDIAN _BIG_ENDIAN ^ }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 12:01:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 12:01:51 -0000 Subject: [Varnish] #1456: ReqAcct is not output during request handling In-Reply-To: <046.d3874a8b2442595487802963f9b68200@varnish-cache.org> References: <046.d3874a8b2442595487802963f9b68200@varnish-cache.org> Message-ID: <061.bd430f19561ae37361c5b2112b9fef08@varnish-cache.org> #1456: ReqAcct is not output during request handling ----------------------+---------------------------------- Reporter: lkarsten | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: This was fixed as a part of Martin's accounting commits about 2 weeks ago. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 12:50:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 12:50:48 -0000 Subject: [Varnish] #1477: Varnish cra Message-ID: <044.9ebf5466605be1630e84912affd2a5d8@varnish-cache.org> #1477: Varnish cra -------------------------------------------------+------------------------- Reporter: citrus | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: hash_ignore_busy streaming panic | ttl do_stream | -------------------------------------------------+------------------------- Varnish crashes if multiple users are downloading a streamed file and another request is made after its TTL expires. - A big (~1GB), cacheable file from a server is requested by user 1. - While varnish is streaming the file to user 1, user 2 also starts downloading it, within TTL. - User 3 starts downloading the file after its TTL has expired. - Varnish crashes {{{ set req.hash_ignore_busy = true; set beresp.do_stream = true; }}} {{{ vcl: set beresp.ttl = 10s; OR .htaccess: Header set Cache-Control "max-age=10" }}} {{{ ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & ~# sleep 3 ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & ~# sleep 10 ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & }}} {{{ Child (24178) Panic message: Assert error in HSH_Lookup(), cache/cache_hash.c line 461: Condition((req->hash_ignore_busy) == 0) not true. thread = (cache-worker) ident = Linux,3.10.23-std-ipv6-64,x86_64 Backtrace: 0x43bd4f: pan_backtrace+0x19 0x43c059: pan_ic+0x1e9 0x42c699: HSH_Lookup+0xa47 0x43fd1f: cnt_lookup+0x242 0x4423b6: CNT_Request+0x441 0x434ed7: HTTP1_Session+0x427 0x44538e: ses_req_pool_task+0x166 0x445659: ses_sess_pool_task+0x23b 0x445c01: SES_pool_accept_task+0x201 0x43dbca: Pool_Work_Thread+0x442 req = 0x8e1d70 { sp = 0x7f0e2c0065d0, vxid = 1073807362, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f0e2c0065d0 { fd = 25, vxid = 65537, client = xx.xx.xx.xx 50957, step = S_STP_WORKING, }, worker = 0x7f0cc8e01c50 { ws = 0x7f0cc8e01e60 { id = "wrk", {s,f,r,e} = {0x7f0cc8e01430,0x7f0cc8e01430,(nil),+2048}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x8e1f00 { id = "req", {s,f,r,e} = {0x8e3d40,+168,+57392,+57392}, }, http[req] = { ws = 0x8e1f00[req] "GET", "/bigfile_cache", "HTTP/1.1", "User-Agent: Wget/1.13.4 (linux-gnu)", "Accept: */*", "Host: example.com", "Connection: Keep-Alive", "X-Forwarded-For: xx.xx.xx.xx", }, vcl = { srcname = { "input", "Builtin", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 13:58:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 13:58:35 -0000 Subject: [Varnish] #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired Message-ID: <044.80053f43190452a5895eda5daf7014f5@varnish-cache.org> #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired ---------------------------------------------+---------------------- Reporter: citrus | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: ignore_busy streaming panic ttl | ---------------------------------------------+---------------------- Varnish crashes if a user requests a streamed file that is still being cached if its TTL has already expired. - A big (~1GB), cacheable file from a server is requested by user 1. - While varnish is streaming the file to user 1, user 2 also starts downloading it, within TTL. - User 3 tries to download the file after its TTL has expired. - Varnish crashes {{{ set req.hash_ignore_busy = true; set beresp.do_stream = true; }}} {{{ vcl: set beresp.ttl = 10s; OR .htaccess: Header set Cache-Control "max-age=10" }}} {{{ ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & ~# sleep 3 ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & ~# sleep 10 ~# curl 0/1GB_file -H'Host: example.com' -is -o /dev/null & }}} It also crashes if the first request is cancelled and a second one is made after TTL expires (while it's downloading the whole file to cache). {{{ Child (24178) Panic message: Assert error in HSH_Lookup(), cache/cache_hash.c line 461: Condition((req->hash_ignore_busy) == 0) not true. thread = (cache-worker) ident = Linux,3.10.23-std-ipv6-64,x86_64 Backtrace: 0x43bd4f: pan_backtrace+0x19 0x43c059: pan_ic+0x1e9 0x42c699: HSH_Lookup+0xa47 0x43fd1f: cnt_lookup+0x242 0x4423b6: CNT_Request+0x441 0x434ed7: HTTP1_Session+0x427 0x44538e: ses_req_pool_task+0x166 0x445659: ses_sess_pool_task+0x23b 0x445c01: SES_pool_accept_task+0x201 0x43dbca: Pool_Work_Thread+0x442 req = 0x8e1d70 { sp = 0x7f0e2c0065d0, vxid = 1073807362, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f0e2c0065d0 { fd = 25, vxid = 65537, client = xx.xx.xx.xx 50957, step = S_STP_WORKING, }, worker = 0x7f0cc8e01c50 { ws = 0x7f0cc8e01e60 { id = "wrk", {s,f,r,e} = {0x7f0cc8e01430,0x7f0cc8e01430,(nil),+2048}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x8e1f00 { id = "req", {s,f,r,e} = {0x8e3d40,+168,+57392,+57392}, }, http[req] = { ws = 0x8e1f00[req] "GET", "/bigfile_cache", "HTTP/1.1", "User-Agent: Wget/1.13.4 (linux-gnu)", "Accept: */*", "Host: example.com", "Connection: Keep-Alive", "X-Forwarded-For: xx.xx.xx.xx", }, vcl = { srcname = { "input", "Builtin", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 11 14:05:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Apr 2014 14:05:43 -0000 Subject: [Varnish] #1477: Varnish cra In-Reply-To: <044.9ebf5466605be1630e84912affd2a5d8@varnish-cache.org> References: <044.9ebf5466605be1630e84912affd2a5d8@varnish-cache.org> Message-ID: <059.27700241508ee3a29425a418bcce61d9@varnish-cache.org> #1477: Varnish cra -------------------------------------------------+------------------------- Reporter: citrus | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish Component: varnishd | 4.0 release Severity: normal | Version: 4.0.0 Keywords: hash_ignore_busy streaming panic | Resolution: duplicate ttl do_stream | -------------------------------------------------+------------------------- Changes (by lkarsten): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1478, closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 12 23:01:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Apr 2014 23:01:11 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. Message-ID: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+-------------------- Reporter: basile@? | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: | ----------------------+-------------------- When building varnish 4.0.0 outside of the source tree, making vmod_std.3 and vmod_directors.3 fail because they depend on lib/libvmod_std/vmod_std.man.rst and lib/libvmod_directors/vmod_directors.man.rst which are generated under the top_builddir and not under the top_srcdir. The attached patch fixes the build -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 13 14:12:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Apr 2014 14:12:21 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete Message-ID: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ------------------------+--------------------------- Reporter: falconindy | Type: documentation Status: new | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Keywords: | ------------------------+--------------------------- Thanks for the new release of Varnish. I found the porting guide for 4.0.0, but it seems incomplete in a number of ways. My setup is quite simple, yet I still ran into 2 instances where the guide did not cover important changes: - vcl_error is now vcl_backend_error - req.request is now req.method There may be other instances -- I see there's also now a vcl_backend_fetch, but I can't determine if this is new, or just renamed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 13 14:30:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Apr 2014 14:30:07 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete In-Reply-To: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> References: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> Message-ID: <063.0b247aef081b728889941e2af364c563@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ---------------------------+-------------------- Reporter: falconindy | Owner: Type: documentation | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Comment (by falconindy): For some reason I thought I was finished porting... More examples: - obj.status -> beresp.status (in vcl_backend_error) - obj.response -> beresp.reason (in vcl_backend_error) - in vcl_hash, return(hash) is no longer valid - in vcl_pass, return(pass) is no longer valid - in vcl_recv, return(lookup) is no longer valid A bunch of this seems to be inferred by the builtin.vcl shipped with varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From phk at phk.freebsd.dk Sun Apr 13 16:51:19 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 13 Apr 2014 16:51:19 +0000 Subject: Gzipping SVG In-Reply-To: References: Message-ID: <12602.1397407879@critter.freebsd.dk> In message , Mike Neumegen writes: >Gzip doesn't work on SVG files for me. I have GZip compression working for > >if (beresp.http.content-type ~ >"^(image/svg|image/svg\+xml|image/svg+xml)$") { > > set beresp.do_gzip = true; > > } Please capture the varnishlog output for the transaction so we can see what goes on. Are you sure you were not seeing and old cached entry ? gzip'ing happens at fetch time. -- 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 varnish-cache.org Mon Apr 14 10:36:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 10:36:55 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete In-Reply-To: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> References: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> Message-ID: <063.7f53fa58ee2eb3cf7568c23a023a7953@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ---------------------------+-------------------- Reporter: falconindy | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by scoof): * owner: => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 14 10:37:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 10:37:50 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.4fa88075caf06d627b8e36f71cda68c7@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+-------------------- Reporter: basile@? | Owner: scoof Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by scoof): * owner: => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 14 10:42:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 10:42:21 -0000 Subject: [Varnish] #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired In-Reply-To: <044.80053f43190452a5895eda5daf7014f5@varnish-cache.org> References: <044.80053f43190452a5895eda5daf7014f5@varnish-cache.org> Message-ID: <059.878b7f7d6190b8f3d20a9d1563c64d0e@varnish-cache.org> #1478: Panic when trying to stream a big file that is still being cached and its TTL has expired ---------------------------------------------+----------------------------- Reporter: citrus | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 Component: varnishd | release Severity: normal | Version: 4.0.0 Keywords: ignore_busy streaming panic ttl | Resolution: ---------------------------------------------+----------------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 14 10:42:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 10:42:28 -0000 Subject: [Varnish] #1476: Build failures on Debian GNU/kFreeBSD In-Reply-To: <041.70dfa72ba3eef70143ec6b80ce0ffc03@varnish-cache.org> References: <041.70dfa72ba3eef70143ec6b80ce0ffc03@varnish-cache.org> Message-ID: <056.cd8d43c19ba40292c6699a8393571c54@varnish-cache.org> #1476: Build failures on Debian GNU/kFreeBSD --------------------+-------------------- Reporter: ssm | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 14 12:15:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 12:15:03 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete In-Reply-To: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> References: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> Message-ID: <063.10d7f5436fff31517739f0d040e8234b@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ---------------------------+-------------------- Reporter: falconindy | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Comment (by scoof): note to self: -m is gone, use -q -w is gone, use -p -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 14 16:03:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Apr 2014 16:03:43 -0000 Subject: [Varnish] #1475: varnishncsa's ttfb is potentially dishonest In-Reply-To: <043.e80b008761b52f4c1e00a4729b526848@varnish-cache.org> References: <043.e80b008761b52f4c1e00a4729b526848@varnish-cache.org> Message-ID: <058.0a70debbae8c2394309565c73c0ab982@varnish-cache.org> #1475: varnishncsa's ttfb is potentially dishonest ----------------------+----------------------------------------------- Reporter: daghf | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [d31fa8397deda3697d68a381d7df48073e41556d]: {{{ #!CommitTicketReference repository="" revision="d31fa8397deda3697d68a381d7df48073e41556d" Timestamp "Process" after vcl_deliver has been run. The EXP_Touch and the Age header will be based off the last timestamp taken. This can be slightly inaccurate, but saves us from having to do another timestamp for them. Fixes: #1475 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 16 03:02:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Apr 2014 03:02:02 -0000 Subject: [Varnish] #1481: directors vmod needs a simpler way to declare a massive set of backends Message-ID: <050.ce8e424d586f3d48f37721a6fc0adaf7@varnish-cache.org> #1481: directors vmod needs a simpler way to declare a massive set of backends --------------------------+------------------------- Reporter: mattrobenolt | Type: enhancement Status: new | Priority: normal Milestone: | Component: vmod Version: 4.0.0 | Severity: normal Keywords: directors | --------------------------+------------------------- In 3.0, declaring a long list of backend servers for a director was trivial. An except from one of our VCLs looks like the following: {{{ director apps random { { .backend = { .host = "app-1.i"; .probe = isup; } .weight = 50; } { .backend = { .host = "app-2.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-3.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-4.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-5.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-6.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-7.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-8.i"; .probe = isup; } .weight = 100; } { .backend = { .host = "app-9.i"; .probe = isup; } .weight = 100; } # ... 100 more } }}} In 4.0, the amount of lines has effective doubled and introduces the fact that each backend needs to have a proper name making using any automated tooling trickier and much more difficult to work with. For example: {{{ backend app1 { .host = "app-1.i" .probe = isup; } backend app2 { .host = "app-2.i" .probe = isup; } backend app3 { .host = "app-3.i" .probe = isup; } backend app4 { .host = "app-4.i" .probe = isup; } backend app5 { .host = "app-5.i" .probe = isup; } backend app6 { .host = "app-6.i" .probe = isup; } backend app7 { .host = "app-7.i" .probe = isup; } backend app8 { .host = "app-8.i" .probe = isup; } backend app9 { .host = "app-9.i" .probe = isup; } # ... 100 more sub vcl_init { new apps = backend.random(); apps.add_backend(app1, 100); apps.add_backend(app2, 100); apps.add_backend(app3, 100); apps.add_backend(app4, 100); apps.add_backend(app5, 100); apps.add_backend(app6, 100); apps.add_backend(app7, 100); apps.add_backend(app8, 100); apps.add_backend(app9, 100); # ... 100 more } }}} This list of servers is typically managed by some configuration management system, such as puppet or chef. In the previous model, it's trivial to iterate over a list of servers and repeat the same line and just swap out the hostname. In the new model, a unique name for the backend needs to be generated that needs to then pair up with what's inside `vcl_init`. Now, I understand the advantages of moving directors to a vmod, so I'm not arguing against that. I'd suggest more functions on the vmod that take parameters as input to create the backends automatically. I don't think it's possible in current vmod syntax to support something like: `director.add_backend({ .host = "foo" }, 1)` Something like `director.add_anonymous_backend` could probably fill that gap. `add_anonymous_backend` would look something like: `director.add_anonymous_backend("app-1.i", ...)` As it stands today, this just made switching to 4.0 an almost deal breaker in my opinion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 17 10:44:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Apr 2014 10:44:40 -0000 Subject: [Varnish] #1482: [PATCH]: initialize supplementary groups before setuid() Message-ID: <043.7500bf778f4b622e4f506463c4cbfca9@varnish-cache.org> #1482: [PATCH]: initialize supplementary groups before setuid() -------------------+------------------------- Reporter: idl0r | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+------------------------- Please see the attached patch. One may have gcc or other things restricted, so that e.g. only a specific user and/or group may execute it. Varnish never inherited the groups of the user that has been specified by "-u". initgroups() will make sure that varnish gets all supplementary groups. Steps to reproduce: {{{ chown root:gccuser /usr/bin/gcc chmod 0750 /usr/bin/gcc varnishd -u varnish -g varnish -f /etc/varnish/default.vcl -F Message from C-compiler: /bin/sh: 1: exec: gcc: Permission denied Running C-compiler failed, exit 126 VCL compilation failed gpasswd -a varnish gccuser varnishd -u varnish -g varnish -f /etc/varnish/default.vcl -F Message from C-compiler: /bin/sh: 1: exec: gcc: Permission denied Running C-compiler failed, exit 126 VCL compilation failed }}} Now apply my patch and try again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 17 12:00:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Apr 2014 12:00:42 -0000 Subject: [Varnish] #1482: [PATCH]: initialize supplementary groups before setuid() In-Reply-To: <043.7500bf778f4b622e4f506463c4cbfca9@varnish-cache.org> References: <043.7500bf778f4b622e4f506463c4cbfca9@varnish-cache.org> Message-ID: <058.53db3e5be6243a2d97655aa386a53935@varnish-cache.org> #1482: [PATCH]: initialize supplementary groups before setuid() -------------------------+-------------------- Reporter: idl0r | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by idl0r): It seems to be more a regression. Varnish 3.x did the gcc exec as root (or the user that executes varnishd) and the setuid() is done afterwards. In 4.x it does the setuid() first and then the gcc exec. The way Varnish 4.x does it is much better though it needs the proposed fix to make it "perfect". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 17 13:01:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Apr 2014 13:01:58 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.6acb88aec20c5023535538f52ba34377@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+---------------------- Reporter: idl0r | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+---------------------- Changes (by fgsch): * type: enhancement => defect -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 19 22:03:05 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 19 Apr 2014 22:03:05 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete In-Reply-To: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> References: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> Message-ID: <063.0c87a6ce356593e5fbdeff5f0904cee4@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ---------------------------+-------------------- Reporter: falconindy | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Comment (by patrice): for the porting guide : * server.port is now std.port(server.ip) * req.backend using a director is now : req.backend_hint = mydirector.backend() {{{ - if (server.port == 8020) { - set req.backend = mydirector; + if (std.port(server.ip) == 8020) { + set req.backend_hint = mydirector.backend(); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 19 22:26:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 19 Apr 2014 22:26:48 -0000 Subject: [Varnish] #1471: Assert error with persistent storage In-Reply-To: <046.385d53525338dce61ea8f1e5b97f7250@varnish-cache.org> References: <046.385d53525338dce61ea8f1e5b97f7250@varnish-cache.org> Message-ID: <061.173d336c6d36121e8f3b7aa70f69fe62@varnish-cache.org> #1471: Assert error with persistent storage ---------------------------------------------+-------------------------- Reporter: tmagnien | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0-beta1 Severity: normal | Resolution: Keywords: assert persistent smp_oc_getobj | ---------------------------------------------+-------------------------- Comment (by patrice): after a few minutes testing version 4.0.0 from ubuntu package with live traffic : {{{ arnish> panic.show 200 Last panic at: Sat, 19 Apr 2014 22:21:51 GMT Assert error in smp_oc_getobj(), storage/storage_persistent_silo.c line 438: Condition((o)->magic == 0x32851d42) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.11.0-12-generic,x86_64,-spersistent,-smalloc,-hcritbit,epoll Backtrace: 0x4325b5: /usr/sbin/varnishd() [0x4325b5] 0x45c70e: /usr/sbin/varnishd() [0x45c70e] 0x435d2b: /usr/sbin/varnishd(CNT_Request+0x56b) [0x435d2b] 0x42cccb: /usr/sbin/varnishd(HTTP1_Session+0x3eb) [0x42cccb] 0x439f78: /usr/sbin/varnishd() [0x439f78] 0x43aff9: /usr/sbin/varnishd(SES_pool_accept_task+0x2a9) [0x43aff9] 0x434ab4: /usr/sbin/varnishd(Pool_Work_Thread+0xb4) [0x434ab4] 0x4477e8: /usr/sbin/varnishd() [0x4477e8] 0x7fb22aceef6e: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e) [0x7fb22aceef6e] 0x7fb22aa199cd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb22aa199cd] req = 0x7fb1e4106c10 { sp = 0x7fb1e803ce00, vxid = 1080526246, step = R_STP_FETCH, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fb1e803ce00 { fd = 142, vxid = 6784421, client = 172.18.80.5 1977, step = S_STP_WORKING, }, worker = 0x7fb2032ebc30 { ws = 0x7fb2032ebe40 { id = "wrk", {s,f,r,e} = {0x7fb2032eb420,0x7fb2032eb420,(nil),+2048}, }, VCL::method = 0x0, VCL::return = fetch, }, ws = 0x7fb1e4106da0 { id = "req", {s,f,r,e} = {0x7fb1e4108be0,+608,(nil),+57392}, }, http[req] = { ws = 0x7fb1e4106da0[req] "GET", "/2080/73282080/pics/3106286939_1_3_BqvX9uOx.png", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36", "Accept: image/webp,*/*;q=0.8", "Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4", "Host: auto.img.v4.skyrock.net", "Referer: http://mileydest-source.skyrock.com/tags/dhG8rmHt6C- Francia-Raisa.html", "X-Cluster-Client-Ip: XXXXXXXXXX", "Connection: keep-alive", "X-Forwarded-For: XXXXXXXX", "x-vc-backend: isilon", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 21 20:11:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Apr 2014 20:11:34 -0000 Subject: [Varnish] #1480: Porting guide for 4.0.0 is incomplete In-Reply-To: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> References: <048.01d65432deb4027b10ea9ff21fbabc0b@varnish-cache.org> Message-ID: <063.8259da8a46c185c6f43151f827103f91@varnish-cache.org> #1480: Porting guide for 4.0.0 is incomplete ---------------------------+--------------------- Reporter: falconindy | Owner: scoof Type: documentation | Status: closed Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Changes (by Andreas Plesner ): * status: new => closed * resolution: => fixed Comment: In [e7340a68ecf908968f4ffbb4ca4be24347348aae]: {{{ #!CommitTicketReference repository="" revision="e7340a68ecf908968f4ffbb4ca4be24347348aae" Add more changes. Fixes #1480 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 08:52:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 08:52:47 -0000 Subject: [Varnish] #1482: [PATCH]: initialize supplementary groups before setuid() In-Reply-To: <043.7500bf778f4b622e4f506463c4cbfca9@varnish-cache.org> References: <043.7500bf778f4b622e4f506463c4cbfca9@varnish-cache.org> Message-ID: <058.33648ca3f95d465c9e445ba074a789f6@varnish-cache.org> #1482: [PATCH]: initialize supplementary groups before setuid() -------------------------+---------------------------------------- Reporter: idl0r | Owner: Poul-Henning Kamp Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [3599490aed5524ea19a63cf488a60dc8ddb59365]: {{{ #!CommitTicketReference repository="" revision="3599490aed5524ea19a63cf488a60dc8ddb59365" One may have gcc or other things restricted, so that e.g. only a specific user and/or group may execute it. Varnish never inherited the groups of the user that has been specified by "-u". initgroups() will make sure that varnish gets all supplementary groups. Submitted by: Christian Ruppert Fixes #1482 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 08:55:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 08:55:49 -0000 Subject: [Varnish] #1481: directors vmod needs a simpler way to declare a massive set of backends In-Reply-To: <050.ce8e424d586f3d48f37721a6fc0adaf7@varnish-cache.org> References: <050.ce8e424d586f3d48f37721a6fc0adaf7@varnish-cache.org> Message-ID: <065.7f4f9c12c2ecc16884f06711a905cbea@varnish-cache.org> #1481: directors vmod needs a simpler way to declare a massive set of backends --------------------------+---------------------- Reporter: mattrobenolt | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: vmod | Version: 4.0.0 Severity: normal | Resolution: invalid Keywords: directors | --------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Moved to Wiki/Future_VCL, we use tickets only for bugs, not for enhancement requests. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 11:57:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 11:57:58 -0000 Subject: [Varnish] #1483: std.fileread can't handle files larger than 32kB Message-ID: <046.f994344d3b207a1697bfef2ba72a4d0c@varnish-cache.org> #1483: std.fileread can't handle files larger than 32kB ----------------------+-------------------- Reporter: kipusoep | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.5 | Severity: normal Keywords: fileread | ----------------------+-------------------- It seems the std.fileread function doesn't read files larger than approx. 32kB. When I try, I get '(null)' returned. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 13:03:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 13:03:34 -0000 Subject: [Varnish] #1483: std.fileread can't handle files larger than 32kB In-Reply-To: <046.f994344d3b207a1697bfef2ba72a4d0c@varnish-cache.org> References: <046.f994344d3b207a1697bfef2ba72a4d0c@varnish-cache.org> Message-ID: <061.67e87dc1d2e412be01c055256261c583@varnish-cache.org> #1483: std.fileread can't handle files larger than 32kB ----------------------+-------------------- Reporter: kipusoep | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: Keywords: fileread | ----------------------+-------------------- Comment (by kipusoep): I'm sorry, this isn't true. Because I was storing the contents inside an HTTP header, it was limited to 32kB. The problem is with this example: http://blog.tenya.me/blog/2012/06/25/varnish-3-dot-x-custom-error-pages/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 18:07:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 18:07:55 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.b748119a2654c5fa9ad05de122f8b052@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Comment (by jpotter): Just checking in on this -- is there anything I can do to assist? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 18:20:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 18:20:12 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.cc8b5210f975d91af8ede9b81f22f0a1@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Comment (by perbu): Installing docutils on a mac is basically $ sudo pip install docutils I don't see the problem. I suggest we close this as wontfix. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 18:22:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 18:22:41 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.5563c19c639e9f720d43c716e041ab90@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: wontfix Keywords: | ---------------------+---------------------------------- Changes (by perbu): * status: new => closed * resolution: => wontfix Comment: The reason for rst2man being mandatory can be found in e5516699439d560f5df326a55a427b3a9f2bdce5 Closing the ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 18:40:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 18:40:55 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.7ee309161ac79ef1fbfa8ab31f2136d2@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: reopened Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: Keywords: | ---------------------+---------------------------------- Changes (by perbu): * status: closed => reopened * resolution: wontfix => Comment: Not everyone is entirely on board with me closing this. Leaving it open, all though I have no idea why. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 20:45:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 20:45:24 -0000 Subject: [Varnish] #1463: Assert in cnt_lookup(), cache/cache_req_fsm.c line 417 In-Reply-To: <046.fcde1d88ee5a91a1b85a42bd45352ba0@varnish-cache.org> References: <046.fcde1d88ee5a91a1b85a42bd45352ba0@varnish-cache.org> Message-ID: <061.6df8f2a00210f0a7119e425106f4b13a@varnish-cache.org> #1463: Assert in cnt_lookup(), cache/cache_req_fsm.c line 417 ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by patrice): hit the bug today on 4.0.0 ubuntu packaged version : {{{ root at sc95:/etc# varnishd -V varnishd (varnish-4.0.0 revision 2acedeb) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS }}} {{{ varnish> panic.show 200 Last panic at: Tue, 22 Apr 2014 19:46:37 GMT Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. thread = (cache-worker) ident = Linux,3.11.0-12-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4325b5: /usr/sbin/varnishd() [0x4325b5] 0x4356f6: /usr/sbin/varnishd() [0x4356f6] 0x436001: /usr/sbin/varnishd(CNT_Request+0x841) [0x436001] 0x42cccb: /usr/sbin/varnishd(HTTP1_Session+0x3eb) [0x42cccb] 0x439f78: /usr/sbin/varnishd() [0x439f78] 0x43aff9: /usr/sbin/varnishd(SES_pool_accept_task+0x2a9) [0x43aff9] 0x434ab4: /usr/sbin/varnishd(Pool_Work_Thread+0xb4) [0x434ab4] 0x4477e8: /usr/sbin/varnishd() [0x4477e8] 0x7f1b25131f6e: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e) [0x7f1b25131f6e ] 0x7f1b24e5c9cd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f1b24e5c9cd] req = 0x7eb6edd8ac00 { sp = 0x7eb6b285ba10, vxid = 1155607705, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7eb6b285ba10 { fd = 117, vxid = 81865880, client = 172.19.80.3 29065, step = S_STP_WORKING, }, worker = 0x7eb6133b9c30 { ws = 0x7eb6133b9e40 { id = "wrk", {s,f,r,e} = {0x7eb6133b9420,0x7eb6133b9420,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7eb6edd8ad90 { id = "req", {s,f,r,e} = {0x7eb6edd8cbd0,+616,(nil),+57392}, }, http[req] = { ws = 0x7eb6edd8ad90[req] "GET", "/art/PRIP.82445706.3.0.jpg", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36", "Accept: image/webp,*/*;q=0.8", "Cache-Control: max-age=0", "Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4", "Host: auto.mgl.skyrock.net", "Referer: http://skyrock.com/m/messages/show_mess.php?id_thread=1520142875 &msg_sent=1&sent_from_thread=1", "X-Cluster-Client-Ip: XXXXX", "Connection: keep-alive", "X-Forwarded-For: 172.19.80.3", "x-vc-backend: mogilefs", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7ee2a6106000 { vxid = 2230887897, http[obj] = { ws = 0x7eb677d79d70[] "HTTP/1.1", "404", "Not Found", "Server: nginx", "Date: Tue, 22 Apr 2014 19:46:11 GMT", }, len = 1, store = { 1 { 0a |.| }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 22 23:15:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Apr 2014 23:15:11 -0000 Subject: [Varnish] #1483: std.fileread can't handle files larger than 32kB In-Reply-To: <046.f994344d3b207a1697bfef2ba72a4d0c@varnish-cache.org> References: <046.f994344d3b207a1697bfef2ba72a4d0c@varnish-cache.org> Message-ID: <061.451b71b53b947fa0701f4f99335da521@varnish-cache.org> #1483: std.fileread can't handle files larger than 32kB ----------------------+---------------------- Reporter: kipusoep | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: fileread | ----------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 23 12:17:37 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Apr 2014 12:17:37 -0000 Subject: [Varnish] #1484: Extra provides in 4.0.0 RPM packages Message-ID: <046.737980f5728501ca8500dd42baa96c66@varnish-cache.org> #1484: Extra provides in 4.0.0 RPM packages -----------------------+---------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: normal | Keywords: -----------------------+---------------------- [originally posted to varnish-dev@ by Ingvar Hagelund] I should have reported this by trac, but it is down at the moment. There are some serious build errors in the rpm packages of varnish-4.0.0 from the varnish-cache.org repository. Consider the following; varnish should _not_ provide things like libc.so.6, libncurses or /bin/bash !!! This breaks the rpm database. It should be fixed as soon as possible. {{{ $ rpm -qp --provides varnish-4.0.0-1.el6.x86_64.rpm /bin/bash /bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3)(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libedit.so.0()(64bit) libjemalloc.so.1()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libncurses.so.5()(64bit) libncursesw.so.5()(64bit) libnsl.so.1()(64bit) libpcre.so.0()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) libtinfo.so.5()(64bit) libvarnishapi.so.1()(64bit) libvarnishcompat.so()(64bit) libvarnish.so()(64bit) libvcc.so()(64bit) libvgz.so()(64bit) varnishabi-4.0.0-26c2dc6 varnish = 4.0.0-1.el6 varnish(x86-64) = 4.0.0-1.el6 }}} This is caused by a small typo/bug in redhat/find-provides. The script calls the system's find-requires. It should call find-provides. Also the correct path is /usr/lib/rpm/redhat/find-provides, from the redhat-rpm- config package on redhat and derivates, though the path in the script may be available by historical reasons, or perhaps for compatibility with other rpm based distributions. Fixing the script will fix the bug. This would also make the explicit provides of LIBVARNISHAPI for various versions unnecessary, so they should be removed as well. I proposed adding these as a workaround in an earlier trac bug, since I didn't catch the script bug in tp2+. That workaround was dropped in verbatim, though it was hard coded for 64bit, which is yet another bug, though only visible on 32bit systems. Since all this happens in the rpm package only, the easiest way out is fixing the script by adding a patch to the rpm, fixing those other bits, bump the rpm Release tag, and then you only need to roll new rpm packages. A complete release should no be necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 23 13:08:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Apr 2014 13:08:29 -0000 Subject: [Varnish] #1485: Background refetches update the text of the HTTP status line Message-ID: <046.82ae1761f1e8d39aaf5d255f6d846463@varnish-cache.org> #1485: Background refetches update the text of the HTTP status line ---------------------------------+---------------------- Reporter: smerrill | Type: defect Status: new | Priority: low Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: minor Keywords: | ---------------------------------+---------------------- Varnish 4 is an excellent release - thank you for everything. I have noticed one interesting issue. This example uses background refresh, and the simplified VCL is as follows, setting a short TTL for HTML pages but a long grace/keep interval to allow conditional background refreshes. {{{ sub vcl_backend_response { if (beresp.http.Content-Type ~ "text/html" && beresp.ttl > 0s) { set beresp.ttl = 1m; } set beresp.grace = 24h; set beresp.keep = 24h; } }}} This works extremely well, but after the backend sends a 304 in response to Varnish's conditional backend request, the text of the status line is updated to be "HTTP/1.1 200 Not Modified". {{{ $ curl -I -XGET -s http://192.168.168.168/ | egrep '(HTTP|Age)' HTTP/1.1 200 OK Age: 0 # Wait about two minutes, hit it again. $ curl -I -XGET -s http://192.168.168.168/ | egrep '(HTTP|Age)' HTTP/1.1 200 OK Age: 132 # Background conditional request is now triggered, hit it one more time. $ curl -I -XGET -s http://192.168.168.168/ | egrep '(HTTP|Age)' HTTP/1.1 200 Not Modified Age: 5 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 23 14:06:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Apr 2014 14:06:06 -0000 Subject: [Varnish] #1486: Failing assert in cnt_deliver(): (req->t_prev > req->obj->exp.t_origin) not true Message-ID: <046.030ba3bc8ce34cc41682649cfab69c4f@varnish-cache.org> #1486: Failing assert in cnt_deliver(): (req->t_prev > req->obj->exp.t_origin) not true ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Fryer ran into this assert on current master: 35308a3c975ce3bd3690fe3afa4f25bb78b887e5 {{{ Last panic at: Wed, 23 Apr 2014 00:43:26 GMT Assert error in cnt_deliver(), cache/cache_req_fsm.c line 121: Condition(req->t_prev > req->obj->exp.t_origin) not true. thread = (cache-worker) ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43b31f: pan_backtrace+0x19 0x43b630: pan_ic+0x1e9 0x43e5b4: cnt_deliver+0x50b 0x441b2c: CNT_Request+0x529 0x434475: HTTP1_Session+0x427 0x444a07: ses_req_pool_task+0x166 0x444cd2: ses_sess_pool_task+0x23b 0x445271: SES_pool_accept_task+0x1f9 0x43d2a4: Pool_Work_Thread+0x416 0x455e20: wrk_thread_real+0x204 req = 0x7fccdc060a00 { sp = 0x7fccd80014b0, vxid = 1075189378, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fccd80014b0 { fd = 22, vxid = 1447553, client = 194.31.39.161 56800, step = S_STP_WORKING, }, worker = 0x7fccf9d2dc60 { ws = 0x7fccf9d2de70 { id = "wrk", {s,f,r,e} = {0x7fccf9d2d410,0x7fccf9d2d410,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7fccdc060b90 { id = "req", {s,f,r,e} = {0x7fccdc0629d0,+296,(nil),+57392}, }, http[req] = { ws = 0x7fccdc060b90[req] "GET", "/cacheabledata/set_imagehosting1/0/image13790.jpg", "HTTP/1.1", "Host: fryer1.varnish-software.com:6081", "Accept: */*", "Accept-Encoding: gzip", "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4", "Connection: close", "X-Forwarded-For: 194.31.39.161", }, http[resp] = { ws = 0x7fccdc060b90[req] "HTTP/1.1", "200", "OK", "Date: Wed, 23 Apr 2014 00:43:25 GMT", "Server: Apache/2.2.22 (Ubuntu)", "Last-Modified: Mon, 26 Aug 2013 14:11:34 GMT", "ETag: "824156-1af8-4e4da5578d683"", "Content-Type: image/jpeg", "X-Varnish: 1447554 2039678", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7fcc6c62e640 { vxid = 2149523326, http[obj] = { ws = 0x7fcce4050c18[] "HTTP/1.1", "200", "OK", "Date: Wed, 23 Apr 2014 00:43:25 GMT", "Server: Apache/2.2.22 (Ubuntu)", "Last-Modified: Mon, 26 Aug 2013 14:11:34 GMT", "ETag: "824156-1af8-4e4da5578d683"", "Content-Type: image/jpeg", }, len = 6904, store = { 6904 { 00 00 00 af 9a be b0 41 00 00 80 8a ae a3 e3 41 |.......A.......A| 00 00 80 76 65 db cc 41 00 00 00 b8 e4 0d 9b 41 |...ve..A.......A| 00 00 80 e6 a8 5b cb 41 00 00 20 f2 1d 1d e4 41 |.....[.A.. ....A| 00 00 20 6f e7 88 e0 41 00 00 c0 94 34 87 d3 41 |.. o...A....4..A| [6840 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 24 16:28:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Apr 2014 16:28:28 -0000 Subject: [Varnish] #1473: Can't build on OS X because of rst2man/python-docutils requirement In-Reply-To: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> References: <045.626d2c7638c2ad5b34ea3014b07fba54@varnish-cache.org> Message-ID: <060.8ccba5df7edbdb8c1f00c6653a18520f@varnish-cache.org> #1473: Can't build on OS X because of rst2man/python-docutils requirement ---------------------+---------------------------------- Reporter: jpotter | Owner: fgsch Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0 release Component: build | Version: 4.0.0 Severity: major | Resolution: fixed Keywords: | ---------------------+---------------------------------- Changes (by Tollef Fog Heen ): * status: reopened => closed * resolution: => fixed Comment: In [06ba9c2ae51c5496ae2fc322f4d3543f0894479b]: {{{ #!CommitTicketReference repository="" revision="06ba9c2ae51c5496ae2fc322f4d3543f0894479b" Error when no rst2man is found If one runs configure with --without-rst2man or no rst2man is found, the value is "no", not an empty string. Handle this correctly in configure. Fixes: #1473 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 25 10:36:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Apr 2014 10:36:16 -0000 Subject: [Varnish] #1447: Panic message: Assert error in http_Write In-Reply-To: <046.4d292c524c5bcf6e4c46bbf1ff236ca0@varnish-cache.org> References: <046.4d292c524c5bcf6e4c46bbf1ff236ca0@varnish-cache.org> Message-ID: <061.b682a7183a2aa6b59980cfefa85dbee4@varnish-cache.org> #1447: Panic message: Assert error in http_Write -------------------------------------+---------------------- Reporter: scorillo | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: major | Resolution: invalid Keywords: panic assert http_write | -------------------------------------+---------------------- Comment (by scorillo): The problem was the workspace allocated for worker threads (thread_pool_workspace). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 25 13:50:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Apr 2014 13:50:42 -0000 Subject: [Varnish] #1486: Failing assert in cnt_deliver(): (req->t_prev > req->obj->exp.t_origin) not true In-Reply-To: <046.030ba3bc8ce34cc41682649cfab69c4f@varnish-cache.org> References: <046.030ba3bc8ce34cc41682649cfab69c4f@varnish-cache.org> Message-ID: <061.acc807a96e7dae7f8eb237e65f86fd96@varnish-cache.org> #1486: Failing assert in cnt_deliver(): (req->t_prev > req->obj->exp.t_origin) not true ----------------------+----------------------------------------------- Reporter: lkarsten | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [e258ca15604b210aad3d70960eccd21fce645778]: {{{ #!CommitTicketReference repository="" revision="e258ca15604b210aad3d70960eccd21fce645778" Remove negative Age assertion and truncate to zero instead. The Age reported on response objects is calculated from the last request timestamp taken. For a cache hit that hasn't been on a waitinglist, that will be the Start timestamp. This opens a race where the requests' last timestamp could be before the objects t_origin. Truncate the Age to zero rather than assert in that case. Fixes: #1486 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 25 13:50:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Apr 2014 13:50:42 -0000 Subject: [Varnish] #1485: Background refetches update the text of the HTTP status line In-Reply-To: <046.82ae1761f1e8d39aaf5d255f6d846463@varnish-cache.org> References: <046.82ae1761f1e8d39aaf5d255f6d846463@varnish-cache.org> Message-ID: <061.81d7018077e6fc8f752ab088929f16c1@varnish-cache.org> #1485: Background refetches update the text of the HTTP status line ----------------------+----------------------------------------------- Reporter: smerrill | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: low | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [e04394c7205547193d188ca5d18e8361e57c838d]: {{{ #!CommitTicketReference repository="" revision="e04394c7205547193d188ca5d18e8361e57c838d" Copy the status code, proto, status string and response message on backend IMS. When revalidating using backend IMS, copy the status code, status code, status string and response message from the original object into the new revalidated object. This makes sure that none of the 304 message fields gets applied to the new revalidated object. Fixes: #1485 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 27 11:50:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 27 Apr 2014 11:50:55 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.5f8b53cb138884ddb483348af25c0185@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+------------------------ Reporter: basile@? | Owner: scoof Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Changes (by fgsch): * status: new => Need info Comment: basile, what are the steps you have used to get these errors? I got plenty more issues when I tested it myself. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 27 11:52:32 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 27 Apr 2014 11:52:32 -0000 Subject: [Varnish] #1457: vcl.show should expand includes In-Reply-To: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> References: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> Message-ID: <058.644516778dd9f9976f91ffd2aeab885d@varnish-cache.org> #1457: vcl.show should expand includes ----------------------+---------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Comment (by fgsch): I think this should be marked as enhancement. Not really a defect IMO. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 27 13:11:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 27 Apr 2014 13:11:44 -0000 Subject: [Varnish] #1487: VCL flow outdated Message-ID: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> #1487: VCL flow outdated ---------------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: low | Milestone: Component: documentation | Version: unknown Severity: normal | Keywords: ---------------------------+--------------------- VCL flow details in cache_req_fsm.c needs to be updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 27 13:12:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 27 Apr 2014 13:12:01 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.347aa5e21db537ae1f80e702e29201fe@varnish-cache.org> #1487: VCL flow outdated ---------------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by fgsch): * version: unknown => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 27 16:19:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 27 Apr 2014 16:19:30 -0000 Subject: [Varnish] #1457: vcl.show should expand includes In-Reply-To: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> References: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> Message-ID: <058.4944e522e09331e9bd780c96cfec874d@varnish-cache.org> #1457: vcl.show should expand includes ----------------------+---------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Comment (by slink): I had created this ticket at the last VDD because someone (phk?) had asked for it -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 07:01:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 07:01:13 -0000 Subject: [Varnish] #1488: Panic at high volume of requests Message-ID: <050.be207582b57e02e98588e0c64eccd40e@varnish-cache.org> #1488: Panic at high volume of requests --------------------------+-------------------- Reporter: mattrobenolt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: panic | --------------------------+-------------------- Caused Varnish to panic when benchmarking with ~30k+ rps. {{{ varnish> panic.show 200 Last panic at: Fri, 25 Apr 2014 23:12:11 GMT Assert error in WRW_Write(), cache/cache_wrw.c line 255: Condition((wrk) != NULL) not true. thread = (cache-worker) ident = Linux,3.13.0-24-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4325b5: /usr/sbin/varnishd() [0x4325b5] 0x4484da: /usr/sbin/varnishd(WRW_Write+0x12a) [0x4484da] 0x438046: /usr/sbin/varnishd() [0x438046] 0x438655: /usr/sbin/varnishd() [0x438655] 0x438e58: /usr/sbin/varnishd(V1D_Deliver+0x4f8) [0x438e58] 0x435b77: /usr/sbin/varnishd(CNT_Request+0x3b7) [0x435b77] 0x42cccb: /usr/sbin/varnishd(HTTP1_Session+0x3eb) [0x42cccb] 0x439f78: /usr/sbin/varnishd() [0x439f78] 0x434ab4: /usr/sbin/varnishd(Pool_Work_Thread+0xb4) [0x434ab4] 0x4477e8: /usr/sbin/varnishd() [0x4477e8] req = 0x7f99f0072ad0 { sp = 0x7f99f0028670, vxid = 1075054490, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f99f0028670 { fd = 475, vxid = 9207815, client = 127.0.0.1 32303, step = S_STP_WORKING, }, ws = 0x7f99f0072c60 { id = "req", {s,f,r,e} = {0x7f99f0074aa0,+384,(nil),+57392}, }, http[req] = { ws = 0x7f99f0072c60[req] "GET", "/embed/comments/090849", "HTTP/1.1", "Host: 127.0.0.1:6081", "X-Forwarded-For: 127.0.0.1, 127.0.0.1", "Accept-Encoding: gzip", }, http[resp] = { ws = 0x7f99f0072c60[req] "HTTP/1.1", "200", "OK", "Cache-Control: max-age=3600", "Content-Encoding: gzip", "Content-Type: text/html", "Grace: max-age=3600", "X-Accel-Expires: 15", "Date: Fri, 25 Apr 2014 23:12:09 GMT", "X-Varnish: 1312666 11600334", "Age: 0", "Via: 1.1 varnish (v4)", "X-Served-By: test-shield-1.dal01", "X-Cache: HIT", "X-Cache-Hits: 10", "Transfer-Encoding: chunked", "Connection: keep-alive", "Accept-Ranges: bytes", }, vcl = { srcname = { "input", "Builtin", "includes/x-forwarded-for.vcl", "includes/recv-common.vcl", "includes/surrogate-control.vcl", "includes/grace.vcl", "includes/health-synthetic.vcl", "includes/x-served-by.vcl", }, }, obj (REQ) = 0x7f9b60269e40 { vxid = 2159083982, http[obj] = { ws = 0x7f9b0c010f40[obj] "HTTP/1.1", "200", "OK", "Cache-Control: max-age=3600", "Content-Encoding: gzip", "Content-Type: text/html", "Grace: max-age=3600", "X-Accel-Expires: 15", "Date: Fri, 25 Apr 2014 23:12:09 GMT", }, len = 15210, store = { 15210 { 1f 8b 08 00 00 09 6e 88 00 ff ec 7d 79 77 1b c7 |......n....}yw..| b1 ef ff fe 14 6d e4 9e e7 dc fb b0 cc be e0 52 |.....m.........R| d4 a3 64 2d 94 65 4b 91 18 2b 4e 94 a3 33 98 69 |..d-.eK..+N..3.i| 00 63 ce 82 cc 42 0a ce c9 77 7f bf ea 1e 2c c4 |.c...B...w....,.| [15146 more] }, }, }, }, }}} I'll be happy to supply any other information you may need. Not sure what else is relevant beyond this panic. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 07:40:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 07:40:25 -0000 Subject: [Varnish] #1488: Panic at high volume of requests In-Reply-To: <050.be207582b57e02e98588e0c64eccd40e@varnish-cache.org> References: <050.be207582b57e02e98588e0c64eccd40e@varnish-cache.org> Message-ID: <065.60d1824ba766bcd6aa27a27d858a7804@varnish-cache.org> #1488: Panic at high volume of requests --------------------------+-------------------- Reporter: mattrobenolt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: panic | --------------------------+-------------------- Changes (by lkarsten): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 08:05:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 08:05:42 -0000 Subject: [Varnish] #1489: Assert error to use the req.esi in vcl_backend_response Message-ID: <042.544224d58ec168f451ee901a1162679e@varnish-cache.org> #1489: Assert error to use the req.esi in vcl_backend_response -------------------+---------------------- Reporter: xcir | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | -------------------+---------------------- Hi, I found the req.esi that can be accessed by vcl_backend_response in lib/libvcc/generate.py I tried it, only to fail. {{{ vcl 4.0; import directors; import std; backend default { .host = "192.168.1.199";.port = "88";} sub vcl_backend_response{ std.log("req.esi" + req.esi); } }}} {{{ Last panic at: Mon, 28 Apr 2014 07:16:53 GMT Assert error in VRT_r_req_esi(), cache/cache_vrt_var.c line 388: Condition((ctx->req) != NULL) not true. thread = (cache-worker) ident = Linux,3.2.0-60-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4325b5: /usr/sbin/varnishd() [0x4325b5] 0x4454b0: /usr/sbin/varnishd(VRT_r_req_esi+0xb0) [0x4454b0] 0x7f678adede4a: ./vcl.9MoGK6Nv.so(VGC_function_vcl_backend_response+0x2a) [0x7f678adede4a] 0x43e348: /usr/sbin/varnishd() [0x43e348] 0x43f658: /usr/sbin/varnishd(VCL_backend_response_method+0x48) [0x43f658] 0x4209a3: /usr/sbin/varnishd() [0x4209a3] 0x434ab4: /usr/sbin/varnishd(Pool_Work_Thread+0xb4) [0x434ab4] 0x4477e8: /usr/sbin/varnishd() [0x4477e8] 0x7f67a3f9ae9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f67a3f9ae9a] 0x7f67a3cc73fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f67a3cc73fd] busyobj = 0x7f6778010cf0 { ws = 0x7f6778010db8 { id = "bo", {s,f,r,e} = {0x7f6778012cc0,+440,(nil),+57392}, }, refcnt = 2 retries = 0 failed = 0 state = 1 is_do_stream is_should_close bodystatus = 3 (length), }, http[bereq] = { ws = 0x7f6778010db8[bo] "GET", "/date2.php", "HTTP/1.1", "User-Agent: Wget/1.12 (linux-gnu)", "Accept: */*", "Host: 192.168.1.45", "X-Forwarded-For: 192.168.1.199", "Accept-Encoding: gzip", "X-Varnish: 3", }, http[beresp] = { ws = 0x7f6778010db8[bo] "HTTP/1.1", "200", "OK", "Date: Mon, 28 Apr 2014 07:00:27 GMT", "Server: Apache/2.2.15 (Scientific Linux)", "X-Powered-By: PHP/5.3.2", "Cache-Control: no-store", "Content-Length: 20", "Connection: close", "Content-Type: text/html; charset=UTF-8", }, ws = 0x7f6778010f40 { BAD_MAGIC(0x00000000) }, }, objcore (FETCH) = 0x7f6778010b10 { refcnt = 2 flags = 0x2 objhead = 0x7f6778010ba0 } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 10:08:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 10:08:33 -0000 Subject: [Varnish] #1457: vcl.show should expand includes In-Reply-To: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> References: <043.f14786107b6d266ced5da4fa3a4b15af@varnish-cache.org> Message-ID: <058.a2de5625cfcdacb062e4e8bd757b5b34@varnish-cache.org> #1457: vcl.show should expand includes ----------------------+---------------------- Reporter: slink | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Changes (by lkarsten): * owner: => daghf Comment: Dag has been working on this. Assigning to him. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 12:31:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 12:31:44 -0000 Subject: [Varnish] #1490: Is not release destroyed thread Message-ID: <042.e0788bb7b0c6545200090cf88772c403@varnish-cache.org> #1490: Is not release destroyed thread -------------------+---------------------- Reporter: xcir | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | -------------------+---------------------- Hi, I'm testing Varnish4 on my site. I noticed the thread is to continue to increase. {{{ [root at gw02 varnish]# ps aux -L|grep varnish|wc -l 1702 [root at gw02 varnish]# varnishstat -1|grep threads MAIN.threads 200 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 1678 0.00 Threads created MAIN.threads_destroyed 1478 0.00 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed }}} How to reproduce(artificially). And my log. {{{ root at varnish4:~# varnishd -V varnishd (varnish-4.0.0 revision 2acedeb) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS root at varnish4:~# uname -a Linux varnish4 3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux root at varnish4:~# /etc/init.d/varnish restart * Stopping HTTP accelerator varnishd ...done. * Starting HTTP accelerator varnishd ...done. root at varnish4:~# varnishadm param.set thread_pool_timeout 10 root at varnish4:~# varnishadm param.show|grep thread cc_command "exec gcc -std=gnu99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wall -Werror -Wno- error=unused-result -pthread -fpic -shared -Wl,-x -o %o %s" (default) thread_pool_add_delay 0.000 [seconds] (default) thread_pool_destroy_delay 1.000 [seconds] (default) thread_pool_fail_delay 0.200 [seconds] (default) thread_pool_max 5000 [threads] (default) thread_pool_min 100 [threads] (default) thread_pool_stack 48k [bytes] (default) thread_pool_timeout 10.000 [seconds] thread_pools 2 [pools] (default) thread_queue_limit 20 (default) thread_stats_rate 10 [requests] (default) workspace_thread 2k [bytes] (default) root at varnish4:~# varnishstat -1|grep thread MAIN.pools 2 . Number of thread pools MAIN.threads 200 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 200 3.03 Threads created MAIN.threads_destroyed 0 0.00 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed MAIN.thread_queue_len 0 . Length of session queue MAIN.sess_queued 0 0.00 Sessions queued for thread MAIN.sess_dropped 0 0.00 Sessions dropped for thread MAIN.exp_mailed 0 0.00 Number of objects mailed to expiry thread MAIN.exp_received 0 0.00 Number of objects received by expiry thread root at varnish4:~# ps aux -L |grep varnishd|grep nobody|wc -l 217 root at varnish4:~# varnishadm param.set thread_pool_min 5 root at varnish4:~# varnishadm param.show|grep thread cc_command "exec gcc -std=gnu99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wall -Werror -Wno- error=unused-result -pthread -fpic -shared -Wl,-x -o %o %s" (default) thread_pool_add_delay 0.000 [seconds] (default) thread_pool_destroy_delay 1.000 [seconds] (default) thread_pool_fail_delay 0.200 [seconds] (default) thread_pool_max 5000 [threads] (default) thread_pool_min 5 [threads] thread_pool_stack 48k [bytes] (default) thread_pool_timeout 10.000 [seconds] thread_pools 2 [pools] (default) thread_queue_limit 20 (default) thread_stats_rate 10 [requests] (default) workspace_thread 2k [bytes] (default) root at varnish4:~# varnishstat -1|grep thread MAIN.pools 2 . Number of thread pools MAIN.threads 10 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 200 0.90 Threads created MAIN.threads_destroyed 190 0.85 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed MAIN.thread_queue_len 0 . Length of session queue MAIN.sess_queued 0 0.00 Sessions queued for thread MAIN.sess_dropped 0 0.00 Sessions dropped for thread MAIN.exp_mailed 0 0.00 Number of objects mailed to expiry thread MAIN.exp_received 0 0.00 Number of objects received by expiry thread root at varnish4:~# ps aux -L |grep varnishd|grep nobody|wc -l 217 ##is not release root at varnish4:~# varnishadm param.set thread_pool_min 200 root at varnish4:~# varnishstat -1|grep thread MAIN.pools 2 . Number of thread pools MAIN.threads 400 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 590 2.09 Threads created MAIN.threads_destroyed 190 0.67 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed MAIN.thread_queue_len 0 . Length of session queue MAIN.sess_queued 0 0.00 Sessions queued for thread MAIN.sess_dropped 0 0.00 Sessions dropped for thread MAIN.exp_mailed 0 0.00 Number of objects mailed to expiry thread MAIN.exp_received 0 0.00 Number of objects received by expiry thread root at varnish4:~# ps aux -L |grep varnishd|grep nobody|wc -l 607 root at varnish4:~# varnishadm param.set thread_pool_min 5 root at varnish4:~# varnishstat -1|grep thread MAIN.pools 2 . Number of thread pools MAIN.threads 10 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 590 1.09 Threads created MAIN.threads_destroyed 580 1.07 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed MAIN.thread_queue_len 0 . Length of session queue MAIN.sess_queued 0 0.00 Sessions queued for thread MAIN.sess_dropped 0 0.00 Sessions dropped for thread MAIN.exp_mailed 0 0.00 Number of objects mailed to expiry thread MAIN.exp_received 0 0.00 Number of objects received by expiry thread root at varnish4:~# ps aux -L |grep varnishd|grep nobody|wc -l 607 root at varnish4:~# varnishadm param.set thread_pool_min 200 root at varnish4:~# varnishstat -1|grep thread MAIN.pools 2 . Number of thread pools MAIN.threads 400 . Total number of threads MAIN.threads_limited 0 0.00 Threads hit max MAIN.threads_created 980 1.73 Threads created MAIN.threads_destroyed 580 1.02 Threads destoryed MAIN.threads_failed 0 0.00 Thread creation failed MAIN.thread_queue_len 0 . Length of session queue MAIN.sess_queued 0 0.00 Sessions queued for thread MAIN.sess_dropped 0 0.00 Sessions dropped for thread MAIN.exp_mailed 0 0.00 Number of objects mailed to expiry thread MAIN.exp_received 0 0.00 Number of objects received by expiry thread root at varnish4:~# ps aux -L |grep varnishd|grep nobody|wc -l 997 root at varnish4:~# ps aux -L |grep varnishd|grep nobody nobody 28377 28377 0.0 997 4.6 1086176 91840 ? Sl 20:46 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 28378 0.0 997 4.6 1086176 91840 ? Sl 20:46 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 28379 0.0 997 4.6 1086176 91840 ? Sl 20:46 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m ... nobody 28377 28592 0.0 997 4.6 1086176 91840 ? Sl 20:46 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 28593 0.0 997 4.6 1086176 91840 ? Sl 20:46 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 28856 0.0 997 4.6 1086176 91840 ? Sl 20:51 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 28855 0.0 997 4.6 1086176 91840 ? Sl 20:51 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m ... nobody 28377 29242 0.0 997 4.6 1086176 91840 ? Sl 20:51 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 29243 0.0 997 4.6 1086176 91840 ? Sl 20:51 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 29244 0.0 997 4.6 1086176 91840 ? Sl 20:51 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 29656 0.0 997 4.6 1086176 91840 ? Sl 20:55 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m nobody 28377 29657 0.0 997 4.6 1086176 91840 ? Sl 20:55 0:00 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m ... }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 28 13:27:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Apr 2014 13:27:02 -0000 Subject: [Varnish] #1488: Panic at high volume of requests In-Reply-To: <050.be207582b57e02e98588e0c64eccd40e@varnish-cache.org> References: <050.be207582b57e02e98588e0c64eccd40e@varnish-cache.org> Message-ID: <065.f2be171a36fa341d7187ce9b2ad19310@varnish-cache.org> #1488: Panic at high volume of requests --------------------------+----------------------------------------------- Reporter: mattrobenolt | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: panic | --------------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [94a3d071b66d4f7aa7f94660cad42e4d58f25724]: {{{ #!CommitTicketReference repository="" revision="94a3d071b66d4f7aa7f94660cad42e4d58f25724" Close race on req->wrk clearing introduced in 6f2e1bcd The disembarking thread would clear the req->wrk pointer in CNT_Request. The req could have already been rescheduled on another worker at this point, causing the req->wrk to be cleared while processing. Change back to not clearing the pointer for REQ_FSM_DISEMBARK (it's already been done under mutex in HSH_Lookup anyways). Fixes: #1488 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 30 11:52:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Apr 2014 11:52:38 -0000 Subject: [Varnish] #1490: Is not release destroyed thread In-Reply-To: <042.e0788bb7b0c6545200090cf88772c403@varnish-cache.org> References: <042.e0788bb7b0c6545200090cf88772c403@varnish-cache.org> Message-ID: <057.8d97aa17a5b64e1c834077839a3907b8@varnish-cache.org> #1490: Is not release destroyed thread ----------------------+-------------------- Reporter: xcir | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Nicely spotted :) Attached patch with test case. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 30 14:00:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Apr 2014 14:00:30 -0000 Subject: [Varnish] #1489: Assert error to use the req.esi in vcl_backend_response In-Reply-To: <042.544224d58ec168f451ee901a1162679e@varnish-cache.org> References: <042.544224d58ec168f451ee901a1162679e@varnish-cache.org> Message-ID: <057.c3aab783aa381a6d9b3af33f0946d0fb@varnish-cache.org> #1489: Assert error to use the req.esi in vcl_backend_response ----------------------+----------------------------------------------- Reporter: xcir | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [9aa6eef5b2f37f2197ff70bb41e74705b83f80eb]: {{{ #!CommitTicketReference repository="" revision="9aa6eef5b2f37f2197ff70bb41e74705b83f80eb" Fix up req.esi to only be available in client context. Fixes: #1489 Spotted by: xcir }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator