From varnish-bugs at varnish-cache.org Thu Apr 1 05:22:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Apr 2010 05:22:33 -0000 Subject: [Varnish] #672: encountered libpcre error when running ./configure Message-ID: <045.8d34ccfca4d0b1693cc6589036a73a67@varnish-cache.org> #672: encountered libpcre error when running ./configure ---------------------------------+------------------------------------------ Reporter: flyincat | Type: defect Status: new | Priority: high Milestone: Varnish 2.1 release | Component: build Version: | Severity: normal Keywords: libpcre | ---------------------------------+------------------------------------------ Hello, first I'd like to express my appreciation to all the development members that you give us a so amazing new release. But, when i'm trying to run ./configure after i decompressed the source tar package, there is an error as below: ------------------------------------------------------------------- checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PCRE... configure: error: Package requirements (libpcre) were not met: No package 'libpcre' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables PCRE_CFLAGS and PCRE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. I'm running ./configure under a X64 HP Server with CentOS 5.4 X64 installed. and I've already installed pcre-8.2 from the tarball package. ------------------------------------------------------------------- Any suggestions? Thanks a lot for your hard working! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 1 10:53:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Apr 2010 10:53:57 -0000 Subject: [Varnish] #673: Bug fix in doc/changes-2.0.6-2.1.0.xml Message-ID: <044.ea45eaa2be456fdcf240889bde7afd74@varnish-cache.org> #673: Bug fix in doc/changes-2.0.6-2.1.0.xml ---------------------+------------------------------------------------------ Reporter: andersb | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: minor Keywords: | ---------------------+------------------------------------------------------ Hi, attached is a diff file for fixing up "doc/changes-2.0.6-2.1.0.xml" so it will create a .html file when xslt transformed. Since I have no clue how to make patchfiles it's a diff I made with: diff -Naur changes-2.0.6-2.1.0.xml changes-2.0.6-2.1.0.xml.old > rel_2.0.6-2.1.0_doc.patch changes-2.0.6-2.1.0.xml.old is the old original file. changes-2.0.6-2.1.0.xml is the file where I made the fixes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 1 10:56:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Apr 2010 10:56:52 -0000 Subject: [Varnish] #673: Bug fix in doc/changes-2.0.6-2.1.0.xml In-Reply-To: <044.ea45eaa2be456fdcf240889bde7afd74@varnish-cache.org> References: <044.ea45eaa2be456fdcf240889bde7afd74@varnish-cache.org> Message-ID: <053.e46636d9ac862ce3d58e5335e887f9d1@varnish-cache.org> #673: Bug fix in doc/changes-2.0.6-2.1.0.xml ---------------------+------------------------------------------------------ Reporter: andersb | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: minor Keywords: | ---------------------+------------------------------------------------------ Comment(by andersb): I see now that my patch is reversed... I am sure you guys will figure out :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 2 23:23:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Apr 2010 23:23:36 -0000 Subject: [Varnish] #674: Any failed request should be enough to decide backend is sick Message-ID: <045.e9ae81fe78cd757cc4eece7a1d245289@varnish-cache.org> #674: Any failed request should be enough to decide backend is sick -------------------------+-------------------------------------------------- Reporter: istenrot | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: saintmode probe backend -------------------------+-------------------------------------------------- As of Varnish 2.1.0 only failed probe requests can switch backend's status from healthy to sick. Any failed normal request should be also a clear signal to Varnish that a corresponding backend has gone sick. The problem is that saintmode doesn't get activated until a probe request has been made and decided as failed. That may result publishing 503 errors for many seconds depending on probe request interval setting. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 3 08:23:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 03 Apr 2010 08:23:10 -0000 Subject: [Varnish] #674: Any failed request should be enough to decide backend is sick In-Reply-To: <045.e9ae81fe78cd757cc4eece7a1d245289@varnish-cache.org> References: <045.e9ae81fe78cd757cc4eece7a1d245289@varnish-cache.org> Message-ID: <054.6b65ca2870d041a514d0ccc917cae20c@varnish-cache.org> #674: Any failed request should be enough to decide backend is sick -------------------------------------+-------------------------------------- Reporter: istenrot | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: saintmode probe backend | -------------------------------------+-------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I will not claim the current code to be perfect, but what you suggest is not better. We want to have a specific, well chosen URL we use for the general backend healthy check, to avoid having one randomly failing URL take down the entire backend. The saint-mode facility, contains a limit, so that if more than $saintmode_threshold different URLS fail, the entire backend will be declared unhealthy. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 11:23:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 11:23:23 -0000 Subject: [Varnish] #675: resource leak in mgt_cli.c Message-ID: <039.3ee735b1c8634ba3fab4e8518d3213d5@varnish-cache.org> #675: resource leak in mgt_cli.c ----------------------+----------------------------------------------------- Reporter: eg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I think there is a resource leak in mgt_cli.c file in mgt_cli_secret function - file opened at line 506 should be closed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 12:48:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 12:48:35 -0000 Subject: [Varnish] #673: Bug fix in doc/changes-2.0.6-2.1.0.xml In-Reply-To: <044.ea45eaa2be456fdcf240889bde7afd74@varnish-cache.org> References: <044.ea45eaa2be456fdcf240889bde7afd74@varnish-cache.org> Message-ID: <053.799b245c13ae863f42fb39a19d67a6d4@varnish-cache.org> #673: Bug fix in doc/changes-2.0.6-2.1.0.xml ----------------------+----------------------------------------------------- Reporter: andersb | Type: documentation Status: closed | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: minor Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r4643 already. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 12:49:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 12:49:53 -0000 Subject: [Varnish] #672: encountered libpcre error when running ./configure In-Reply-To: <045.8d34ccfca4d0b1693cc6589036a73a67@varnish-cache.org> References: <045.8d34ccfca4d0b1693cc6589036a73a67@varnish-cache.org> Message-ID: <054.8acc1f3972efcfc384d1da88fabe53af@varnish-cache.org> #672: encountered libpcre error when running ./configure ----------------------------------+----------------------------------------- Reporter: flyincat | Type: defect Status: closed | Priority: high Milestone: Varnish 2.1 release | Component: build Version: | Severity: normal Resolution: invalid | Keywords: libpcre ----------------------------------+----------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: Varnish 2.1.0 requires PCRE to be installed, and it seems like you don't have that. Make sure the libpcre.pc is in pkg-config's search path. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 13:00:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 13:00:16 -0000 Subject: [Varnish] #543: vcl.discard causes crash In-Reply-To: <040.77994a6127d2724f6aaeaf5c7e2e863a@varnish-cache.org> References: <040.77994a6127d2724f6aaeaf5c7e2e863a@varnish-cache.org> Message-ID: <049.23692a39e37050d6864fab98fcca9e0c@varnish-cache.org> #543: vcl.discard causes crash ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 13:00:45 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 13:00:45 -0000 Subject: [Varnish] #526: expiring objects with too large headers crashes varnish In-Reply-To: <043.50a7eddcced7d17429074091503f20a1@varnish-cache.org> References: <043.50a7eddcced7d17429074091503f20a1@varnish-cache.org> Message-ID: <052.5b6723da07489b85b6126b5e6904d1b7@varnish-cache.org> #526: expiring objects with too large headers crashes varnish ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: time this out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 13:07:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 13:07:52 -0000 Subject: [Varnish] #659: Varnish hcb_cleaner asset crash In-Reply-To: <044.b7bb3aeb2310d4da5e1d8404a8d9bb02@varnish-cache.org> References: <044.b7bb3aeb2310d4da5e1d8404a8d9bb02@varnish-cache.org> Message-ID: <053.17fea21fe4eaacd99bdbf6a5dd39096c@varnish-cache.org> #659: Varnish hcb_cleaner asset crash -------------------------+-------------------------------------------------- Reporter: victori | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I belive this has been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 7 13:13:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Apr 2010 13:13:05 -0000 Subject: [Varnish] #660: Varnish LINGER crash in tcp.c In-Reply-To: <044.085c5471b3d64713b43a7295b6635376@varnish-cache.org> References: <044.085c5471b3d64713b43a7295b6635376@varnish-cache.org> Message-ID: <053.ce2ff6d97f47d4209146c25237c7e969@varnish-cache.org> #660: Varnish LINGER crash in tcp.c ------------------------+--------------------------------------------------- Reporter: victori | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: duplicate | Keywords: ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: dup of #649 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 8 07:35:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Apr 2010 07:35:52 -0000 Subject: [Varnish] #675: resource leak in mgt_cli.c In-Reply-To: <039.3ee735b1c8634ba3fab4e8518d3213d5@varnish-cache.org> References: <039.3ee735b1c8634ba3fab4e8518d3213d5@varnish-cache.org> Message-ID: <048.8156fc40437e13bb300266e308b71032@varnish-cache.org> #675: resource leak in mgt_cli.c ----------------------+----------------------------------------------------- Reporter: eg | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4647 Thanks a lot! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 8 08:10:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Apr 2010 08:10:26 -0000 Subject: [Varnish] #669: taking to long on startup when RLIMIT_NOFILE is very high In-Reply-To: <042.234bda83da426b84ee5fc3efa690fdd4@varnish-cache.org> References: <042.234bda83da426b84ee5fc3efa690fdd4@varnish-cache.org> Message-ID: <051.6283e02c3e818c57a0600fe82c5e3e2a@varnish-cache.org> #669: taking to long on startup when RLIMIT_NOFILE is very high ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4648 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 8 13:09:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Apr 2010 13:09:40 -0000 Subject: [Varnish] #669: taking to long on startup when RLIMIT_NOFILE is very high In-Reply-To: <042.234bda83da426b84ee5fc3efa690fdd4@varnish-cache.org> References: <042.234bda83da426b84ee5fc3efa690fdd4@varnish-cache.org> Message-ID: <051.c7d19f582bbac970b796ab33a6b4f4a3@varnish-cache.org> #669: taking to long on startup when RLIMIT_NOFILE is very high ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by slink): Looks like a nice solution, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 13 13:27:50 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Apr 2010 13:27:50 -0000 Subject: [Varnish] #676: keeping varnishstat open will bring down server Message-ID: <045.d350afaccc03fe08044ff0b0b51085a6@varnish-cache.org> #676: keeping varnishstat open will bring down server -------------------------+-------------------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishstat | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- Hey guys, I've seen something I'd like to share with you, perhaps it could be seen as a bug in varnishstat. Yesterday I opened ssh sessions to my 4 balancers, to run some scripts, and then I opened varnishstat to monitor them. A while later I had to leave in a rush and closed my laptop's lid, and in that process killed my vpn tunnel and ssh sessions. However, the varnishstat process (apparently) keeps running. (FreeBSD 7.2 x64) Just a few hours ago (so around 16 hours later), I had one balancer die on my (become completely unresponsive, refuse connections to port 80). I immediately restarted varnishd, and I also saw a varnishstat instance eat 100% cpu, which I killed. Now when I just looked on the other balancers, I see the varnishstat instance using up a lot of CPU (only one out of 4 cores though). See attached top.txt. So it seems running varnishstat for a long time, it will use more and more resources, and in my case, even cause varnishd to fail somehow (it could be a coincidence, but I don't think so). After killing varnishstat, load went back from 1.5 to 0.2, around the usual. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 14 06:54:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Apr 2010 06:54:47 -0000 Subject: [Varnish] #677: test Message-ID: <043.02353cf9150588912f072ad199bc43e3@varnish-cache.org> #677: test --------------------+------------------------------------------------------- Reporter: tfheen | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- test ticket, please ignore -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 14 06:55:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Apr 2010 06:55:04 -0000 Subject: [Varnish] #677: test In-Reply-To: <043.02353cf9150588912f072ad199bc43e3@varnish-cache.org> References: <043.02353cf9150588912f072ad199bc43e3@varnish-cache.org> Message-ID: <052.9dd7ff0e1800aad30abde42505493b26@varnish-cache.org> #677: test --------------------+------------------------------------------------------- Reporter: tfheen | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 14 07:58:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Apr 2010 07:58:34 -0000 Subject: [Varnish] #665: should provide function for aligned allocations on the workspace In-Reply-To: <042.e3a7572daf97f0b894881c337e711349@varnish-cache.org> References: <042.e3a7572daf97f0b894881c337e711349@varnish-cache.org> Message-ID: <051.b313a864eb7ab4eb3f6457c09b3e9622@varnish-cache.org> #665: should provide function for aligned allocations on the workspace -----------------------------------------------------+---------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: ws_alloc workspace allocation alignment | -----------------------------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I have thought it over, and decided to align all WS allocations to void* size. This is implemented as of r4660 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 14 11:56:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Apr 2010 11:56:00 -0000 Subject: [Varnish] #678: varnishd stops accepting requests Message-ID: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> #678: varnishd stops accepting requests ----------------------+----------------------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: hang stop responding ----------------------+----------------------------------------------------- I have four balancers that ran 2.0.5 fine for months, and now I've upgraded them to 2.1.0, and sometimes one (at random which one) seems to hang. Varnishstat shows no requests coming in, and when I run varnishlog I only see a lot of lines like this: 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 I don't see anything else that is strange.. The only thing I see in my cacti monitoring is that responses go down, and active tcp connections go up (probably as a result). Load of the balancers prior to the problem is a normal 0.2-0.5. After restaring, in my syslog I see (strange the time is off by 2 hours though, time was 13:34, all other daemons log ok) Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Manager got SIGINT Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Stopping Child Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: child (65643) Started Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Closed fds: 4 5 6 7 11 12 14 15 Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Child starts Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said managed to mmap 8589934592 bytes of 8589934592 I cannot reproduce it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 15 07:18:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Apr 2010 07:18:27 -0000 Subject: [Varnish] #679: pass converts HEAD to GET Message-ID: <040.b8d4cb292bf3df5f3f03cc1aa0964f76@varnish-cache.org> #679: pass converts HEAD to GET ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- placeholder ticket to get number for regression test. Issue reported on mailing list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 15 07:47:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Apr 2010 07:47:18 -0000 Subject: [Varnish] #679: pass converts HEAD to GET In-Reply-To: <040.b8d4cb292bf3df5f3f03cc1aa0964f76@varnish-cache.org> References: <040.b8d4cb292bf3df5f3f03cc1aa0964f76@varnish-cache.org> Message-ID: <049.7e4d7284ce58cf33c26a877ef61885f4@varnish-cache.org> #679: pass converts HEAD to GET ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4662 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 15 08:15:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Apr 2010 08:15:57 -0000 Subject: [Varnish] #680: Passing on HEAD modifies backend request method to GET. Message-ID: <045.82cf0b7ce93e8cfd43772d475a58fdd6@varnish-cache.org> #680: Passing on HEAD modifies backend request method to GET. ----------------------+----------------------------------------------------- Reporter: censored | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Redefine vcl_recv as follows: sub vcl_recv { if (req.request == "HEAD") { return(pass); } } Pass works, but varnish still changes the method from HEAD to GET in the backend request. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 15 08:23:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Apr 2010 08:23:55 -0000 Subject: [Varnish] #680: Passing on HEAD modifies backend request method to GET. In-Reply-To: <045.82cf0b7ce93e8cfd43772d475a58fdd6@varnish-cache.org> References: <045.82cf0b7ce93e8cfd43772d475a58fdd6@varnish-cache.org> Message-ID: <054.55287e07aea6325eb3e24f542b569ba5@varnish-cache.org> #680: Passing on HEAD modifies backend request method to GET. ----------------------+----------------------------------------------------- Reporter: censored | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by censored): Forgot to mention this is varnish version 2.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 16 01:45:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Apr 2010 01:45:10 -0000 Subject: [Varnish] #681: problems using regular expressions with varnishlog Message-ID: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org> #681: problems using regular expressions with varnishlog ---------------------------+------------------------------------------------ Reporter: danielpicolli | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishlog | Version: Severity: critical | Keywords: regular expressions varnishlog ---------------------------+------------------------------------------------ I'm having some problems with regular expressions in varnishlog when i use "-X" param in version 2.1. Eg: varnishlog -X "foo" Assert error in VRE_exec(), vre.c line 58: Condition((code) != NULL) not true. Aborted When i use "-I" param, it works. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 19 09:26:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Apr 2010 09:26:47 -0000 Subject: [Varnish] #680: Passing on HEAD modifies backend request method to GET. In-Reply-To: <045.82cf0b7ce93e8cfd43772d475a58fdd6@varnish-cache.org> References: <045.82cf0b7ce93e8cfd43772d475a58fdd6@varnish-cache.org> Message-ID: <054.e9143b6794b7e79a47f66449862272c4@varnish-cache.org> #680: Passing on HEAD modifies backend request method to GET. -----------------------+---------------------------------------------------- Reporter: censored | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Hi there, I already fixed that (while waiting for your ticket :-) See #679 and r4662 Thanks for spotting this, it will be fixed in 2.1.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 19 20:30:59 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Apr 2010 20:30:59 -0000 Subject: [Varnish] #682: hash maps Message-ID: <047.b6895b33e6460a13ca874a4205f65ea0@varnish-cache.org> #682: hash maps -------------------------+-------------------------------------------------- Reporter: rosenfield | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: hash, hashtable, maps -------------------------+-------------------------------------------------- Hi I have a web site where every URL either: 1) returns an immutable (cacheable) content page or[[BR]] 2) results in an (uncacheable) HTTP redirect to a more-specific URL. I'd like to cache everything under bullet 1). {{{ +-------http-------+ +------302------+ | lots of contents | | go here | | ... | | +------302------+ | +-------https------+ +-| update acc'd | | | blah blah | | go there | | | blah | +---------------+ | | .... | +-| | | | +------------------+ }}} Many pages are for authorized users only. Caching them requires a bit of work. Specifics follow. I want an elegant design, meaning: 1) No hitting the backend servers to do auth,[[BR]] 2) No superfluous per-user backend requests,[[BR]] 3) No superfluous per-user copies of the same page. {{{ +-----------+ +-----------+ +-----------+ | | ---> ---> | | | | | CLIENT | blah blah | CACHE | SSSH! | BACKEND | | | <--- <--- | | | | +-----------+ +-----------+ +-----------+ }}} So far so good. At a minimum, I need to keep track of a few details via VCL: 1) which security clearance a cached page requires, and[[BR]] 2) given the user's authentication cookie, which clearances it grants. Bullet 1) is easy to implement. There are advanced and very flexible solutions where the backend server emits a page's security context via a HTTP header.. But for starters let's just go with something simple and put all pages which require elevated privileges into /admin/, let's call that security context 1. Even more dangerous stuff goes into /superuser/, aka context 2. Everything else is context 0. A snippet of VCL then simply deduces the security context (aka required clearance) by grokking the URL with a regex. {{{ ^ ^ ^ ^ ^ ^ | | | | | | | /* | | /admin/* | | /superuser/* | | /public/* | | | | | | /images/* | | | | | | /foo/* | | | | | \----------/ \---------/ \------------/ Context 0 Context 1 Context 2 }}} Easy peasy. Bullet 2) comes in two parts. First, we need to shovel the user's security clearances (or "allowed contexts") to the VCL. Second, we need to check that against the page's required clearance (or "security context") on subsequent requests. For the first part, we just shovel the user's security clearances (or "allowed contexts") to the VCL when the user logs in. No problem, just add a header, call it "X-Granted-Clearances: 1,2" to the login response. The VCL can now pick out both the user's cookie value from the "Set- Cookie: SESSAUTH=blah" header, and which security contexts this user has access to from the X-Granted-Clearances header. For the second part, we hit a brick wall. When the next request from the user comes in, VCL is in a different state of mind and has forgotten all about that stuff. So therein lies my problem. I need a hash map which is accessible from VCL, in which I can store authentication cookie values plus which security contexts they map to. Additionally, the hash map must clean itself up. The simplest mechanism will do, such as a 5-minute timeout on all entries. The required API functions as seen from VCL code are thus: {{{ map-define(map-id, timeout) [ creates the map if it doesn't exist. ] map-set(map-id, key, value) [ adds or updates entry. NULL value destroys entry. internally timestamps new entries. ] map-touch(map-id, key) [ updates internal timestamp. ] map-get(map-id, key) [ retrieves an entry. ] }}} And the cleanup thread must at least do: {{{ while (true) { if (no-entries) { wait-for-first-entry; } else { find-entry-with-lowest-timeout; wait-remaining; purge-if-still-exists-and-not-touched; } } }}} I think hash maps with timeouts have other use cases as well! (For example, the security context could be stored in a {url,context} map rather than being deduced directly from the URL, resulting in a more flexible solution.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From rosenfield.albert at gmail.com Mon Apr 19 20:34:48 2010 From: rosenfield.albert at gmail.com (rosenfield.albert at gmail.com) Date: Mon, 19 Apr 2010 20:34:48 -0000 Subject: [Varnish] #682: hash maps In-Reply-To: <047.b6895b33e6460a13ca874a4205f65ea0@varnish-cache.org> References: <047.b6895b33e6460a13ca874a4205f65ea0@varnish-cache.org> Message-ID: http://www.varnish-cache.org/ticket/682 On Mon, Apr 19, 2010 at 10:30 PM, Varnish wrote: > #682: hash maps > -------------------------+-------------------------------------------------- > ?Reporter: ?rosenfield ? | ? ? ? Owner: ?phk > ? ? Type: ?enhancement ?| ? ? ?Status: ?new > ?Priority: ?normal ? ? ? | ? Milestone: > Component: ?varnishd ? ? | ? ? Version: ?trunk > ?Severity: ?normal ? ? ? | ? ?Keywords: ?hash, hashtable, maps > -------------------------+-------------------------------------------------- > ?Hi > > ?I have a web site where every URL either: > ?1) returns an immutable (cacheable) content page or[[BR]] > ?2) results in an (uncacheable) HTTP redirect to a more-specific URL. > > ?I'd like to cache everything under bullet 1). > > ?{{{ > ? +-------http-------+ ? ? ? ? ? ? ? ? ? ? ? ? ?+------302------+ > ? | lots of contents | ? ? ? ? ? ? ? ? ? ? ? ? ?| go here ? ? ? | > ? | ... ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ?| +------302------+ > ? | +-------https------+ ? ? ? ? ? ? ? ? ? ? ? ?+-| update acc'd ?| > ? | | blah blah ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ?| go there ? ? ?| > ? | | blah ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ?+---------------+ > ? | | .... ? ? ? ? ? ? | > ? +-| ? ? ? ? ? ? ? ? ?| > ? ? | ? ? ? ? ? ? ? ? ?| > ? ? +------------------+ > ?}}} > > ?Many pages are for authorized users only. ?Caching them requires a bit of > ?work. ?Specifics follow. > > ?I want an elegant design, meaning: > ?1) No hitting the backend servers to do auth,[[BR]] > ?2) No superfluous per-user backend requests,[[BR]] > ?3) No superfluous per-user copies of the same page. > > ?{{{ > ? +-----------+ ? ? ? ? ? +-----------+ ? ? ? ? +-----------+ > ? | ? ? ? ? ? | ---> ---> | ? ? ? ? ? | ? ? ? ? | ? ? ? ? ? | > ? | ?CLIENT ? | blah blah | ? CACHE ? | ?SSSH! ?| ?BACKEND ?| > ? | ? ? ? ? ? | <--- <--- | ? ? ? ? ? | ? ? ? ? | ? ? ? ? ? | > ? +-----------+ ? ? ? ? ? +-----------+ ? ? ? ? +-----------+ > ?}}} > > > ?So far so good. > > ?At a minimum, I need to keep track of a few details via VCL: > ?1) which security clearance a cached page requires, and[[BR]] > ?2) given the user's authentication cookie, which clearances it grants. > > ?Bullet 1) is easy to implement. ?There are advanced and very flexible > ?solutions where the backend server emits a page's security context via a > ?HTTP header.. ?But for starters let's just go with something simple and > ?put all pages which require elevated privileges into /admin/, let's call > ?that security context 1. ?Even more dangerous stuff goes into /superuser/, > ?aka context 2. ?Everything else is context 0. ?A snippet of VCL then > ?simply deduces the security context (aka required clearance) by grokking > ?the URL with a regex. > > ?{{{ > ? ^ ? ? ? ? ? ?^ ? ? ? ^ ? ? ? ? ? ^ ? ? ? ^ ? ? ? ? ? ? ?^ > ? | ? ? ? ? ? ?| ? ? ? | ? ? ? ? ? | ? ? ? | ? ? ? ? ? ? ?| > ? | /* ? ? ? ? | ? ? ? | /admin/* ?| ? ? ? | /superuser/* | > ? | /public/* ?| ? ? ? | ? ? ? ? ? | ? ? ? | ? ? ? ? ? ? ?| > ? | /images/* ?| ? ? ? | ? ? ? ? ? | ? ? ? | ? ? ? ? ? ? ?| > ? | /foo/* ? ? | ? ? ? | ? ? ? ? ? | ? ? ? | ? ? ? ? ? ? ?| > ? ?\----------/ ? ? ? ? \---------/ ? ? ? ? \------------/ > ? ? Context 0 ? ? ? ? ? ?Context 1 ? ? ? ? ? ?Context 2 > ?}}} > > ?Easy peasy. > > > ?Bullet 2) comes in two parts. ?First, we need to shovel the user's > ?security clearances (or "allowed contexts") to the VCL. ?Second, we need > ?to check that against the page's required clearance (or "security > ?context") on subsequent requests. > > ?For the first part, we just shovel the user's security clearances (or > ?"allowed contexts") to the VCL when the user logs in. ?No problem, just > ?add a header, call it "X-Granted-Clearances: 1,2" to the login response. > ?The VCL can now pick out both the user's cookie value from the "Set- > ?Cookie: SESSAUTH=blah" header, and which security contexts this user has > ?access to from the X-Granted-Clearances header. > > ?For the second part, we hit a brick wall. ?When the next request from the > ?user comes in, VCL is in a different state of mind and has forgotten all > ?about that stuff. > > ?So therein lies my problem. ?I need a hash map which is accessible from > ?VCL, in which I can store authentication cookie values plus which security > ?contexts they map to. > > ?Additionally, the hash map must clean itself up. ?The simplest mechanism > ?will do, such as a 5-minute timeout on all entries. > > ?The required API functions as seen from VCL code are thus: > ?{{{ > ? ?map-define(map-id, timeout) ? [ creates the map if it doesn't exist. ] > ? ?map-set(map-id, key, value) ? [ adds or updates entry. NULL value > ?destroys > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?entry. internally timestamps new > ?entries. ] > ? ?map-touch(map-id, key) ? ? ? ?[ updates internal timestamp. ] > ? ?map-get(map-id, key) ? ? ? ? ?[ retrieves an entry. ] > ?}}} > > ?And the cleanup thread must at least do: > > ?{{{ > ? ?while (true) { > ? ? ? if (no-entries) { > ? ? ? ? ?wait-for-first-entry; > ? ? ? } else { > ? ? ? ? ?find-entry-with-lowest-timeout; > ? ? ? ? ?wait-remaining; > ? ? ? ? ?purge-if-still-exists-and-not-touched; > ? ? ? } > ? ?} > ?}}} > > ?I think hash maps with timeouts have other use cases as well! > > ?(For example, the security context could be stored in a {url,context} map > ?rather than being deduced directly from the URL, resulting in a more > ?flexible solution.) > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > From varnish-bugs at varnish-cache.org Wed Apr 21 21:01:03 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Apr 2010 21:01:03 -0000 Subject: [Varnish] #683: varnishd usage output out of date Message-ID: <045.159da22a2165a289f563b20ba189dd1a@varnish-cache.org> #683: varnishd usage output out of date ----------------------+----------------------------------------------------- Reporter: dormando | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- -h lists classic as default hash -s doesn't list persist mode. this is in 2.1's branch, but I guess that'd apply to trunk as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 22 08:17:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Apr 2010 08:17:46 -0000 Subject: [Varnish] #684: Varnish 2.1.1 hangs with critbit enabled Message-ID: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> #684: Varnish 2.1.1 hangs with critbit enabled ----------------------+----------------------------------------------------- Reporter: dormando | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I'm able to run varnish 2.1.x with critbit as the default hash table for 1-15 minutes, then a full thread hang happens. combined thread stack: 6011 5844 __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_lookup,HSH_Lookup,cnt_lookup,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone 153 writev,WRW_Flush,WRW_FlushRelease,RES_WriteObj,cnt_deliver,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone 3 __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_deref,HSH_DerefObjCore,cnt_miss,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone 1 pthread_cond_wait@@GLIBC_2.3.2,Lck_CondWait,wrk_herder_thread,start_thread,clone 1 poll,CLS_Poll,CLI_Run,child_main,start_child,mgt_sigchld,vev_sched_signal,vev_schedule,MGT_Run,main 1 nanosleep,TIM_sleep,wrk_herdtimer_thread,start_thread,clone 1 nanosleep,TIM_sleep,vca_sess_timeout_ticker,start_thread,clone Most are locked within HSH_Lookup example full backtrace: #0 0x00007f225f328e74 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f225f324874 in _L_lock_106 () from /lib64/libpthread.so.0 #2 0x00007f225f3242e0 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000421e19 in Lck__Lock (lck=, p=0x44d0f8 "hcb_lookup", f=0x44ce1b "hash_critbit.c", l=454) at cache_lck.c:78 #4 0x000000000042e820 in hcb_lookup (sp=, noh=0x7f1476804a20) at hash_critbit.c:454 #5 0x000000000041cb51 in HSH_Lookup (sp=0x7f148f09b008, poh=0x7f15103e6798) at cache_hash.c:345 #6 0x0000000000411b10 in cnt_lookup (sp=0x7f148f09b008) at cache_center.c:786 #7 0x0000000000413f90 in CNT_Session (sp=0x7f148f09b008) at steps.h:38 #8 0x0000000000424a78 in wrk_do_cnt_sess (w=0x7f15103f9e60, priv=) at cache_pool.c:294 #9 0x0000000000423d5d in wrk_thread_real (qp=0x7f225ea0b2e0, shm_workspace=, sess_workspace=65536, nhttp=64, http_space=, siov=128) at cache_pool.c:183 #10 0x00007f225f322367 in start_thread () from /lib64/libpthread.so.0 #11 0x00007f225ebfdf7d in clone () from /lib64/libc.so.6 Running with `-h classic` is running much longer so far. nothing in the varnish stats or params looks off. vcl is identical to working(ish) 2.0 series aside from the obj->beresp replacement. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 22 11:10:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Apr 2010 11:10:39 -0000 Subject: [Varnish] #684: Varnish 2.1.1 hangs with critbit enabled In-Reply-To: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> References: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> Message-ID: <054.f6e93ecae1d3c6b6b0806a5a87ad4e80@varnish-cache.org> #684: Varnish 2.1.1 hangs with critbit enabled ----------------------+----------------------------------------------------- Reporter: dormando | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Old description: > I'm able to run varnish 2.1.x with critbit as the default hash table for > 1-15 minutes, then a full thread hang happens. > > combined thread stack: > > 6011 > 5844 > __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_lookup,HSH_Lookup,cnt_lookup,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone > 153 > writev,WRW_Flush,WRW_FlushRelease,RES_WriteObj,cnt_deliver,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone > 3 > __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_deref,HSH_DerefObjCore,cnt_miss,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone > 1 > pthread_cond_wait@@GLIBC_2.3.2,Lck_CondWait,wrk_herder_thread,start_thread,clone > 1 > poll,CLS_Poll,CLI_Run,child_main,start_child,mgt_sigchld,vev_sched_signal,vev_schedule,MGT_Run,main > 1 nanosleep,TIM_sleep,wrk_herdtimer_thread,start_thread,clone > 1 nanosleep,TIM_sleep,vca_sess_timeout_ticker,start_thread,clone > > Most are locked within HSH_Lookup > > example full backtrace: > #0 0x00007f225f328e74 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f225f324874 in _L_lock_106 () from /lib64/libpthread.so.0 > #2 0x00007f225f3242e0 in pthread_mutex_lock () from > /lib64/libpthread.so.0 > #3 0x0000000000421e19 in Lck__Lock (lck=, > p=0x44d0f8 "hcb_lookup", f=0x44ce1b "hash_critbit.c", l=454) > at cache_lck.c:78 > #4 0x000000000042e820 in hcb_lookup (sp=, > noh=0x7f1476804a20) at hash_critbit.c:454 > #5 0x000000000041cb51 in HSH_Lookup (sp=0x7f148f09b008, > poh=0x7f15103e6798) at cache_hash.c:345 > #6 0x0000000000411b10 in cnt_lookup (sp=0x7f148f09b008) at > cache_center.c:786 > #7 0x0000000000413f90 in CNT_Session (sp=0x7f148f09b008) at steps.h:38 > #8 0x0000000000424a78 in wrk_do_cnt_sess (w=0x7f15103f9e60, priv= optimized out>) at cache_pool.c:294 > #9 0x0000000000423d5d in wrk_thread_real (qp=0x7f225ea0b2e0, > shm_workspace=, sess_workspace=65536, > nhttp=64, http_space=, siov=128) at > cache_pool.c:183 > #10 0x00007f225f322367 in start_thread () from /lib64/libpthread.so.0 > #11 0x00007f225ebfdf7d in clone () from /lib64/libc.so.6 > > Running with `-h classic` is running much longer so far. > > nothing in the varnish stats or params looks off. vcl is identical to > working(ish) 2.0 series aside from the obj->beresp replacement. New description: I'm able to run varnish 2.1.x with critbit as the default hash table for 1-15 minutes, then a full thread hang happens. combined thread stack: {{{ 6011 5844 Lck__Lock,hcb_lookup,HSH_Lookup[...] 153 writev,WRW_Flush,[...] 3 Lck__Lock,hcb_deref,HSH_DerefObjCore[...] 1 Lck_CondWait,wrk_herder_thread,start_thread,clone 1 poll,CLS_Poll,CLI_Run 1 TIM_sleep,wrk_herdtimer_thread 1 TIM_sleep,vca_sess_timeout_ticker }}} Most are locked within HSH_Lookup example full backtrace: {{{ #0 0x00007f225f328e74 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f225f324874 in _L_lock_106 () from /lib64/libpthread.so.0 #2 0x00007f225f3242e0 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000421e19 in Lck__Lock (lck=, p=0x44d0f8 "hcb_lookup", f=0x44ce1b "hash_critbit.c", l=454) at cache_lck.c:78 #4 0x000000000042e820 in hcb_lookup (sp=, noh=0x7f1476804a20) at hash_critbit.c:454 #5 0x000000000041cb51 in HSH_Lookup (sp=0x7f148f09b008, poh=0x7f15103e6798) at cache_hash.c:345 #6 0x0000000000411b10 in cnt_lookup (sp=0x7f148f09b008) at cache_center.c:786 #7 0x0000000000413f90 in CNT_Session (sp=0x7f148f09b008) at steps.h:38 #8 0x0000000000424a78 in wrk_do_cnt_sess (w=0x7f15103f9e60, priv=) at cache_pool.c:294 #9 0x0000000000423d5d in wrk_thread_real (qp=0x7f225ea0b2e0, shm_workspace=, sess_workspace=65536, nhttp=64, http_space=, siov=128) at cache_pool.c:183 #10 0x00007f225f322367 in start_thread () from /lib64/libpthread.so.0 #11 0x00007f225ebfdf7d in clone () from /lib64/libc.so.6 }}} Running with `-h classic` is running much longer so far. nothing in the varnish stats or params looks off. vcl is identical to working(ish) 2.0 series aside from the obj->beresp replacement. -- Comment(by phk): (Polished description) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 22 11:58:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Apr 2010 11:58:16 -0000 Subject: [Varnish] #684: Varnish 2.1.1 hangs with critbit enabled In-Reply-To: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> References: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> Message-ID: <054.23af40c1946dbad12d41beb9ddf89243@varnish-cache.org> #684: Varnish 2.1.1 hangs with critbit enabled ----------------------+----------------------------------------------------- Reporter: dormando | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): This is a lock order inversion (a deadlock), Working on a patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 23 05:17:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 23 Apr 2010 05:17:44 -0000 Subject: [Varnish] #684: Varnish 2.1.1 hangs with critbit enabled In-Reply-To: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> References: <045.146c9b0ca32ab205e8f3a999f25ebfb6@varnish-cache.org> Message-ID: <054.ec13c0c87ee51fcefab86ef1658d8dd9@varnish-cache.org> #684: Varnish 2.1.1 hangs with critbit enabled ----------------------+----------------------------------------------------- Reporter: dormando | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4717 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 23 16:20:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 23 Apr 2010 16:20:25 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null Message-ID: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> #685: Logging non-HTTP connections as null ------------------------+--------------------------------------------------- Reporter: joshdevins | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Keywords: | ------------------------+--------------------------------------------------- We have a load balancer setup in front of Varnish and it is simply doing a TCP health check against it. The resulting log lines when running varnishncsa are just a bunch of nulls: - - - [23/Apr/2010:18:13:20 +0200] "(null) (null) (null)" (null) - "-" "-" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 24 13:20:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 24 Apr 2010 13:20:00 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <047.9fcb9d7ed222a4e98ee12e293410d173@varnish-cache.org> References: <047.9fcb9d7ed222a4e98ee12e293410d173@varnish-cache.org> Message-ID: <056.316d8ff1cfbaac2e94cc9f45ba09bfcd@varnish-cache.org> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 1.1.2 Severity: major | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Comment(by mike3050): Replying to [comment:19 phk]: > Ok, so I think we can conclude that you simply were running into the 32bit limit. > > Varnish does use [http://zolpo.com/auto-insurance/ auto insurance quotes] oodles of VM, it's built to take advantage of the Virtual Memory system in the computer to the full extent possible, so that is not a problem indication. > > I'll close this ticket then. Thank you phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 08:50:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 08:50:16 -0000 Subject: [Varnish] #686: VCL doesn't account for duplicate headers with different content Message-ID: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> #686: VCL doesn't account for duplicate headers with different content ----------------------+----------------------------------------------------- Reporter: felix | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: vcl headers ----------------------+----------------------------------------------------- Using Chromium 5.0.342.9 on Linux with a forced refresh (Ctrl+F5) I get the following in Varnish 2.1.0 on Debian: {{{ 13 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 13 RxHeader c Cache-Control: max-age=0 13 RxHeader c Pragma: no-cache 13 RxHeader c Cache-Control: no-cache }}} whereas in Firefox I get: {{{ Firefox (3.6.3): 13 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100402 Namoroka/3.6.3 13 RxHeader c Pragma: no-cache 13 RxHeader c Cache-Control: no-cache }}} It seems that rfc2616 section 4.2 allows multiple duplicate headers so Chrome's behaviour is correct (but not traditional). Varnish seems to be only using the ''first'' one found. In the example of Chromium above, a VCL statement of 'req.http.Cache- Control' would be filled with 'max-age=0' whereas with Firefox it would be 'no-cache'. This makes tests for a forced refresh a little difficult. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 11:40:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 11:40:36 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.4c7c598f8ff6996f7a76d475a1bc50a8@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Changes (by kristian): * owner: => kristian * status: new => assigned Comment: Ok, that shouldn't go in varnishncsa. Just to confirm: This is just a tcp open and close, right? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 11:44:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 11:44:04 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.2c10063c3f40c9a1d6d1f0aff923f8a3@varnish-cache.org> #678: varnishd stops accepting requests ----------------------+----------------------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: hang stop responding ----------------------+----------------------------------------------------- Description changed by phk: Old description: > I have four balancers that ran 2.0.5 fine for months, and now I've > upgraded them to 2.1.0, and sometimes one (at random which one) seems to > hang. > > Varnishstat shows no requests coming in, and when I run varnishlog I only > see a lot of lines like this: > > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > > I don't see anything else that is strange.. The only thing I see in my > cacti monitoring is that responses go down, and active tcp connections go > up (probably as a result). Load of the balancers prior to the problem is > a normal 0.2-0.5. > > After restaring, in my syslog I see (strange the time is off by 2 hours > though, time was 13:34, all other daemons log ok) > > Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Manager got SIGINT > Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Stopping Child > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: child (65643) Started > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Closed > fds: 4 5 6 7 11 12 14 15 > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Child > starts > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said managed to > mmap 8589934592 bytes of 8589934592 > > I cannot reproduce it. New description: I have four balancers that ran 2.0.5 fine for months, and now I've upgraded them to 2.1.0, and sometimes one (at random which one) seems to hang. Varnishstat shows no requests coming in, and when I run varnishlog I only see a lot of lines like this: {{{ 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 }}} I don't see anything else that is strange.. The only thing I see in my cacti monitoring is that responses go down, and active tcp connections go up (probably as a result). Load of the balancers prior to the problem is a normal 0.2-0.5. After restaring, in my syslog I see (strange the time is off by 2 hours though, time was 13:34, all other daemons log ok) {{{ Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Manager got SIGINT Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Stopping Child Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: child (65643) Started Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Closed fds: 4 5 6 7 11 12 14 15 Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Child starts Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said managed to mmap 8589934592 bytes of 8589934592 }}} I cannot reproduce it. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 11:44:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 11:44:56 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.56d6b0c46a984e0b79a7d8998d2ac934@varnish-cache.org> #678: varnishd stops accepting requests ----------------------+----------------------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: hang stop responding ----------------------+----------------------------------------------------- Comment(by phk): Can you please test 2.1.1, (just released) it sounds like you have hit the critbit-deadlock that was fixed in 2.1.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 11:50:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 11:50:26 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.7dba0456e6863d386d461beed1842ccc@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by joshdevins): Correct. It's just testing the TCP connection, there's no HTTP request. This is the standard TCP health check from a BigIP (if that helps/matters). I'll attach varnishlog output too... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 12:12:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 12:12:58 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.47c2cc70569331db0f58728c3aa10c6f@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by joshdevins): Version affected is 2.1.0 (not trunk) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 26 13:56:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Apr 2010 13:56:34 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.5a6b4533974d01623477d3d4fa818ba8@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by joshdevins): Workaround: Removing the #if 0/#endif around line 390 did the trick. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 28 04:59:15 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Apr 2010 04:59:15 -0000 Subject: [Varnish] #687: Varnish, squid and apc Message-ID: <042.61148997d1c00f9569c2424784b2d1ae@varnish-cache.org> #687: Varnish, squid and apc -------------------+-------------------------------------------------------- Reporter: S2eve | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Hi, Can I use them together? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 28 11:54:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Apr 2010 11:54:35 -0000 Subject: [Varnish] #638: Assert error in VRT_ESI In-Reply-To: <044.4b6a2d3d1fdacb1b288692723d0ae263@varnish-cache.org> References: <044.4b6a2d3d1fdacb1b288692723d0ae263@varnish-cache.org> Message-ID: <053.b09545908afdd9734a0c6f622f0cebf7@varnish-cache.org> #638: Assert error in VRT_ESI ----------------------+----------------------------------------------------- Reporter: bertjan | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4743]) Restrict the esi action to vcl_fetch{} now that we have the VCC infrastructure to do so. Fixes:#638 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 30 09:25:15 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Apr 2010 09:25:15 -0000 Subject: [Varnish] #688: varnish doesn't work Message-ID: <042.8f30762555411d7407ced6b52b8ae242@varnish-cache.org> #688: varnish doesn't work -------------------+-------------------------------------------------------- Reporter: S2eve | Type: defect Status: new | Priority: highest Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- varnish doesn't seams to work on my server what's wrong? 0+00:04:16 server3.localhost.com Hitrate ratio: 0 0 0 Hitrate avg: 0.0000 0.0000 0.0000 1 . . N struct sess_mem 1 . . N struct sess 1 . . N struct smf 1 . . N large free smf 10 . . N worker threads 10 0.00 0.04 N worker threads created 1 . . N backends 34 0.00 0.13 SHM records 34 0.00 0.13 SHM writes 1073741824 . . bytes free 1 0.00 0.00 N vcl total 1 0.00 0.00 N vcl available 1 . . N total active purges 1 0.00 0.00 N new purges added -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 30 15:18:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Apr 2010 15:18:40 -0000 Subject: [Varnish] #689: Backend host "yui.yahooapis.com": resolves to multiple IPv4 addresses Message-ID: <048.3618c474eb742511695e79e1d86abfd1@varnish-cache.org> #689: Backend host "yui.yahooapis.com": resolves to multiple IPv4 addresses -------------------------+-------------------------------------------------- Reporter: diego.silva | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.0 Severity: major | Keywords: -------------------------+-------------------------------------------------- Piece of my code backend Portal { .host = "172.17.2.10"; .port = "80"; } backend yahoo { .host = "yui.yahooapis.com"; .port = "http"; } sub vcl_recv { elsif (req.url ~ "^/yui") { set req.backend = yahoo; } else { set req.backend = Portal; -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 30 15:31:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Apr 2010 15:31:27 -0000 Subject: [Varnish] #689: Backend host "yui.yahooapis.com": resolves to multiple IPv4 addresses In-Reply-To: <048.3618c474eb742511695e79e1d86abfd1@varnish-cache.org> References: <048.3618c474eb742511695e79e1d86abfd1@varnish-cache.org> Message-ID: <057.bbffdbbc754e872dbc081e49c13e983b@varnish-cache.org> #689: Backend host "yui.yahooapis.com": resolves to multiple IPv4 addresses -------------------------+-------------------------------------------------- Reporter: diego.silva | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.0 Severity: major | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This works exactly as advertised. If you want Varnish to try all these IP numbers, you must define a round- robin director which knows them all. A plain backend instance can have no more than one IP# in each family (ie: one IPv4 and one IPv6) -- Ticket URL: Varnish The Varnish HTTP Accelerator