From varnish-bugs at varnish-cache.org Thu Jul 1 00:11:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Jul 2010 00:11:41 -0000 Subject: [Varnish] #698: High load after upgrade from 2.1.0 to 2.1.2 In-Reply-To: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org> References: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org> Message-ID: <061.a35fa1fe385dc65117cf7776e5e970dc@varnish-cache.org> #698: High load after upgrade from 2.1.0 to 2.1.2 -----------------------------+---------------------------------------------- Reporter: lukasz.jagiello | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Comment(by diegomontoya): Also confirmed very high cpu usage for varnish using critbit hash, as compared to classic hash, after cache is warmed with 100k plus of smallish (<100KB) objects. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 1 17:39:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Jul 2010 17:39:10 -0000 Subject: [Varnish] #731: Can't remove illegal header without terminal colon Message-ID: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> #731: Can't remove illegal header without terminal colon -------------------+-------------------------------------------------------- Reporter: slink | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I needed to find a server-side solution for a broken client which constructs malformed requests with a carriage return after the URI like {{{ GET URI\r HTTP/1.1 }}} After parsing this request with http_splitline, we get an illegal header {{{ HTTP/1.1 }}} which I would like to remove in a VCL. This rightly can't be done in VCL- code alone, but I would like to use the following inline C-Code to remove it: {{{ C{ VRT_SetHdr(sp, HDR_REQ, "\011 HTTP/1.1", 0); }C }}} which triggers a failed assertion in http_IsHdr due to the missing colon, so this is a request to remove the respective assertion. Yes,I know this is somewhere between a defect and an enhancement, I hope a ticket is the right place for it. Thank you, Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 06:33:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 06:33:27 -0000 Subject: [Varnish] #732: Varnish apparently does not allow for cross compiling Message-ID: <043.4a11dbf6026761e50f72455b6dc4a0cd@varnish-cache.org> #732: Varnish apparently does not allow for cross compiling --------------------+------------------------------------------------------- Reporter: ccrumb | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- Was going to try cross compiling Varnish for ARM and did the following: ./configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi Ended up with a message: checking whether SO_RCVTIMEO works... configure: error: cannot run test program while cross compiling Is there any particular reason not to allow/support cross compilation? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 11:35:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 11:35:31 -0000 Subject: [Varnish] #700: Response Reason-Phrase can contain SP In-Reply-To: <042.348b46dfda00d59b349769e65b19cd10@varnish-cache.org> References: <042.348b46dfda00d59b349769e65b19cd10@varnish-cache.org> Message-ID: <051.17d95d675f9b4a12fcb94bab984d0b57@varnish-cache.org> #700: Response Reason-Phrase can contain SP ---------------------+------------------------------------------------------ Reporter: slink | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by tfheen): (In [5023]) Merge r4829: Allow TAB in the 3rd field of the first line of HTTP requests and responses. Fixes: #700 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 11:58:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 11:58:26 -0000 Subject: [Varnish] #704: Incorrect Range support for the last n bytes In-Reply-To: <040.af42aa00b4b49c6c36e4d5aa07ff066f@varnish-cache.org> References: <040.af42aa00b4b49c6c36e4d5aa07ff066f@varnish-cache.org> Message-ID: <049.38405ab169f34d2524a944fba91e00ad@varnish-cache.org> #704: Incorrect Range support for the last n bytes ---------------------+------------------------------------------------------ Reporter: luc | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by tfheen): (In [5025]) Merge r4866: Make bytes=-100 work I have no idea how I overlooked that a "bytes=-100" range was from the end of the object, but I did. Fixes #704. Reported by: Luc Saillard -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 12:22:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 12:22:16 -0000 Subject: [Varnish] #681: problems using regular expressions with varnishlog In-Reply-To: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org> References: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org> Message-ID: <059.d4506eb5a43eb13c26e4a01a7524baa3@varnish-cache.org> #681: problems using regular expressions with varnishlog --------------------------------------------+------------------------------- Reporter: danielpicolli | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishlog | Version: Severity: critical | Resolution: fixed Keywords: regular expressions varnishlog | --------------------------------------------+------------------------------- Comment(by tfheen): (In [5027]) Merge r4981: Typo in -X matching in varnishapi Fixes: #681 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 12:44:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 12:44:44 -0000 Subject: [Varnish] #709: After SessionClose c EOF there is a second ReqEnd c 0 In-Reply-To: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org> References: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org> Message-ID: <051.dbc6940c48b8f0e6660788674f1a9c76@varnish-cache.org> #709: After SessionClose c EOF there is a second ReqEnd c 0 ----------------------+----------------------------------------------------- Reporter: jdzst | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5028]) Merge r4980: Emit Length for client side right before ReqEnd, to summarize ESI transactions correctly. Only emit Length and ReqEnd if we have an XID. Fixes: #709 Fixes: #720 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 12:44:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 12:44:44 -0000 Subject: [Varnish] #720: esi confuses varnishncsa In-Reply-To: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org> References: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org> Message-ID: <050.285b4d1cdbfb52b7db35b7fc2f2a0ca3@varnish-cache.org> #720: esi confuses varnishncsa ---------------------+------------------------------------------------------ Reporter: knan | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 2.1.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by tfheen): (In [5028]) Merge r4980: Emit Length for client side right before ReqEnd, to summarize ESI transactions correctly. Only emit Length and ReqEnd if we have an XID. Fixes: #709 Fixes: #720 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 6 13:19:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Jul 2010 13:19:28 -0000 Subject: [Varnish] #719: Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c line 634 In-Reply-To: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org> References: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org> Message-ID: <054.9583491eb0d417523e10c6eed54e48a5@varnish-cache.org> #719: Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c line 634 ----------------------+----------------------------------------------------- Reporter: tseliger | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5030]) Merge r4743, r4744, r4745: ESI panic when element spans malloc segments r4973: Use WSP instead of VSL for ordering and performance r4974: Minor nitpicking r4975: Fix a bug when ESI elements span storage elements, which only the tightfisted -smalloc would trigger. Fixes: #719 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 12 14:06:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Jul 2010 14:06:01 -0000 Subject: [Varnish] #733: Content-Length set to 0 when no Content-Length headers is set Message-ID: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org> #733: Content-Length set to 0 when no Content-Length headers is set ----------------------+----------------------------------------------------- Reporter: zab | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.2 Severity: blocker | Keywords: ----------------------+----------------------------------------------------- In my current config, Varnish have only one backend (a caching server). When trying to get a specific URL from the cache through Varnish, it always set the header "Content-Length: 0" for it before sending it back to Firefox. Inside the cache, this URL has no "Content-Length" header as you can see: 1) CACHE BACKEND ---> VARNISH ----------------------------------------------------- HTTP/1.1 200 OK Date: Tue, 15 Jun 2010 09:18:29 GMT Content-Type: text/html; charset=UTF-8 X-Powered-By: ASP.NET Set-Cookie: jsessionid=XXXXXXXXXXXXXXXXXXX; path=/ [payload] 2) VARNISH ----> FIREFOX ----------------------------------------- Content-Type text/html; charset=UTF-8 X-Powered-By ASP.NET Set-Cookie jsessionid=XXXXXXXXXXXXXXXXXXX; path=/ Content-Length 0 Date Mon, 12 Jul 2010 10:11:06 GMT X-Varnish 353742751 Age 0 Via 1.1 varnish [payload] N.B: getting this URL directly from the cache (i.e without using Varnish) works perfectly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 13 09:03:17 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Jul 2010 09:03:17 -0000 Subject: [Varnish] #722: Director cleanup issue on vcl.discard In-Reply-To: <040.72efccced4c789e3b09e4a32f5ead9b1@varnish-cache.org> References: <040.72efccced4c789e3b09e4a32f5ead9b1@varnish-cache.org> Message-ID: <049.16048659c674da3efe7670117ab92f32@varnish-cache.org> #722: Director cleanup issue on vcl.discard ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5040]) Merge r4967: Fix a problem in director teardown at vcl.discard time We didn't create/destroy directors and backends in a consistent order, and in some case we even destroyed directors more than once. Always destroy in opposite order of creation (which follows VCL source order). Turn the bottom element of the array into (only) an indication of which backend/director is the default. Fixes: #722 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 16 09:54:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Jul 2010 09:54:35 -0000 Subject: [Varnish] #734: Random objects from memory mixed with requested object Message-ID: <040.94a77bcdbeef74b0fe461382be5b20be@varnish-cache.org> #734: Random objects from memory mixed with requested object ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: major | Keywords: ----------------------+----------------------------------------------------- Varnish 2.1.1, Linux, amd64. All varnish instances in the cluster sometimes send what seems to be parts of random objects from memory interspersed with the requested object. We don't use ESI. I have a sample file that was served, which consists of: - parts of 6 JPEGs - headers from ~40 objects - the original HTML, garbled. It is hard to reproduce and I don't have specific steps at this time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 16 16:46:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Jul 2010 16:46:14 -0000 Subject: [Varnish] #734: Random objects from memory mixed with requested object In-Reply-To: <040.94a77bcdbeef74b0fe461382be5b20be@varnish-cache.org> References: <040.94a77bcdbeef74b0fe461382be5b20be@varnish-cache.org> Message-ID: <049.ab8b6c2ffe557db7c19a3c0ed0dc689a@varnish-cache.org> #734: Random objects from memory mixed with requested object ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: major | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Please update to 2.1.2, this is a known bug in 2.1.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 16 17:42:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Jul 2010 17:42:44 -0000 Subject: [Varnish] #734: Random objects from memory mixed with requested object In-Reply-To: <040.94a77bcdbeef74b0fe461382be5b20be@varnish-cache.org> References: <040.94a77bcdbeef74b0fe461382be5b20be@varnish-cache.org> Message-ID: <049.0aec74154f562a9ef67011e55c827928@varnish-cache.org> #734: Random objects from memory mixed with requested object ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: major | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Comment(by tgr): Are you sure? 2.1.2 release notes say: "This bug which would append garbage to objects larger than the chunk size, by default 128k. This only affects content transfered with chunked encoding. Browsers would do the right thing due to Content-Length". But this is something entirely different. Garbage is not appended, it is _mixed_ with the object and I'm 100% sure it happens without chunked encoding. And browsers don't do the right thing in this case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 16 21:32:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Jul 2010 21:32:01 -0000 Subject: [Varnish] #735: Support backend control via CLI Message-ID: <040.5238d8dc11accb237444ccdefb404199@varnish-cache.org> #735: Support backend control via CLI -------------------------+-------------------------------------------------- Reporter: tgr | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- The attached patches (for trunk and for 2.1, the only difference is Sphinx docs) are a PoC of CLI-based backend control for round-robin and random directors. It's a quick hack and the code may not be where you want it, but it works. Rationale: - it may be desirable to allow application administrators to disable/enable backends without allowing VCL modification, - there is presumably no need to disable a backend that is not part of a director, - health probes should continue when a backend is disabled - it is easy to make a decision to disable/enable a backend based on its health status, when presented in a format like: director1 backend1 Enabled Healthy[[BR]] director1 backend2 Disabled Healthy[[BR]] director1 backend3 Disabled Sick[[BR]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 20 22:12:12 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Jul 2010 22:12:12 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform Message-ID: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- It will be nice to support Varnish in Cygwin plataform (http://www.cygwin.com) After weeks making some tests I was able to build successful Varnish in Cygwin, the problems that I have found are: 1) Cygwin doesn't support CLOCK_MONOTONIC but HAVE_CLOCK_GETTIME is defined 2) RTLD_LOCAL is not defined in dlfcn.h headers 3) madvise function and MADV_RANDOM define does not exists, in Cygwin their correct names are posix_madvise and POSIX_MADV_RANDOM 4) In Cygwin SO_RCVTIMEO_WORKS and SO_SNDTIMEO_WORKS doesn't work properly because in Windows setsockopt/getsockopt expects time-out in "int" milliseconds instead of "struct timeval" (in future, i think it could be fixed) 5) Linkage problems ("Undefined reference" errors). The undefined reference is because fundamentally ELF (UNIX) and PE/COFF (Windows) are very different in terms of how linking works under the hood. The short explanation is that PE/COFF requires all references to be resolved at link-time: * http://www.cygwin.com/ml/cygwin/2006-12/msg00592.html * http://www.cygwin.com/ml/cygwin/2005-07/msg00675.html * http://www.mail-archive.com/cygwin at cygwin.com/msg81837.html 6) VCL compilation problems ("Undefined reference" errors). VCL compiled DLL uses simbols from EXE. It is necesary to create a fake import file from EXE to allow compilation. I have solved all problems modifing source code and automake scripts. I attach all modification to this ticket. It is also necessary to execute varnishd with cc_command parameter in order to compile VCL correctly: -p cc_command='cc -shared /tmp/varnish-2.1.2/bin/varnishd/varnishd- cache_vrt.o /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_backend_cfg.o -L/usr/local/lib -L/tmp/varnish-2.1.2/bin/varnishd/ -lvarnish -lvarnishd -Wl,--export-all-symbols -Wl,-x -o %o %s' I have tested varnish and works OK. I think it will be interesting to add this information to wiki: * http://www.varnish-cache.org/wiki/Installation -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 20 22:20:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Jul 2010 22:20:43 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.6899315e3611b826a3e841a6843346c0@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): I have worked with varnish 2.1.2 version, I don't know if there is any change in trunk. The modifications works OK in SOLARIS and CYGWIN platforms, I need somebody to test in Linux. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 21 14:33:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Jul 2010 14:33:28 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.162b70c180ede6c85ca5d4bbcdef978b@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): I have forgotten to say that the CYGWIN version that I used is 1.7.5: * CYGWIN_NT-5.1 machinename 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin In CYGWIN 1.5.25 exists some problems with compilation. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 21 15:08:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Jul 2010 15:08:27 -0000 Subject: [Varnish] #737: ExpKILL Message-ID: <044.74ce0b6b8dd77e901938a6c929ff024a@varnish-cache.org> #737: ExpKILL ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.2 Severity: blocker | Keywords: ----------------------+----------------------------------------------------- I am using Varnish 2.1.2 and I am getting this error on Varnishlog which is causing me 503's 0 ExpKill - 476131785 -60 0 ExpKill - 476131786 -60 0 ExpKill - 476131788 -60 0 ExpKill - 476131789 -60 0 ExpKill - 476131790 -60 0 ExpKill - 475778248 -60 0 ExpKill - 476131794 -60 0 ExpKill - 476131796 -60 0 ExpKill - 476131799 -60 0 ExpKill - 476131800 -60 0 ExpKill - 476131804 -60 0 ExpKill - 476131809 -60 0 ExpKill - 476131814 -60 0 ExpKill - 476131817 -60 0 ExpKill - 476131821 -60 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1279724710 1.0 0 ExpKill - 476131825 -60 0 ExpKill - 476131827 -60 0 ExpKill - 476131837 -60 0 ExpKill - 476131840 -60 0 ExpKill - 476131841 -60 0 ExpKill - 476131847 -60 0 ExpKill - 476131859 -60 0 ExpKill - 476131861 -60 0 ExpKill - 476131862 -60 0 ExpKill - 476131867 -60 0 ExpKill - 476131873 -60 0 ExpKill - 476131886 -60 0 ExpKill - 476131889 -60 0 ExpKill - 476131890 -60 0 ExpKill - 476131892 -60 0 ExpKill - 476131895 -60 0 ExpKill - 476131911 -60 0 ExpKill - 476131915 -60 0 ExpKill - 476131916 -60 0 ExpKill - 476131919 -60 0 ExpKill - 476131921 -60 0 ExpKill - 476131925 -60 0 ExpKill - 476131937 -60 0 ExpKill - 476131977 -60 0 ExpKill - 476131979 -60 0 ExpKill - 475778294 -60 0 ExpKill - 475778296 -60 0 ExpKill - 475778297 -60 0 ExpKill - 476131986 -60 0 ExpKill - 476131995 -60 0 ExpKill - 475778300 -60 0 ExpKill - 476131996 -60 0 ExpKill - 476132000 -60 0 ExpKill - 475778301 -60 0 ExpKill - 476132003 -60 0 ExpKill - 475778306 -60 0 ExpKill - 476132014 -60 0 ExpKill - 475778310 -60 0 ExpKill - 476132018 -60 0 ExpKill - 476132025 -60 0 ExpKill - 476132033 -60 I cant seem to figure what error means or how to delete it. This is my VarnishStat 0+20:07:37 var01.buscacorp.com Hitrate ratio: 10 21 21 Hitrate avg: 0.7285 0.7310 0.7310 1116301 17.99 15.41 Client connections accepted 4520884 68.95 62.39 Client requests received 2930655 44.97 40.45 Cache hits 17132 0.00 0.24 Cache hits for pass 1049494 15.99 14.48 Cache misses 421592 5.00 5.82 Backend conn. success 1165918 17.99 16.09 Backend conn. reuses 212016 4.00 2.93 Backend conn. was closed 1377945 21.99 19.02 Backend conn. recycles 14399 0.00 0.20 Fetch head 1231700 19.99 17.00 Fetch with Length 211378 4.00 2.92 Fetch chunked 882 0.00 0.01 Fetch wanted close 2 0.00 0.00 Fetch failed 1296 . . N struct sess_mem 627 . . N struct sess 55201 . . N struct object 55295 . . N struct objectcore 74700 . . N struct objecthead 112304 . . N struct smf 1434 . . N small free smf 579 . . N large free smf 60 . . N struct vbe_conn 136 . . N worker threads 1782 0.00 0.02 N worker threads created 0 0.00 0.00 N queued work requests 21538 0.00 0.30 N overflowed work requests 5 . . N backends 834374 . . N expired objects 2515582 . . N LRU moved objects 3738560 62.96 51.60 Objects sent with write 1116253 17.99 15.41 Total Sessions 4520884 68.95 62.39 Total Requests 131009 0.00 1.81 Total pipe 414748 7.99 5.72 Total pass 1452908 23.98 20.05 Total fetch 1585032626 22456.93 21875.49 Total header bytes 216833013960 2798777.61 2992575.10 Total body bytes 360740 6.00 4.98 Session Closed 7115 0.00 0.10 Session Pipeline 10786 0.00 0.15 Session Read Ahead 4249623 65.96 58.65 Session Linger 4281093 62.96 59.08 Session herd 234483085 3585.59 3236.17 SHM records 15282489 223.85 210.92 SHM writes 907 0.00 0.01 SHM flushes due to overflow 37899 0.00 0.52 SHM MTX contention 105 0.00 0.00 SHM cycles through buffer 2282435 35.98 31.50 allocator requests 110291 . . outstanding allocations 4452687872 . . bytes allocated 6284730368 . . bytes free 6310 0.00 0.09 SMS allocator requests 3075346 . . SMS bytes allocated 3075346 . . SMS bytes freed 1458409 21.99 20.13 Backend requests made -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 21 15:52:51 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Jul 2010 15:52:51 -0000 Subject: [Varnish] #738: New functionality: loading a compiled VCL SO library file at boot Message-ID: <042.26d3c22cd66586f9ea2e069d9409993a@varnish-cache.org> #738: New functionality: loading a compiled VCL SO library file at boot -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: phk Type: enhancement | Status: new Priority: low | Milestone: Component: varnishd | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- I think it would be interesting to implement a new option for loading a compiled VCL SO library file at boot. Now, varnishd works receiving -b (backend address) or -f parameter (VCL file). If backend address is specified, varnishd internally creates a VCL file with the backend information. Varnishd at boot makes this job: VCL => C file => [c compiler] => SO library. At shutdown it deletes generated SO library. With small changes of code we could specify the SO library file, as a optional parameter of varnishd and instead procesing and compiling VCL, load directly in mgt_run_cc function the compiled VCL library. At shutdown varnishd should not delete VCL library if varnishd did not compile it at boot. The benefits of this new functionality are: * Improve security. In case of an security flaw, an attacker could execute the compiler and execute custom code in the machine. If varnish does not need compiler, it could be removed for varnish user, and make more difficult to attacker. * Boot speed improvement. The starting time will be smallest if we remove the need of compiling. * Now in production enviroment, varnish machine must have a C compiler installed in it, sometimes this is a bit odd for customers that a program needs to be compiled in production without control. An alternative is to compile VCL in development or test enviroments and install the compiled files in production and boot with compiled VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 21 16:14:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Jul 2010 16:14:56 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.b463c53b86fdbe6ebc8e7ea9579bfd28@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): After some problems launching regression tests, i have changed VCC_CC definition in configure.ac for Cygwin platform, and now cc_command parameter is not needed for varnishd. I have executed the tests and this is the result: {{{ 14 of 174 tests failed }}} I have detected some problems with VCL compilation for complex configuration files: {{{ #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x59): undefined reference to `_VRT_re_match'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0xc0): undefined reference to `_VRT_re_match'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x628): undefined reference to `_VRT_re_init'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x63c): undefined reference to `_VRT_re_init'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x667): undefined reference to `_VRT_re_fini'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x674): undefined reference to `_VRT_re_fini'\n }}} There are some errors with used ports, perhaps I have to stop some software of my machine {{{ bind(): Address already in use Assert error in server_start(), vtc_server.c line 181: Condition(s->sock >= 0) not true. errno = 112 (Address already in use) /bin/sh: line 5: 5836 Aborted (core dumped) ./varnishtest ${dir}$tst }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 21 17:48:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Jul 2010 17:48:53 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.200115290e1fbfe205ae3a160b6f9646@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): After one small change in configure.ac (I have added file "varnishd- cache_vrt_re.o" to VCC_C command) the VCL compilation problem has disappear and now regression tests problems are only 9: 9 of 174 tests failed I attach the new version. I continue having problems of "bind(): Address already in use" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 22 10:21:45 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Jul 2010 10:21:45 -0000 Subject: [Varnish] #739: varnishlog sometimes reports backend logs as client logs Message-ID: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> #739: varnishlog sometimes reports backend logs as client logs ------------------------+--------------------------------------------------- Reporter: thoran | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 2.1.2 Severity: major | Keywords: ------------------------+--------------------------------------------------- under heavy load, some backend logs are reported as if they were coming from the client. Here is an example: {{{ 10 RxProtocol c HTTP/1.1 10 RxStatus c 200 10 RxResponse c OK 10 RxHeader c Date: Wed, 21 Jul 2010 13:38:20 GMT 10 RxHeader c Status: 200 OK 10 RxHeader c Connection: close 10 RxHeader c Vary: X-Ftn-Is-Logged,Host 10 RxHeader c ETag: "a23d4243273da489d81423ee54c17767" 10 RxHeader c p3p: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT" 10 RxHeader c X-Varnish-Browser-Cache-Control: no-cache, private 10 RxHeader c X-Runtime: 0.45694 10 RxHeader c Content-Type: text/html; charset=utf-8 10 RxHeader c Content-Length: 27925 10 RxHeader c X-Metacache-Key: /items/154r509v8jcbi- gJMQmBre_2Q#Host:www.fotopedia.com#X-Ftn-Is-Logged:yes# 10 RxHeader c Cache-Control: public, max-age=604800 }}} This fragment was received from the backend, not from the client. By the way, it obviously looks like an HTTP response. So there is no way it could be an RxStatus, at best we can see a TxStatus, when talking to a client. This bug is easy to reproduce: * Setup an nginx to serve some static files on localhost:2223 * launch varnish with this: {{{ varnishd -a *:8543 -b localhost:2223 -F }}} * hit varnish with apache-bench like this: {{{ ab -n 100000 -c 50 http://localhost:8543/i/test.html }}} * control for the presence of an absurd log with this: {{{ varnishlog -c -i RxStatus }}} * wait ---- Results: on my linux vm, I approximately see 1 log every 1000 requests: {{{ [10:14][infrabox] root at infrabox:~# varnishlog -c -i RxStatus 14 RxStatus c 200 13 RxStatus c 200 13 RxStatus c 200 14 RxStatus c 200 15 RxStatus c 200 21 RxStatus c 200 18 RxStatus c 200 13 RxStatus c 200 13 RxStatus c 200 14 RxStatus c 200 13 RxStatus c 200 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 22 10:31:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Jul 2010 10:31:30 -0000 Subject: [Varnish] #739: varnishlog sometimes reports backend logs as client logs In-Reply-To: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> References: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> Message-ID: <052.fab5dd2ba800b0c24127571c86d584ce@varnish-cache.org> #739: varnishlog sometimes reports backend logs as client logs ------------------------+--------------------------------------------------- Reporter: thoran | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 2.1.2 Severity: major | Keywords: ------------------------+--------------------------------------------------- Comment(by thoran): I forgot to mention one important setting of the nginx configuration. Be sure that nginx answers with {{{ Cache-Control: no-cache }}} otherwise, varnish will cache the response -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 22 12:23:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Jul 2010 12:23:48 -0000 Subject: [Varnish] #739: varnishlog sometimes reports backend logs as client logs In-Reply-To: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> References: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> Message-ID: <052.c057254f21ceb59fe20d9a80e2aa9d72@varnish-cache.org> #739: varnishlog sometimes reports backend logs as client logs ------------------------+--------------------------------------------------- Reporter: thoran | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 2.1.2 Severity: major | Keywords: ------------------------+--------------------------------------------------- Comment(by thoran): on our server, in production, the bug happens much more frequently than here. For requests that hit our backends, 1/20 of their responses are logged as coming from the client. By the way, we only observed the problem with the response, not with the request (which is correctly logged as being sent to a backend) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jul 25 15:55:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 25 Jul 2010 15:55:57 -0000 Subject: [Varnish] #740: Build dependencies on Debian/Ubuntu should mention pkg-config Message-ID: <045.d15ba4b4913c446c52cb4d721a65f5b5@varnish-cache.org> #740: Build dependencies on Debian/Ubuntu should mention pkg-config ----------------------+----------------------------------------------------- Reporter: arrowman | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 2.1.0 | Severity: minor Keywords: | ----------------------+----------------------------------------------------- On http://varnish-cache.org/docs/installation/install/ the dependencies on Debian/Ubuntu are listed. With these packages installed, ./configure of Varnins 2.1 on Debian lenny (stable) failed with: checking for pkg-config... no[[BR]] checking for PCRE... configure: error: in `/tmp/tmpeyr_tObuildout-varnish- build/varnish-2.1': configure: error: The pkg-config script could not be found or is too old. The solution was to install package 'pkg-config' as well. Please add it to the list of dependencies. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jul 25 20:42:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 25 Jul 2010 20:42:52 -0000 Subject: [Varnish] #741: varnish{top, stat} crash ("Assert error") when output scrolls past shell window height Message-ID: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> #741: varnish{top,stat} crash ("Assert error") when output scrolls past shell window height -------------------------+-------------------------------------------------- Reporter: rb | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: critical | Keywords: -------------------------+-------------------------------------------------- i've, varnishd -V varnishd (varnish-trunk SVN 5048) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS uname -a Linux svr 2.6.34-12-xen #1 SMP 2010-06-29 02:39:08 +0200 i686 i686 i386 GNU/Linux lsb_release -a LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch Distributor ID: SUSE LINUX Description: openSUSE 11.3 (i586) Release: 11.3 Codename: n/a if i execute 'varnishtop' or 'varnishstat', and output scrolls past vertical height/extent of the shell window i'm in, it crashes with: --------------------- varnishstat -n alpha Assert error in do_curses(), varnishstat_curses.c line 216: Condition((mvprintw(line, 0, "%12ju %12.2f %12.2f %s\n", ju, (ju - (intmax_t)pt->ref)/lt, ju / up, pt->name)) != ERR) not true. Abort --------------------- varnishtop -n alpha Assert error in update(), varnishtop.c line 171: Condition((mvprintw(l, 0, "%9.2f %-*.*s %*.*s\n", tp->count, maxfieldlen, maxfieldlen, VSL_tags[tp->tag], len, len, tp->rec_data)) != ERR) not true. Abort --------------------- fully reproducible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 26 17:49:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Jul 2010 17:49:48 -0000 Subject: [Varnish] #741: varnish{top, stat} crash ("Assert error") when output scrolls past shell window height In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> Message-ID: <048.1be3c83babe576bf42e5882b3afdcfea@varnish-cache.org> #741: varnish{top,stat} crash ("Assert error") when output scrolls past shell window height -------------------------+-------------------------------------------------- Reporter: rb | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: critical | Keywords: -------------------------+-------------------------------------------------- Comment(by victori): seconded same issue on varnish-trunk 5048M / opensolaris snv98 host. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 26 17:52:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Jul 2010 17:52:32 -0000 Subject: [Varnish] #741: varnish{top, stat} crash ("Assert error") when output scrolls past shell window height In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> Message-ID: <048.dd7f21962cc90e761f2610ab17d2c49f@varnish-cache.org> #741: varnish{top,stat} crash ("Assert error") when output scrolls past shell window height -------------------------+-------------------------------------------------- Reporter: rb | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: critical | Keywords: -------------------------+-------------------------------------------------- Comment(by victori): Edit: Removing the assert check made it work correctly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 26 18:01:03 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Jul 2010 18:01:03 -0000 Subject: [Varnish] #741: varnish{top, stat} crash ("Assert error") when output scrolls past shell window height In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> Message-ID: <048.c9a41c2b4b874fec2bc22445d9c3f7dc@varnish-cache.org> #741: varnish{top,stat} crash ("Assert error") when output scrolls past shell window height -------------------------+-------------------------------------------------- Reporter: rb | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: critical | Keywords: -------------------------+-------------------------------------------------- Comment(by victori): Edit: I should really wait and obtain a full bug report case before posting as I hit bugs. Seems like varnish{stat|log} utilities don't default to the default instance and just core dump. Removing the assert check and defining the default instance name via -n toggle makes it work correctly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 27 09:40:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Jul 2010 09:40:00 -0000 Subject: [Varnish] #742: vcl.show possible segmentation fault when using format-strings Message-ID: <040.0c3f2f22d121290d2bc82781cff7e17e@varnish-cache.org> #742: vcl.show possible segmentation fault when using format-strings -------------------+-------------------------------------------------------- Reporter: nav | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Using following vcl code may cause segfault while handling vcl.show command. {{{ C{ void whatever_function_that_is_never_called(){ // Important part are the %s syslog(0, "%s %s %s", "", "", ""); } }C }}} Problem occurs when mentioned command is issued. To show code function cli_out is used without additional arguments. This function handles input as format string + params - therefore these %s will be replaced by data on stack. Sometimes you can get only trash in your vcl code, but its possible to get segfault. The more %s the bigger is probability of segfault. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 27 09:43:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Jul 2010 09:43:31 -0000 Subject: [Varnish] #742: vcl.show possible segmentation fault when using format-strings In-Reply-To: <040.0c3f2f22d121290d2bc82781cff7e17e@varnish-cache.org> References: <040.0c3f2f22d121290d2bc82781cff7e17e@varnish-cache.org> Message-ID: <049.25ed72036eec0f3348ce74fdc5323c3e@varnish-cache.org> #742: vcl.show possible segmentation fault when using format-strings -------------------+-------------------------------------------------------- Reporter: nav | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by nav): {{{ 15 _IO_vfprintf_internal() vfprintf.c:1614 0xb751750b 14 _IO_vsnprintf() vsnprintf.c:120 0xb7537460 13 vsb_vprintf() varnish-cache/lib/libvarnish/vsb.c:326 0xb76bbb14 12 cli_out() varnish-cache/lib/libvarnish/cli_common.c:64 0xb76b4e6a 11 mcf_config_show() varnish-cache/bin/varnishd/mgt_vcc.c:676 0x0808cb27 10 cls_dispatch() varnish-cache/lib/libvarnish/cli_serve.c:224 0xb76b5b26 9 cls_vlu() varnish-cache/lib/libvarnish/cli_serve.c:294 0xb76b5f7c 8 LineUpProcess() varnish-cache/lib/libvarnish/vlu.c:157 0xb76ba291 7 VLU_Fd() varnish-cache/lib/libvarnish/vlu.c:182 0xb76ba487 6 CLS_PollFd() varnish-cache/lib/libvarnish/cli_serve.c:426 0xb76b6a40 5 mgt_cli_callback2() varnish-cache/bin/varnishd/mgt_cli.c:383 0x08088b08 4 vev_schedule_one() varnish-cache/lib/libvarnish/vev.c:501 0xb76b9c83 3 vev_schedule() varnish-cache/lib/libvarnish/vev.c:366 0xb76b948c 2 MGT_Run() varnish-cache/bin/varnishd/mgt_child.c:613 0x080861bf 1 main() varnish-cache/bin/varnishd/varnishd.c:700 0x08099fd5 }}} Stack trace from where segfault occured (lines may differ from original code). Tested on 2.1 branch, but trunk is also affected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 27 21:23:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Jul 2010 21:23:30 -0000 Subject: [Varnish] #743: Modification to varnishncsa init script on RH based distros Message-ID: <043.1837d707016f590252ca8d7dd1dd7354@varnish-cache.org> #743: Modification to varnishncsa init script on RH based distros ----------------------+----------------------------------------------------- Reporter: jlintz | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: 2.0 | Severity: normal Keywords: epel rpm | ----------------------+----------------------------------------------------- Line 30 of the init script 30 DAEMON_OPTS="-a -w $logfile -D -P $pidfile" should be moved down to line #34, past the sourcing of the /etc/sysconfig/varnishncsa file. With the current setup, if you set your logfile variable in /etc/sysconfig/varnishncsa , it gets ignored as DAEMON_OPTS is already set with the default value. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 28 16:55:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Jul 2010 16:55:09 -0000 Subject: [Varnish] #744: CLI repeats previous commands instead of executing the current one Message-ID: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org> #744: CLI repeats previous commands instead of executing the current one ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Keywords: cli ----------------------+----------------------------------------------------- When a command is issued to the CLI, it repeats the previous command. After a few tries the current command is executed, e.g. purge.url ^/something 200 0 purge.list 200 0 purge.list 200 0 purge.list 200 1260 0x7fba40f25e80 1280324791.112952 (...) When a command is run on one CLI connection, it gets repeated on other connections too. I haven't seen it with 2.1.1. I'm setting major severity, because the CLI is an important part of varnishd and it is also the only straightforward way to monitor backend health (via debug.health). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 28 17:47:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Jul 2010 17:47:33 -0000 Subject: [Varnish] #745: Varnishstat Message-ID: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org> #745: Varnishstat --------------------------+------------------------------------------------- Reporter: piripirigoso | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.1 release Component: varnishstat | Version: 2.1.2 Severity: critical | Keywords: varnishstats --------------------------+------------------------------------------------- Dear All, I've found the follow issue: The varnishstat turns the client_req, cache_hit, cache_miss values to the zero mark. At my script, i took this values to send to cacti. '''Look the example:'''[[BR]] ''AGENTE_LASTRUN 1280272976 varnish_requests 1579046 varnish_hits 1512704 varnish_misses 58198[[BR]] AGENTE_LASTRUN 1280272977 varnish_requests 1581086 varnish_hits 1514679 varnish_misses 58253[[BR]] AGENTE_LASTRUN 1280272978 varnish_requests 1 varnish_hits 0 varnish_misses 2[[BR]] AGENTE_LASTRUN 1280272979 varnish_requests 19 varnish_hits 1 varnish_misses 20[[BR]] AGENTE_LASTRUN 1280272980 varnish_requests 345 varnish_hits 28 varnish_misses 319'' I have six servers, half of them with 2.1.2 version and another half with 2.0.6. Its happening junt with 2.1.2 version. ''varnishstat -V varnishstat (varnish-2.1.2 SVN ) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS'' Can You hepl me? -- Ticket URL: Varnish The Varnish HTTP Accelerator From renato at luren.com.br Wed Jul 28 17:54:32 2010 From: renato at luren.com.br (Renato Farias) Date: Wed, 28 Jul 2010 17:54:32 -0000 Subject: varnishstats Message-ID: An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Wed Jul 28 19:09:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Jul 2010 19:09:02 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.0abf4f9999a00dbe603b40806a78237a@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): I have apply all my changes to svn trunk version of varnish. I attach it to ticket. With varnish trunk version I have executed regression tests and this is the result: 8 of 183 tests failed They are: FAIL: ./tests/b00004.vtc FAIL: ./tests/b00015.vtc FAIL: ./tests/b00030.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/p00002.vtc FAIL: ./tests/r00558.vtc FAIL: ./tests/v00009.vtc FAIL: ./tests/v00027.vtc I also attach regression test logs to ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 28 19:11:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Jul 2010 19:11:56 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org> Message-ID: <051.0862e7e2f0a30b2e862c4282de403823@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------------------------------- Reporter: jdzst | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: | Severity: normal Keywords: cygwin, windows | -----------------------------+---------------------------------------------- Comment(by jdzst): I have apply all my changes to svn trunk version of varnish. I attach it to ticket. With varnish trunk version I have executed regression tests and this is the result: {{{8 of 183 tests failed}}} They are: {{{ FAIL: ./tests/b00004.vtc FAIL: ./tests/b00015.vtc FAIL: ./tests/b00030.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/p00002.vtc FAIL: ./tests/r00558.vtc FAIL: ./tests/v00009.vtc FAIL: ./tests/v00027.vtc }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 30 16:20:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Jul 2010 16:20:09 -0000 Subject: [Varnish] #741: varnish{top, stat} crash ("Assert error") when output scrolls past shell window height In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org> Message-ID: <048.8bbec5454d644978de8d7d4eedc686d3@varnish-cache.org> #741: varnish{top,stat} crash ("Assert error") when output scrolls past shell window height -------------------------+-------------------------------------------------- Reporter: rb | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: critical | Keywords: -------------------------+-------------------------------------------------- Comment(by rb): bump? -- Ticket URL: Varnish The Varnish HTTP Accelerator