From varnish-bugs at projects.linpro.no Mon Feb 1 09:01:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 09:01:19 -0000 Subject: [Varnish] #634: Race between HSH_Lookup and EXP_NukeOne In-Reply-To: <051.9ed4e0cd975a3a4a4492f75bc9da6753@projects.linpro.no> References: <051.9ed4e0cd975a3a4a4492f75bc9da6753@projects.linpro.no> Message-ID: <060.2f643ec132100f573d358875a2a52195@projects.linpro.no> #634: Race between HSH_Lookup and EXP_NukeOne ----------------------+----------------------------------------------------- Reporter: mpage | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4516. Thanks a lot, it's no problem fixing bugs with tickets of this quality :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 10:21:11 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 10:21:11 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.1fb0950f44f8e098af2239eb6bdfd8a6@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Old description: > Something happened with the varnish instance and it went down with the > following error message, but it seems from the error message that it > started back again. It was failing to proxy to Apache and resulting on a > 404 till it was restarted. unfortunately no coredumps. > > I am running varnishd (varnish-2.0.4). compiled. > > uname -a > 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 > x86_64 GNU/Linux > CentOS release 5.3 (Final) > > Jan 11 03:50:17 web2 varnishd[8785]: Child (8786) died signal=6<131>Jan > 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in > WSL_Flush(), shmlog.c line 196: Condition(loghead->ptr < loghead->size) > not true. thread = (cache-worker)sp = 0x2aaaeb317008 { fd = 10, id = 10, > xid = 0, client = 10.4.4.5:60313, step = STP_DONE, handling = deliver, ws > = 0x2aaaeb317078 { id = "sess", {s,f,r,e} = > {0x2aaaeb317808,,+256,(nil),+16384}, }, worker = 0x40adcbe0 { }, }, > > Jan 11 03:50:17 web2 varnishd[8785]: child (24840) Started > Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Closed fds: 4 5 6 > 11 12 14 15 > Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Child starts > Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said managed to mmap > 1073741824 bytes of 1073741824 > Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Ready > > Please help! New description: Something happened with the varnish instance and it went down with the following error message, but it seems from the error message that it started back again. It was failing to proxy to Apache and resulting on a 404 till it was restarted. unfortunately no coredumps. I am running varnishd (varnish-2.0.4). compiled. {{{ uname -a 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux CentOS release 5.3 (Final) Jan 11 03:50:17 web2 varnishd[8785]: Child (8786) died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush(), shmlog.c line 196: Condition(loghead->ptr < loghead->size) not true. thread = (cache-worker)sp = 0x2aaaeb317008 { fd = 10, id = 10, xid = 0, client = 10.4.4.5:60313, step = STP_DONE, handling = deliver, ws = 0x2aaaeb317078 { id = "sess", {s,f,r,e} = {0x2aaaeb317808,,+256,(nil),+16384}, }, worker = 0x40adcbe0 { }, }, Jan 11 03:50:17 web2 varnishd[8785]: child (24840) Started Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Closed fds: 4 5 6 11 12 14 15 Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Child starts Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said managed to mmap 1073741824 bytes of 1073741824 Jan 11 03:50:17 web2 varnishd[8785]: Child (24840) said Ready }}} Please help! Comment (by phk): fixed formatting -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 10:21:48 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 10:21:48 -0000 Subject: [Varnish] #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page In-Reply-To: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> References: <056.8d86f10a5074836d7b9d35fa20590ded@projects.linpro.no> Message-ID: <065.8832c7b57c0bc37dd952025a92c6205f@projects.linpro.no> #637: Subversion ask for authentication which is not mentioned in the "Using Subversion" Wiki page --------------------------------+------------------------------------------- Reporter: gladandong | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: invalid Keywords: svn authentication | --------------------------------+------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 10:22:47 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 10:22:47 -0000 Subject: [Varnish] #639: Assert on writing to CLI when child process dies In-Reply-To: <049.774ff00582bdc8c382ad6786fed4376c@projects.linpro.no> References: <049.774ff00582bdc8c382ad6786fed4376c@projects.linpro.no> Message-ID: <058.71564df25d5a59a4b95fa00a10624e39@projects.linpro.no> #639: Assert on writing to CLI when child process dies ------------------------------+--------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: 2.0.6 CLI assert | ------------------------------+--------------------------------------------- Old description: > varnishd 2.0.6 on Debian Lenny amd64. > > When a child dies: > > Jan 29 10:51:10 webcache4 varnishd[24741]: Child (24742) not responding > to ping, killing it. > Jan 29 10:51:12 webcache4 varnishd[24741]: Child (24742) not responding > to ping, killing it. > > and there's a CLI command being written to the child, an xxxassert() is > raised: > > #3 0x000000000042ef64 in mgt_cli_vlu (priv=0x7fb112813c00, > p=0x7fb1128d3000 "debug.health") at mgt_cli.c:270 > 270 xxxassert(i == strlen(p)); > > The master process should handle the unfinished write(), rather than > aborting. > > As a dirty interim fix, it *should* be OK to ignore the unfinished write, > like in the attached patch. New description: varnishd 2.0.6 on Debian Lenny amd64. When a child dies: {{{ Jan 29 10:51:10 webcache4 varnishd[24741]: Child (24742) not responding to ping, killing it. Jan 29 10:51:12 webcache4 varnishd[24741]: Child (24742) not responding to ping, killing it. }}} and there's a CLI command being written to the child, an xxxassert() is raised: {{{ #3 0x000000000042ef64 in mgt_cli_vlu (priv=0x7fb112813c00, p=0x7fb1128d3000 "debug.health") at mgt_cli.c:270 270 xxxassert(i == strlen(p)); }}} The master process should handle the unfinished write(), rather than aborting. As a dirty interim fix, it *should* be OK to ignore the unfinished write, like in the attached patch. Comment (by phk): fixed formatting -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 10:36:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 10:36:53 -0000 Subject: [Varnish] #639: Assert on writing to CLI when child process dies In-Reply-To: <049.774ff00582bdc8c382ad6786fed4376c@projects.linpro.no> References: <049.774ff00582bdc8c382ad6786fed4376c@projects.linpro.no> Message-ID: <058.7bdedc161b64f601cfa86c1e671d2832@projects.linpro.no> #639: Assert on writing to CLI when child process dies ------------------------------+--------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: 2.0.6 CLI assert | ------------------------------+--------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4517]) Don't assert on write errors to the child process CLI-pipe, it might simply be dying on us. Instead return the designed error code for this: CLIS_COMM Fixes #639 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 12:15:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 12:15:17 -0000 Subject: [Varnish] #638: Assert error in VRT_ESI In-Reply-To: <053.1a058ad76c409bcb807363e643479c33@projects.linpro.no> References: <053.1a058ad76c409bcb807363e643479c33@projects.linpro.no> Message-ID: <062.0f32e8fa48e72837f6491f57dd973345@projects.linpro.no> #638: Assert error in VRT_ESI ----------------------+----------------------------------------------------- Reporter: bertjan | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: phk => tfheen Comment: You're calling esi; in vcl_recv, which is not where you should do that. Do it in vcl_fetch. I'll leave this bug open so we can make sure this VCL doesn't compile, since it shouldn't. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 12:20:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 12:20:00 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <053.3fe84c47e21693296422d51486362696@projects.linpro.no> References: <053.3fe84c47e21693296422d51486362696@projects.linpro.no> Message-ID: <062.d507d9d0d28ee151c8186d802421ea57@projects.linpro.no> #633: varnishncsa segfaults ---------------------+------------------------------------------------------ Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by kristian): * owner: => kristian * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 12:34:13 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 12:34:13 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.143bc5fa66ecb87358128e33998a1fc4@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Changes (by phk): * owner: kristian => phk * status: assigned => new Comment: Kristian did some investigation, and we are pretty certain that the problem is that the old child process is not dead, and still writes to the shared memory segment. In general, it is a bad idea to kill the varnish master process because the child does not do what you want, the master is there to restart the child if it dies, so if you killed the child process instead, you would get exactly the behaviour you want. I will look into trying to detect and spit out a sensible error message in this case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 13:06:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 13:06:32 -0000 Subject: [Varnish] #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" In-Reply-To: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> References: <053.75f2e320e780eebef2f5f76b86d830b3@projects.linpro.no> Message-ID: <062.6227212081d68f3acf78e5da61be4a3b@projects.linpro.no> #620: error message from varnish "died signal=6<131>Jan 11 03:50:17 varnishd[8785]: Child (8786) Panic message: Assert error in WSL_Flush()" ---------------------------+------------------------------------------------ Reporter: sprasad | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: varnish 2.0.4 | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4520]) Add the master and child pid's to the SHMFILE. If the master pid is active when we start, we issue a message about this, (with a hint about -n) and exit. If the master pid is not active, but the child pid is, we issue a message about it presumably being busy dying, dump the SHMFILE and create a new one. (This only saves our bacon, if the dying process manages to close the listening sockets before we need them). This should end any confusion that might arise from accidentally running multiple varnishes at the same time. Fixes #620 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 13:25:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 13:25:04 -0000 Subject: [Varnish] #622: restart of varnishd sometimes fails on busy server In-Reply-To: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> References: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> Message-ID: <063.464fc856839b3b55ea541f0a503c1432@projects.linpro.no> #622: restart of varnishd sometimes fails on busy server ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4521]) When we detect the parent absconding the CLI pipes, close the acceptor sockets as fast as we can, so that a new copy of varnishd can get at them. Fixes #622 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 13:25:56 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 13:25:56 -0000 Subject: [Varnish] #622: restart of varnishd sometimes fails on busy server In-Reply-To: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> References: <054.4fa3b343e691a5fce79626f20450bd55@projects.linpro.no> Message-ID: <063.072eec45e41fb351d2e2dfc7b12b32ba@projects.linpro.no> #622: restart of varnishd sometimes fails on busy server ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Just a final footnote, that the fixes for #620 in r4520 are also relevant here. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 19:47:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 19:47:57 -0000 Subject: [Varnish] #590: Assert error in ESI_Parse(), cache_esi.c line 822: Condition(st->len < st->space) not true. In-Reply-To: <050.18b8c0fcb73b96bb78d3b132f35e6485@projects.linpro.no> References: <050.18b8c0fcb73b96bb78d3b132f35e6485@projects.linpro.no> Message-ID: <059.1e41eacbe4c8db29e3b0edf26a31c3ce@projects.linpro.no> #590: Assert error in ESI_Parse(), cache_esi.c line 822: Condition(st->len < st->space) not true. ------------------------------+--------------------------------------------- Reporter: kali | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: esi parser crash | ------------------------------+--------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Your +1 workaround did throw me of the scent for a moment and it certainly prevents the problem. The true fix is to repair the wrong assert (see r4523). Thanks for your patience. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 20:08:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 20:08:19 -0000 Subject: [Varnish] #592: Too many arguments for some macros causes varnishd.1 to be rendered incorrectly In-Reply-To: <051.7c8467608f0db910836a706d7f5aa972@projects.linpro.no> References: <051.7c8467608f0db910836a706d7f5aa972@projects.linpro.no> Message-ID: <060.b1e7a4d3d8237ce15ff32e9b4e6887f1@projects.linpro.no> #592: Too many arguments for some macros causes varnishd.1 to be rendered incorrectly ---------------------------+------------------------------------------------ Reporter: fgsch | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4525]) Mdoc manual page adjustments. Fixes #592 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 20:11:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 20:11:31 -0000 Subject: [Varnish] #366: CLI Communication Error when calling vcl.discard in management interface In-Reply-To: <052.1727b4b0db11f5c555d134fb64c4b0fd@projects.linpro.no> References: <052.1727b4b0db11f5c555d134fb64c4b0fd@projects.linpro.no> Message-ID: <061.59b6291a9f0086e5b102bef499a9fdea@projects.linpro.no> #366: CLI Communication Error when calling vcl.discard in management interface -------------------------------------------------------------+-------------- Reporter: foxdie | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: worksforme Keywords: cli, communication, error, vcl.discard, discard | -------------------------------------------------------------+-------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out for lack of response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 20:13:25 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 20:13:25 -0000 Subject: [Varnish] #350: Get pagesize from getpagesize() instead of hardcoding it In-Reply-To: <052.bdb100a7e21a62e5ee007fcf0dd452a5@projects.linpro.no> References: <052.bdb100a7e21a62e5ee007fcf0dd452a5@projects.linpro.no> Message-ID: <061.1199ba81a16b0abee1c9f7e2d6513383@projects.linpro.no> #350: Get pagesize from getpagesize() instead of hardcoding it --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Time this ticket out. I belive we do now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:08:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:08:38 -0000 Subject: [Varnish] #419: param esi syntax not documented In-Reply-To: <051.7373329eae51a8db9500657bbbf1f391@projects.linpro.no> References: <051.7373329eae51a8db9500657bbbf1f391@projects.linpro.no> Message-ID: <060.0fee7c2e8387f4c5c47e13222aa15a28@projects.linpro.no> #419: param esi syntax not documented ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4527]) Evict the entire section about run-time parameters and replace with a table produced from the CLI parameter tables. In the future all updates to these descriptions SHALL happen in the CLI tables in the C source code. Fixes #419 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:20:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:20:32 -0000 Subject: [Varnish] #231: Assert error in VCL_recv_method() In-Reply-To: <050.fbea24182c47bf0fcc9c91aa22ab50f1@projects.linpro.no> References: <050.fbea24182c47bf0fcc9c91aa22ab50f1@projects.linpro.no> Message-ID: <059.63250cc2f1eb4e95063e845822414de6@projects.linpro.no> #231: Assert error in VCL_recv_method() ----------------------+----------------------------------------------------- Reporter: Bart | 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 ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:23:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:23:00 -0000 Subject: [Varnish] #265: Implement nuke option to invalidate all variants of an object In-Reply-To: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> References: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> Message-ID: <058.63df1da3e1f16c288d7f21dd8811fed8@projects.linpro.no> #265: Implement nuke option to invalidate all variants of an object -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Close this ticket, it is a feature-request and has lived on the PostTwoShoppingList for a long time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:24:22 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:24:22 -0000 Subject: [Varnish] #268: Make 304 and Last-Modified work with ESI In-Reply-To: <049.562ba092d4a09f6f293514999f686752@projects.linpro.no> References: <049.562ba092d4a09f6f293514999f686752@projects.linpro.no> Message-ID: <058.cc48be4068a0adc620a913db46150f5b@projects.linpro.no> #268: Make 304 and Last-Modified work with ESI -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Close this ticket, it is a feature request and has lived in PostTwoShoppingList for a long time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:25:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:25:53 -0000 Subject: [Varnish] #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: In-Reply-To: <049.e144e52043f1621b2c25b91f9073f773@projects.linpro.no> References: <049.e144e52043f1621b2c25b91f9073f773@projects.linpro.no> Message-ID: <058.41b0ece37df9e5d8004d87b0d50a7688@projects.linpro.no> #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: --------------------+------------------------------------------------------- Reporter: sky | Owner: 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: Time this ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:26:25 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:26:25 -0000 Subject: [Varnish] #340: Silent failure on config error when starting as a daemon in CentOS5.2 In-Reply-To: <053.fdef91f2eeb4bff301a3a41b5007a4cf@projects.linpro.no> References: <053.fdef91f2eeb4bff301a3a41b5007a4cf@projects.linpro.no> Message-ID: <062.47f785bb197a64991f28c339eb67a0db@projects.linpro.no> #340: Silent failure on config error when starting as a daemon in CentOS5.2 -----------------------+---------------------------------------------------- Reporter: marlier | Owner: ingvar Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: beta2 | -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:27:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:27:06 -0000 Subject: [Varnish] #344: varnish won't build on ppc/ppc64 using jemalloc In-Reply-To: <052.af7ccd95f6e79e73c54f11a039e753d3@projects.linpro.no> References: <052.af7ccd95f6e79e73c54f11a039e753d3@projects.linpro.no> Message-ID: <061.13d3d19222d0abec3f6bcc59fccf5db9@projects.linpro.no> #344: varnish won't build on ppc/ppc64 using jemalloc --------------------+------------------------------------------------------- Reporter: ingvar | Owner: 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: Time this ticket out. Reopen if still at problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:28:12 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:28:12 -0000 Subject: [Varnish] #280: Workspace overflows give confusing error messaqe In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.7d1413dd0949d6630e5b8f200b573b9d@projects.linpro.no> #280: Workspace overflows give confusing error messaqe ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this out. We know better workspace diagnostics, or dynamic workspaces are the way to go. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:29:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:29:24 -0000 Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> Message-ID: <060.e78202d5d33a149bc8b072085f4293d6@projects.linpro.no> #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed ----------------------+----------------------------------------------------- Reporter: peter | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Time this ticket out. Better 304/ESI interaction has been on our PostTwoShoppingList for a long time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:30:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:30:37 -0000 Subject: [Varnish] #357: Varnish exits quietly when arguments to -a or -T resolves to multiple, similar IP addresses In-Reply-To: <049.9f614c149e511516cbb17ff505bd0570@projects.linpro.no> References: <049.9f614c149e511516cbb17ff505bd0570@projects.linpro.no> Message-ID: <058.91d40a8deee334f5f0b97d1630d27789@projects.linpro.no> #357: Varnish exits quietly when arguments to -a or -T resolves to multiple, similar IP addresses ----------------------+----------------------------------------------------- Reporter: ssm | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Varnish handles both and has done so for quite some time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:33:51 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:33:51 -0000 Subject: [Varnish] #358: pre-allocated cache file gets shrunk on start of varnishd In-Reply-To: <052.cad7b471086d56fbda7c33534524c287@projects.linpro.no> References: <052.cad7b471086d56fbda7c33534524c287@projects.linpro.no> Message-ID: <061.1e6c2b9bc94145fc6ac487bb56ab965b@projects.linpro.no> #358: pre-allocated cache file gets shrunk on start of varnishd --------------------+------------------------------------------------------- Reporter: sascha | Owner: 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 think the way it works now is how we want it to work: either you specify a size, or the default size is used. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:44:12 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:44:12 -0000 Subject: [Varnish] #382: varnishncsa is leaking In-Reply-To: <056.b1479d969d8ea2c19febb9535df4b4e3@projects.linpro.no> References: <056.b1479d969d8ea2c19febb9535df4b4e3@projects.linpro.no> Message-ID: <065.d45bf67cf85fcbe7f3646b8b4f695a66@projects.linpro.no> #382: varnishncsa is leaking -------------------------+-------------------------------------------------- Reporter: chrisrixon | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishncsa | Version: 2.0 Severity: major | Resolution: worksforme Keywords: leak | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out, I think this is fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:44:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:44:50 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.81c17fd9397ede99cc61dd976c64f2b9@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:45:18 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:45:18 -0000 Subject: [Varnish] #429: Segfault in expire timer thread In-Reply-To: <049.82d6da0e75374723f1d3ca37c4634c37@projects.linpro.no> References: <049.82d6da0e75374723f1d3ca37c4634c37@projects.linpro.no> Message-ID: <058.5afc5f5ce7c7a4b843a6e02c0458f71d@projects.linpro.no> #429: Segfault in expire timer thread --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out, belived fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:49:28 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:49:28 -0000 Subject: [Varnish] #515: Crash with persistent after seconds - no assert error In-Reply-To: <054.9e550955107166b204a6a2c093641b7f@projects.linpro.no> References: <054.9e550955107166b204a6a2c093641b7f@projects.linpro.no> Message-ID: <063.db00fe2307428748cbcedaa98a230041@projects.linpro.no> #515: Crash with persistent after seconds - no assert error ----------------------+----------------------------------------------------- Reporter: kristian | 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, I belive this is long since fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:50:18 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:50:18 -0000 Subject: [Varnish] #479: segfault with -s persistent in trunk as of r4002 In-Reply-To: <049.6f83aa5ef54bbfaea94f3b33540b532a@projects.linpro.no> References: <049.6f83aa5ef54bbfaea94f3b33540b532a@projects.linpro.no> Message-ID: <058.0ce31b73035de2f41e310888ac02a72b@projects.linpro.no> #479: segfault with -s persistent in trunk as of r4002 --------------------+------------------------------------------------------- Reporter: sky | Owner: 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: Time this ticket out, I belive this is long since fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 21:50:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 21:50:42 -0000 Subject: [Varnish] #480: segfault with -s file In-Reply-To: <049.0acebd74ae9d0810100ecc78b413bd7e@projects.linpro.no> References: <049.0acebd74ae9d0810100ecc78b413bd7e@projects.linpro.no> Message-ID: <058.2e0d3d9eef9d3753189aca401ad903ff@projects.linpro.no> #480: segfault with -s file --------------------+------------------------------------------------------- Reporter: sky | Owner: 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: Time this out, I belive this has been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 1 22:04:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Feb 2010 22:04:21 -0000 Subject: [Varnish] #446: r00387 fails from time to time In-Reply-To: <052.daab10e68b4faa97dda03a193d86727e@projects.linpro.no> References: <052.daab10e68b4faa97dda03a193d86727e@projects.linpro.no> Message-ID: <061.c9b77e40e1c889dc775615403684a3e3@projects.linpro.no> #446: r00387 fails from time to time --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: worksforme Keywords: 2.0.3 | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Timed out, believed fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 2 14:06:46 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Feb 2010 14:06:46 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.92b3c2bb4a7225c7a5292df3d5814c12@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Can you please test if this is still a problem in -trunk ? As far as I know, the problem does not exist in -trunk, because we use Connection: close on ESI delivery, if the client is not HTTP/1.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 2 22:57:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Feb 2010 22:57:50 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.f54a3c9aa15cfefc9b331e779fa0cdea@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by atppp): No, it's not fixed. {{{ > GET /*****/ HTTP/1.0 > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:8081 > Accept: */* > Connection: Keep-Alive > < HTTP/1.1 200 OK < Server: ***** < Last-Modified: Thu, 28 Jan 2010 21:53:00 GMT < Content-Type: text/html < Date: Tue, 02 Feb 2010 22:55:03 GMT < X-Varnish: 27218680 27218679 < Age: 7 < Via: 1.1 varnish < Connection: keep-alive }}} (here curl hangs 5 secs) `ab -k -n 5 url` gives 5sec/request. tested with varnish r4528. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 2 23:38:25 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Feb 2010 23:38:25 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.0b44b96c6a8601db1ead26454c32395a@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Thanks, that helped men nail it. Fixed in r4529. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 00:23:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 00:23:50 -0000 Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no> Message-ID: <063.d85ea1c68052f0f0cf70d9126dfd1fbb@projects.linpro.no> #524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by atppp): Great. Confirm it's fixed with our application. Thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From jhayter at manta.com Tue Feb 2 21:55:33 2010 From: jhayter at manta.com (Jim Hayter) Date: Tue, 2 Feb 2010 16:55:33 -0500 Subject: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <062.5d0a75139fc8ecb183811b3589e6b955@projects.linpro.no> References: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> <062.5d0a75139fc8ecb183811b3589e6b955@projects.linpro.no> Message-ID: I am not currently able to follow up on this. When we had the issues with Solaris, we also had some new hardware arrive. I was given two systems, 1 running CentOS and one running Ubuntu to install varnish on. We are currently running with these systems in front of our web servers and I am trying to get caught up with configuring the two front end systems for production use. Jim -----Original Message----- From: varnish-bugs at projects.linpro.no [mailto:varnish-bugs at projects.linpro.no] Sent: Monday, January 25, 2010 11:45 AM Cc: varnish-bugs at projects.linpro.no Subject: Re: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 ----------------------+----------------------------------------------------- Reporter: jhayter | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Please try to set parameter "waiter" to "poll" and report if that makes a difference. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 13:58:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 13:58:57 -0000 Subject: [Varnish] #452: Support for chunked transfers on client requests In-Reply-To: <050.93acef03d0f4f2015972fae3662b5932@projects.linpro.no> References: <050.93acef03d0f4f2015972fae3662b5932@projects.linpro.no> Message-ID: <059.6fac36fe37fd1e5e984ec8d8b4cbeaa6@projects.linpro.no> #452: Support for chunked transfers on client requests -------------------------+-------------------------------------------------- Reporter: joel | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: I agree that this should be done. I have moved it to our PostTwoShoppingList with other feature requests. (We try to keep tickets for bugs) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:00:51 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:00:51 -0000 Subject: [Varnish] #447: ESI chunked output fails if included content served via HTTP/1.0 In-Reply-To: <050.3392d3a760cc095c5ed11cd573e59fa3@projects.linpro.no> References: <050.3392d3a760cc095c5ed11cd573e59fa3@projects.linpro.no> Message-ID: <059.dc6ba6ec79f4058d9efc644137f78435@projects.linpro.no> #447: ESI chunked output fails if included content served via HTTP/1.0 ----------------------+----------------------------------------------------- Reporter: jayk | 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: First of all, I'm a little bit confused about the description, but assume you mean that the clients contact varnish with HTTP/1.0 and that the backend is not involved in this, as such. I belive this problem is fixed, see ticket #524 for details. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:06:35 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:06:35 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.96286c38469ddc25feacbcd136a52d42@projects.linpro.no> #310: WS_Reserve panic + error ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: The new allocation policy for objects, forced on us by the persistent stevedore, makes it impossible to change objects headers once they are created. In response to this, we have made a number of changes to the VCL, including the move in vcl_fetch from obj.* to beresp.*. In this light, this ticket is now invalid, in the sense that it has been overtaken by events. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:07:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:07:42 -0000 Subject: [Varnish] #438: varnish hangs upon hot reconfiguration In-Reply-To: <053.dba0b7fe61d70346b1a6b6563506acb7@projects.linpro.no> References: <053.dba0b7fe61d70346b1a6b6563506acb7@projects.linpro.no> Message-ID: <062.d08843d9c836e7dcddb66c1eb1206d6f@projects.linpro.no> #438: varnish hangs upon hot reconfiguration ----------------------+----------------------------------------------------- Reporter: solatis | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Time out for lack of response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:10:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:10:04 -0000 Subject: [Varnish] #470: cryptic error message when drive is full In-Reply-To: <054.da702999a39b226cda07dfa84b3c1c6d@projects.linpro.no> References: <054.da702999a39b226cda07dfa84b3c1c6d@projects.linpro.no> Message-ID: <063.7268feebd39129021106c19dad295f75@projects.linpro.no> #470: cryptic error message when drive is full -------------------------+-------------------------------------------------- Reporter: jacquesm | Owner: kristian Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I don't think that message is given anymore, at least I cannot reproduce it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:10:43 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:10:43 -0000 Subject: [Varnish] #478: Panic: Condition(ws->f + b2 <= ws->e) not true. thread = (cache-worker)sp = 0x7efb0a086008 { In-Reply-To: <049.f648c173e8bd404a9c9a20699d436a12@projects.linpro.no> References: <049.f648c173e8bd404a9c9a20699d436a12@projects.linpro.no> Message-ID: <058.11314ee628a8f103158a762d96caab8f@projects.linpro.no> #478: Panic: Condition(ws->f + b2 <= ws->e) not true. thread = (cache-worker)sp = 0x7efb0a086008 { --------------------+------------------------------------------------------- Reporter: sky | Owner: 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: Presumably this is overtaken by events. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:40:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:40:01 -0000 Subject: [Varnish] #224: Improved logging In-Reply-To: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no> References: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no> Message-ID: <058.66a14e3cc88e4b3edd06d1929698305e@projects.linpro.no> #224: Improved logging -------------------------+-------------------------------------------------- Reporter: des | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => invalid Comment: This is a feature request (a sensible one I might add) and has been on the PostTwoShoppingList, where we track feature requests, for ages. So this ticket can be closed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:41:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:41:53 -0000 Subject: [Varnish] #519: 503 error problem In-Reply-To: <052.b54f7a7932a5fbc3946b8e6cd550fd74@projects.linpro.no> References: <052.b54f7a7932a5fbc3946b8e6cd550fd74@projects.linpro.no> Message-ID: <061.67d0029001975372633a77bab45e756e@projects.linpro.no> #519: 503 error problem -----------------------+---------------------------------------------------- Reporter: silver | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: 503 error | -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This ticket does not seem to contain any bugs in varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:44:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:44:00 -0000 Subject: [Varnish] #516: vsl_mtx "deadlock"; child stops responding In-Reply-To: <048.692a2d331dfd2cef931d98d5b3e067c5@projects.linpro.no> References: <048.692a2d331dfd2cef931d98d5b3e067c5@projects.linpro.no> Message-ID: <057.433cb58e44d76c0f2c1f61108e0b5d3c@projects.linpro.no> #516: vsl_mtx "deadlock"; child stops responding ----------------------+----------------------------------------------------- Reporter: kb | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this ticket out, no other reports in the meantime and plenty of bugfixes that could have caused this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:44:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:44:52 -0000 Subject: [Varnish] #511: Repeating segfault In-Reply-To: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> References: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> Message-ID: <058.0e98e4103899d6ce7b6bb10fc50be04d@projects.linpro.no> #511: Repeating segfault ----------------------+----------------------------------------------------- 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: Time this one out for lack of anything we can do about it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:46:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:46:37 -0000 Subject: [Varnish] #510: Age of objects with 2 varnishes in front of each other In-Reply-To: <054.3b06386eb2eccf58118d145bfed9f2e1@projects.linpro.no> References: <054.3b06386eb2eccf58118d145bfed9f2e1@projects.linpro.no> Message-ID: <063.33209f0440923b5afac4901274dbbe16@projects.linpro.no> #510: Age of objects with 2 varnishes in front of each other ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: 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 think we have fixed this one. If not, please reopen the ticket, preferably with varnishlog traces from both varnishes if possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:48:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:48:04 -0000 Subject: [Varnish] #449: Crash in cache_ws.c with Varnish 2.0.3 In-Reply-To: <052.22242a63723f99d4f3e13e394d7f20f2@projects.linpro.no> References: <052.22242a63723f99d4f3e13e394d7f20f2@projects.linpro.no> Message-ID: <061.2bc0fdd15bfc3acc3030bb46b55a9f5b@projects.linpro.no> #449: Crash in cache_ws.c with Varnish 2.0.3 ----------------------+----------------------------------------------------- Reporter: stonor | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time this one out. I belive this was fixed. Else, reopen ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:48:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:48:41 -0000 Subject: [Varnish] #373: Varnish fails to reload backend/directory In-Reply-To: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> References: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> Message-ID: <061.751a0043c166acc3a535e1f33a06a772@projects.linpro.no> #373: Varnish fails to reload backend/directory ----------------------+----------------------------------------------------- Reporter: anders | 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: I belive this has been fixed. I tried to reproduce and could not. Reopen if observed again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:50:30 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:50:30 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> Message-ID: <063.1b7f496d3ef4bda77be0d80b330df7a6@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Can you still reproduce this in -trunk ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:50:55 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:50:55 -0000 Subject: [Varnish] #491: Crash in 2.0.4 In-Reply-To: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> References: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> Message-ID: <058.c8e9b2a5c7aec3928e6210f1d242876f@projects.linpro.no> #491: Crash in 2.0.4 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: time this ticket out. Belived fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 14:51:56 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 14:51:56 -0000 Subject: [Varnish] #398: logging off phpbb always causes "Error 503 Service Unavailable" In-Reply-To: <053.fcc528fb5f49a4e239de8466a1c0a6d5@projects.linpro.no> References: <053.fcc528fb5f49a4e239de8466a1c0a6d5@projects.linpro.no> Message-ID: <062.93a378a7ff1a8af9887d09d5813124ff@projects.linpro.no> #398: logging off phpbb always causes "Error 503 Service Unavailable" -------------------------------------------+-------------------------------- Reporter: mmpower | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: Error 503 Service Unavailable | -------------------------------------------+-------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Time this ticket out, max number of HTTP headers is now a parameter. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 21:56:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 21:56:50 -0000 Subject: [Varnish] #640: varnishtest uses CLOCK_REALTIME instead of TIM_real Message-ID: <051.dab04b2fd5f54694875d7f3dba890797@projects.linpro.no> #640: varnishtest uses CLOCK_REALTIME instead of TIM_real -------------------+-------------------------------------------------------- Reporter: dugan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- In vcl.c, about line 512: - AZ(clock_gettime(CLOCK_REALTIME, &ts)); - ts.tv_sec += dur; + ts.tv_sec += TIM_real(); This keeps varnish from building on macs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 22:30:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 22:30:31 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding Message-ID: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding -------------------+-------------------------------------------------------- Reporter: dugan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- If I make a 1.1 request I get back a 1.0 response back with chunked transfer encoding, which is illegal. Sending a 1.0 request disables chunked encoding and thus works fine. {{{ curl -I http://localhost HTTP/1.0 200 OK Server: WSGIServer/0.1 Python/2.5.4 Expires: Wed, 03 Feb 2010 22:36:40 GMT Vary: Cookie Last-Modified: Wed, 03 Feb 2010 22:26:40 GMT ETag: "4c74c849522231611b0205d0e25b73e1" Cache-Control: max-age=600 Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Date: Wed, 03 Feb 2010 22:26:50 GMT X-Varnish: 988210263 988210261 Age: 10 Via: 1.1 varnish Connection: keep-alive }}} {{{ curl -0 -I http://localhost HTTP/1.0 200 OK Server: WSGIServer/0.1 Python/2.5.4 Expires: Wed, 03 Feb 2010 22:36:40 GMT Vary: Cookie Last-Modified: Wed, 03 Feb 2010 22:26:40 GMT ETag: "4c74c849522231611b0205d0e25b73e1" Cache-Control: max-age=600 Content-Type: text/html; charset=utf-8 Date: Wed, 03 Feb 2010 22:28:15 GMT X-Varnish: 988210264 988210261 Age: 95 Via: 1.1 varnish Connection: close }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 3 22:57:30 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Feb 2010 22:57:30 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.998836794b8e216df70a24dda6fa4327@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding --------------------+------------------------------------------------------- Reporter: dugan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by dugan): I've attached a potential fix - it forces the 1.1 header to be returned if the chunked encoding is being used. Not sure if this is correct, and am not sure of the other use of the function, but it does solve my problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 03:47:09 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 03:47:09 -0000 Subject: [Varnish] #642: log buffer (VSL) can get corrupted Message-ID: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> #642: log buffer (VSL) can get corrupted ------------------------+--------------------------------------------------- Reporter: Tv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- I had varnishd behave oddly, didn't really manage to debug fully but got reports of delays in serving. "varnishlog" showed no new entries even if I knew it was serving. "varnishlog -d" ended with {{{ 0 Backend_health - linkubate_api[2] Still healthy 4--X-S-RH 8 3 8 0.001422 0.001540 HTTP/1.0 200 OK 0 Backend_health - pix 13357 (null) - -X-S-RH 8 3 8 0.001592 0.001526 HTTP/1.0 200 OK 29556 (null) - art 24946 ObjStatus - t }}} which looked like corruption. Even with varnishd shut down, "varnishlog -d" behaved the same. I removed the /var/lib/varnish/$HOSTNAME/_.vsl file, started varnishd again, and everything went back to normal. Unfortunately, I don't have a copy of the corrupted file. It may have been corrupted by a kernel/virtualization bug. Wouldn't it make sense for varnishd to not trust the old file contents when it starts up? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 08:17:28 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 08:17:28 -0000 Subject: [Varnish] #642: log buffer (VSL) can get corrupted In-Reply-To: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> References: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> Message-ID: <057.bf589c3f0774884f233b9b88bef3ba3b@projects.linpro.no> #642: log buffer (VSL) can get corrupted ------------------------+--------------------------------------------------- Reporter: Tv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): Well, the corruption would have to come from varnishd, since varnishlog opens the shared memory segment read-only. We've seen things like it, if two varnishd processes were started with the same (or no) -n argument. A recent commit added some pid-checks to try to prevent that. Is there any chance that two concurrent varnishd processes could explain your observation ? Typically it would be something like killing varnishd (the master process) and restarting it, before the worker process of the first varnishd had terminated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 08:24:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 08:24:01 -0000 Subject: [Varnish] #642: log buffer (VSL) can get corrupted In-Reply-To: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> References: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> Message-ID: <057.aef7eb694b3e241369121b2bc058cb2c@projects.linpro.no> #642: log buffer (VSL) can get corrupted ------------------------+--------------------------------------------------- Reporter: Tv | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by Tv): I don't think it was caused by two varnishds using the same file, but that is possible. As far as I'm concerned (and because I didn't save a copy of the corrupted file), you can consider the corruption to have been caused by cosmic rays, kernel bugs and a bad disk, all conspiring to ruin my day. What I'm really concerned about is, this effectively DoSed an important service. Are the benefits of persistence big enough to not zap out the old content when starting varnishd? I can even imagine a scheme that unlinks the underlying file, leaving existing varnishlog readers to finish flushing it to permanent storage (and switch to the new file once they're done). I absolutely expected a restart to fix something that has been described as a "shared RAM buffer", and was actually surprised to realize it has a persistent backing file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 08:25:58 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 08:25:58 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.e5c446197168c83c28d819b9e3d2e2a7@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding --------------------+------------------------------------------------------- Reporter: dugan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): Yeah, this entire HTTP/1.0 HTTP/1.1 thing is a mess. We have a parameter called client_http11 which already forces the return protocol, but that is sort of a hack The problem is that your backend returns HTTP/1.0 and we echo that to the client, need to find a sensible and clean way to handle the protocol versions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 08:26:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 08:26:06 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.7d11f0c2be5904a0625acf4023cc919e@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding ----------------------+----------------------------------------------------- Reporter: dugan | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 09:09:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 09:09:19 -0000 Subject: [Varnish] #640: varnishtest uses CLOCK_REALTIME instead of TIM_real In-Reply-To: <051.dab04b2fd5f54694875d7f3dba890797@projects.linpro.no> References: <051.dab04b2fd5f54694875d7f3dba890797@projects.linpro.no> Message-ID: <060.400820cf06cac061d3772824423a4698@projects.linpro.no> #640: varnishtest uses CLOCK_REALTIME instead of TIM_real --------------------+------------------------------------------------------- Reporter: dugan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4532]) Use TIM_real() or the benefit of OS/X. Fixes #640 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 10:29:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 10:29:50 -0000 Subject: [Varnish] #643: Varnish load balancer & (keep session) Message-ID: <055.ce527eed2d53a8f3be2b240699c6e26c@projects.linpro.no> #643: Varnish load balancer & (keep session) ----------------------------------+----------------------------------------- Reporter: Crossfire | Type: defect Status: new | Priority: normal Milestone: Later | Component: build Version: 2.0 | Severity: normal Keywords: Varnish load balance | ----------------------------------+----------------------------------------- Version: 2.0.6-1 Insall: .deb Os: Debian 5.0.3 I've got two backends running apache2: front1.domain.com & front2.domain.com, set with the load balancing configuration from [http ://varnish-cache.org/wiki/LoadBalancing]. The issue is, when I shutdown apache2 of the first backend varnish don't switch to the second and display "Error 503 Service Unavailable", is that a normal answer from varnish? Other question, does varnish load balancer keep php sessions, if yes how will I do? Varnishlog : {{{ 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008 0.039814 HTTP/1.1 200 OK 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948 0.066591 HTTP/1.1 200 OK }}} Missing S flag "4--X-S-RH" to notify that TCP socket shutdown succeeded from [http://varnish-cache.org/wiki/BackendPolling] Part of default.vcl {{{ backend front1 { .host = "front1.domain.com"; .port = "80"; .probe = { .url = "/"; .interval = 10s; .timeout = 5s; .window = 10; .threshold = 8; } } backend front2 { .host = "front2.domain.com"; .port = "80"; .probe = { .url = "/"; .interval = 10s; .timeout = 5s; .window = 10; .threshold = 8; } } director b1 random { { .backend = front1; .weight = 5; } { .backend = front2; .weight = 1; } } #director b1 round-robin { # { .backend = front1; } # { .backend = front2; } #} }}} Thanks for your help... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 4 16:24:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 04 Feb 2010 16:24:16 -0000 Subject: [Varnish] #643: Varnish load balancer & (keep session) In-Reply-To: <055.ce527eed2d53a8f3be2b240699c6e26c@projects.linpro.no> References: <055.ce527eed2d53a8f3be2b240699c6e26c@projects.linpro.no> Message-ID: <064.d0c44be5cfc32dfa1f4c2920c52ae412@projects.linpro.no> #643: Varnish load balancer & (keep session) ----------------------------------+----------------------------------------- Reporter: Crossfire | Owner: Type: defect | Status: closed Priority: normal | Milestone: Later Component: build | Version: 2.0 Severity: normal | Resolution: invalid Keywords: Varnish load balance | ----------------------------------+----------------------------------------- Changes (by kristian): * status: new => closed * resolution: => invalid Comment: This is not really a bug, but a general question. Those are better asked on one of the mailinglists (you get a far wider audience: Only a handful people watch the bug tracker while far more people read the mailinglists). I suggest you send your question to varnish-misc, and we'll probably figure it out. Though as far as the log goes, your server is returning http 200 OK, and all probes are good, and you have an interval of 10 seconds, timeout of 5 seconds and a threshold of 8 out of 10... With that setup it could take quite some times (45 seconds, if I'm not much mistaken) for Varnish to mark a backend as unhealthy. But re-post your question on the mailinglist and we can continue it there :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 5 19:22:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Feb 2010 19:22:03 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. Message-ID: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: deadlock ----------------------+----------------------------------------------------- Varnish will dead lock with all threads in queued status dropping all subsequent work requests when under very high load. Backtrace on all worker threads show blocked in write call to vca_pipes. vca_main thread backtrace shows it in epoll_wait. It is my understanding that epoll_wait in vca_main should return where there is a write to vca_pipes, however all writes are being blocked and no requests are being cleared from request queue. The child ping will eventually timeout and restart the child process. Here are the appropriate back traces: {{{ #0 0x00002ad7dd327d09 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000041afac in Lck_CondWait (cond=0x653000, lck=) at cache_lck.c:150 #2 0x000000000041cd49 in wrk_herder_thread (priv=) at cache_pool.c:624 #3 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #4 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 ------ #0 0x00002ad7dd32afe1 in nanosleep () from /lib64/libpthread.so.0 #1 0x00000032b08056a1 in TIM_sleep (t=) at time.c:161 #2 0x000000000041d54e in wrk_herdtimer_thread (priv=) at cache_pool.c:545 #3 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #4 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 ----- #0 0x00002ad7dda6e0b1 in nanosleep () from /lib64/libc.so.6 #1 0x00002ad7dda6ded4 in sleep () from /lib64/libc.so.6 #2 0x0000000000413e19 in exp_timer (sp=0x2aaaab302008, priv=) at cache_expire.c:294 #3 0x000000000041d829 in wrk_bgthread (arg=0x2ad7dd004120) at cache_pool.c:661 #4 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 ------ #0 0x00002ad7dd32afe1 in nanosleep () from /lib64/libpthread.so.0 #1 0x00000032b08056a1 in TIM_sleep (t=) at time.c:161 #2 0x000000000040a808 in vca_sess_timeout_ticker (arg=) at cache_acceptor_epoll.c:216 #3 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #4 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 ------ #0 0x00002ad7ddaa8018 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000040a1a8 in vca_main (arg=) at cache_acceptor_epoll.c:176 #2 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #3 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 ------ #0 0x00002ad7dda9ee46 in poll () from /lib64/libc.so.6 #1 0x0000000000409523 in vca_acct (arg=) at cache_acceptor.c:221 #2 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #3 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 --- ALL 4000 of the worker threads show: #0 0x00002ad7dd32a6bb in write () from /lib64/libpthread.so.0 #1 0x00000000004097a9 in vca_return_session (sp=0x2aacefff2008) at cache_acceptor.c:325 #2 0x0000000000411b97 in CNT_Session (sp=0x2aacefff2008) at cache_center.c:110 #3 0x000000000041d9e2 in wrk_do_cnt_sess (w=0x44441bd0, priv=) at cache_pool.c:398 #4 0x000000000041cf4f in wrk_thread (priv=0x2ad7dd00a0b0) at cache_pool.c:310 #5 0x00002ad7dd323617 in start_thread () from /lib64/libpthread.so.0 #6 0x00002ad7ddaa7c2d in clone () from /lib64/libc.so.6 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 5 19:29:09 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Feb 2010 19:29:09 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.fdebd91dc5e08e0ac0af3d9eb14261ee@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Comment (by phk): We have seen this reported before, and have at present no handle on it. I will not rule out a bug in Varnish, but given the symptoms, as described by you and others, a kernel bug starts to sound plausible. If you can (or happen to) reproduce it, it would be valuable information to know if the waiter thread is stuck in epoll_wait, not coming back at all, if it comes back on the timer, or if it busy-spins calling epoll_wait all the time, getting nothing done. If it is feasible with your system load, try running with the "poll" waiter, and see if that also suffers from the same problem (which would indicate kernel/pipe issue). Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 5 22:34:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Feb 2010 22:34:17 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.1c3e0472d7b87f22986051e1dda61647@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Comment (by kmcfate): This is easily reproducible. It looks like the pipe is overflowing. It is set to edge triggered. According to epoll docs, if it is using edge triggered, and data is written to pipe, but not all of it is read, another trigger will not happen until all data is read. Since the reader is only reading NEEV events per read, it leaves data in the pipe if there are more than NEEV# and never gets run again. I suggest either running this pipe in level triggering or loop in the reader to see if data remains in the pipe. Steps to reproduce: run the following on about 200 machines on same network: ab -c 1000 -n 100000 http://varnish/ Results: If new sessions between events exceeds NEEV, varnish cows because it never handles the extras and the epoll event never triggers again. Expected Results: Somewhat higher load. No cows. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 6 05:36:43 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 06 Feb 2010 05:36:43 -0000 Subject: [Varnish] #503: Assertion failure when trying to fetch a large object In-Reply-To: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> References: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> Message-ID: <060.c079d74d0e8b12da1d1279da00753cdf@projects.linpro.no> #503: Assertion failure when trying to fetch a large object --------------------+------------------------------------------------------- Reporter: Sesse | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | --------------------+------------------------------------------------------- Comment (by somsak): Could this at least be handled in more gentle way other than finding all large files and put it in (pipe) rules? The latter is not possible if you host a web-site which has so many user on it. You never know which path they are gonna put the file to. At the least, is it possible to have something like # This function will be called when HTTP header is fetched from peer, but not the whole content yet vcl_prefetch() { if obj.http.Content-Length > xxxx { return(pipe); } } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 6 15:15:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 06 Feb 2010 15:15:21 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.b64596d6770c2855406890acfde4349c@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Comment (by kmcfate): Feedback welcome for the patch I am using: diff -udN --recursive varnish-2.0.6/bin/varnishd/cache_acceptor_epoll.c varnish-2.0.6-mod/bin/varnishd/cache_acceptor_epoll.c --- varnish-2.0.6/bin/varnishd/cache_acceptor_epoll.c 2009-11-06 02:43:32.000000000 -0600 +++ varnish-2.0.6-mod/bin/varnishd/cache_acceptor_epoll.c 2010-02-06 09:13:32.658538000 -0600 @@ -64,9 +64,12 @@ { assert(fd >= 0); - if (data == vca_pipes || data == dotimer_pipe) { + if (data == dotimer_pipe) { struct epoll_event ev = { EPOLLIN | EPOLLPRI | EPOLLET, { data } }; AZ(epoll_ctl(epfd, arm, fd, &ev)); + } else if (data == vca_pipes) { + struct epoll_event ev = { EPOLLIN | EPOLLPRI , { data } }; + AZ(epoll_ctl(epfd, arm, fd, &ev)); } else { struct sess *sp = (struct sess *)data; CHECK_OBJ_NOTNULL(sp, SESS_MAGIC); -- Ticket URL: Varnish The Varnish HTTP Accelerator From nicholas at redpill-linpro.com Wed Feb 3 14:56:47 2010 From: nicholas at redpill-linpro.com (Nicholas Klem) Date: Wed, 03 Feb 2010 15:56:47 +0100 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <063.1b7f496d3ef4bda77be0d80b330df7a6@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> <063.1b7f496d3ef4bda77be0d80b330df7a6@projects.linpro.no> Message-ID: <4B698EAF.7090308@redpill-linpro.com> Varnish wrote: > #508: Varnish 2.0.4 started crashing more often under load. Assert error in > VRT_r_req_backend_healthy(). > ----------------------+----------------------------------------------------- > Reporter: nicholas | Owner: phk > Type: defect | Status: new > Priority: normal | Milestone: > Component: varnishd | Version: 2.0 > Severity: normal | Resolution: > Keywords: | > ----------------------+----------------------------------------------------- > Comment (by phk): > > Can you still reproduce this in -trunk ? > This was triggered by a very untraditional usage of req.backend.healthy in vcl - trying to get a http header stating wether object served was graced or not. Spotted and fixed by Kristian. I don't think there is any point pursuing this, close it. :-) Nicholas From j at ww.com Thu Feb 4 20:56:21 2010 From: j at ww.com (Jacques Mattheij) Date: Thu, 04 Feb 2010 21:56:21 +0100 Subject: [Varnish] #470: cryptic error message when drive is full In-Reply-To: <063.7268feebd39129021106c19dad295f75@projects.linpro.no> References: <054.da702999a39b226cda07dfa84b3c1c6d@projects.linpro.no> <063.7268feebd39129021106c19dad295f75@projects.linpro.no> Message-ID: <4B6B3475.2090402@ww.com> Ok, I'll download latest version and check. Thanks! Varnish wrote: > #470: cryptic error message when drive is full > -------------------------+-------------------------------------------------- > Reporter: jacquesm | Owner: kristian > Type: enhancement | Status: closed > Priority: normal | Milestone: > Component: build | Version: 2.0 > Severity: normal | Resolution: worksforme > Keywords: | > -------------------------+-------------------------------------------------- > Changes (by phk): > > * status: new => closed > * resolution: => worksforme > > Comment: > > I don't think that message is given anymore, at least I cannot reproduce > it. > > -- Jacques Mattheij +31 6 30 366 241 From varnish-bugs at projects.linpro.no Mon Feb 8 12:03:10 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Feb 2010 12:03:10 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.b89e8377c821311ae96bb7f3d8a1889b@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: phk => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 8 12:39:02 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Feb 2010 12:39:02 -0000 Subject: [Varnish] #477: Change defaults to respect Cache-Control: private In-Reply-To: <050.cb885dcd552a186f1314aa6843303453@projects.linpro.no> References: <050.cb885dcd552a186f1314aa6843303453@projects.linpro.no> Message-ID: <059.ee70655f32010bfc3fd55bbaa16ddce1@projects.linpro.no> #477: Change defaults to respect Cache-Control: private --------------------+------------------------------------------------------- Reporter: olau | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * owner: => sky Comment: Write up a VCL plan for solving this -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 8 14:20:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Feb 2010 14:20:52 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> Message-ID: <063.fb2cae13d098513c6fb39762203200e7@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed according to mail on -bugs; closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 09:18:09 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 09:18:09 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.0004d96b9430328803a9a506aca6dc9c@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding ----------------------+----------------------------------------------------- Reporter: dugan | 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: I have re-read the relevant RFCs and changed Varnish so that the outgoing (either direction) is always HTTP/1.1, but the replies to the client are HTTP/1.0 compliant, if that's what the client sent us. That should fix this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 09:22:18 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 09:22:18 -0000 Subject: [Varnish] #642: log buffer (VSL) can get corrupted In-Reply-To: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> References: <048.fd9ff26663c2867cdbcdfd51e31d9755@projects.linpro.no> Message-ID: <057.7a88f5e9c8aaa25691e9683617a3d239@projects.linpro.no> #642: log buffer (VSL) can get corrupted ------------------------+--------------------------------------------------- Reporter: Tv | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: The main cause of shmlog trashing we have seen, have been multiple worker- processes running at the same time. Last week I added a pid-check, so that the shmlog is blown away, pretty much like you suggest, if we perceive a risk that there is a running worker process writing to it still. I won't rule out other causes of shmlog corruption, but in general our policy is to not paper over problems, for instance by needlessly blowing the vsl file away, we much prefer to find the cause and fix it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 10:35:34 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 10:35:34 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.a757b332fe1e14a0bb695126980d3821@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4543]) Make sure we always close backend socket if the backend sends "Connection: close" or if a HTTP/1.0 backend does not send "Connection: keep-alive". Fixes #495 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 10:45:28 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 10:45:28 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.89288c45ac84ab5f57e15307f9e3152f@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I belive this is solved now. kb: Why don't you think TCP_connect() is reentrant ? Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 10:56:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 10:56:38 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.a875145bedb74a90501cf619474a1e73@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Can I get you to test -trunk at revision r4545 or later ? I think the logic added to fix the issue from ticket #495 should help you here also. Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 11:20:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 11:20:05 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.035ec53ee775a82eb97ba55d600307e7@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by janne): Great. I'll give it a try at some point pretty soon. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 13:36:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 13:36:21 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.9aef05aede4e52c64c49db1be564b003@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding ----------------------+----------------------------------------------------- Reporter: dugan | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by dugan): Are you sure? Here is the situation one more time: Client requests 1.1 Backend responds with 1.0 Problem: Varnish returns http 1.0 response to client with transfer- encoding set, but transfer-encoding is not part of 1.0 spec. Firefox thus ignores the transfer encoding and displays the chunking data. Proposed solution: 1) Varnish should return 1.1 if the client requested 1.1, even if the server is 1.0. 2) Varnish should avoid using chunked transfer-encoding if the client requests 1.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 13:52:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 13:52:41 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.c312c0c2b7260e59b14ecc3d89ef0b7f@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding ----------------------+----------------------------------------------------- Reporter: dugan | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Yes, I am pretty sure I fixed that. For all but pipe, Varnish now sends HTTP/1.1 in both directions. Please test -trunk r4550 or later, and report if you can still reproduce. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 13:57:36 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 13:57:36 -0000 Subject: [Varnish] #641: client requests http/1.1, backend is http/1.0 conflicts with transfer-encoding In-Reply-To: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> References: <051.7f8e5dd736462f2c2aee5da0f73363a4@projects.linpro.no> Message-ID: <060.d493c6b93241f594d116ae4b4a817492@projects.linpro.no> #641: client requests http/1.1, backend is http/1.0 conflicts with transfer- encoding ----------------------+----------------------------------------------------- Reporter: dugan | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by dugan): Ah, yes, thanks, I understand now. I will test. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 10 21:05:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Feb 2010 21:05:19 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.5dda801b15812d0b9006582901d6b56a@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by kb): errno isn't always thread-safe, and there's some logic based on it. This may no longer be an issue with current Linux/FreeBSD/*Solaris, and is probably more of a red herring than helpful. :-/ Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 11 07:53:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Feb 2010 07:53:17 -0000 Subject: [Varnish] #645: [PATCH] Log hits only with varnishncsa Message-ID: <055.8fdde5e0eb59f9e476abeac372c2b7bf@projects.linpro.no> #645: [PATCH] Log hits only with varnishncsa -----------------------+---------------------------------------------------- Reporter: bmizerany | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: | -----------------------+---------------------------------------------------- I've added the ability log only cache hits with varnishncsa. varnishncsa -H This is a very useful feature when debugging and even for production logging, of which I use both. I would love to see this be part of stock varnish. I'm very open to ideas on how to be a little more general about this. Maybe getting -i to work; I was unable too. varnishncsa -i Hit Thoughts? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 11 07:54:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Feb 2010 07:54:59 -0000 Subject: [Varnish] #646: [PATCH] Log hits only with varnishncsa Message-ID: <055.e0ea5852d2d03adcd20f802e80bd7ef6@projects.linpro.no> #646: [PATCH] Log hits only with varnishncsa -----------------------+---------------------------------------------------- Reporter: bmizerany | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: | -----------------------+---------------------------------------------------- I've added the ability log only cache hits with varnishncsa. varnishncsa -H This is a very useful feature when debugging and even for production logging, of which I use both. I would love to see this be part of stock varnish. I'm very open to ideas on how to be a little more general about this. Maybe getting -i to work; I was unable too. varnishncsa -i Hit Thoughts? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 11 11:57:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Feb 2010 11:57:37 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.c39f555f7bacd4741fae1a2cd6af184c@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Comment (by kristian): Ok, EPOLLET is not ideal here. Epoll with ET will wake up even if you do not empty the buffer, but it will only wake up if something changes. The problem seems to be that the pipe buffer fills up, which means that write() on the worker threads turns into a blocking call. If more than NEEV clients end up in this situation, varnish will deadlock: It will wake up 100 threads, but all of those threads will in turn block when they are done, which WONT wake up epoll because nothing actually changed on the fd. Having discussed this a bit and run some tests, I don't see any real reason why we want to use edge triggered mode at all: there are no situations where we don't want to read the data waiting on the fd right away. However, letting epoll wake up potential other threads while we re- enter threads into the thread pool sounds like a good idea. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 11 11:58:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Feb 2010 11:58:03 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.7fa7d876cd15a47e3968d94ea7702d40@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: deadlock | ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => fixed Comment: (In [4552]) Don't use edge-triggered mode in epoll Fixes #644 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 12 21:31:18 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Feb 2010 21:31:18 -0000 Subject: [Varnish] #645: [PATCH] Log hits only with varnishncsa In-Reply-To: <055.8fdde5e0eb59f9e476abeac372c2b7bf@projects.linpro.no> References: <055.8fdde5e0eb59f9e476abeac372c2b7bf@projects.linpro.no> Message-ID: <064.c1c5724ee8f7287a0c8f9feb2bdd7b7f@projects.linpro.no> #645: [PATCH] Log hits only with varnishncsa -------------------------+-------------------------------------------------- Reporter: bmizerany | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by bmizerany): Sorry. this was a dup of #646. Please delete/mark as a so. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 13 03:52:48 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 13 Feb 2010 03:52:48 -0000 Subject: [Varnish] #356: v00017.vtc fails on x86_64 In-Reply-To: <051.f99bddfcf0e83b27a73b71e0bb8abdaf@projects.linpro.no> References: <051.f99bddfcf0e83b27a73b71e0bb8abdaf@projects.linpro.no> Message-ID: <060.f2476982dc6c87858430a65e8bd53e2c@projects.linpro.no> #356: v00017.vtc fails on x86_64 -------------------------------+-------------------------------------------- Reporter: wiebe | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: v00017.vtc x86_64 | -------------------------------+-------------------------------------------- Changes (by turb0kat): * status: closed => reopened * resolution: fixed => Comment: I'm seeing that on version 2.02 2.03 2.05 2.06 Looks like it successfully parses some VCL but the test expects it to fail. > uname -a Linux stuntman.wikinvest.com 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 19:32:05 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux # top TEST tests/v00017.vtc starting # TEST VCL compiler coverage test: vcc_acl.c ## v1 Launch ### v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/__v1 -a '127.0.0.1:9081' -T 127.0.0.1:9001 -P /tmp/__v1/varnishd.pid ### v1 opening CLI connection #### v1 debug| storage_file: filename: ./varnish.698oFV (unlinked) size 5347 MB.\n #### v1 debug| Creating new SHMFILE\n #### v1 debug| Notice: locking SHMFILE in core failed: Cannot allocate memory\n #### v1 debug| Debugging mode, enter "start" to start child\n ### v1 CLI connection fd = 3 #### v1 CLI TX| vcl.inline vcl1 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.3\"/33; }\n\tsub vcl_recv { if (client.ip ~ a) { pass; } }\n" #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Too wide mask (33) for IPv4 address(input Line 3 Pos 28)\n #### v1 CLI RX| acl a { "10.1.2.3"/33; }\n #### v1 CLI RX| ---------------------------##---\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl2 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"1::2\"/129; }\n\tsub vcl_recv { if (client.ip ~ a) { pass; } }\n" #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Too wide mask (129) for IPv6 address(input Line 3 Pos 24)\n #### v1 CLI RX| acl a { "1::2"/129; }\n #### v1 CLI RX| -----------------------###---\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl3 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\"/31;\n\t\t\"1.2.3.4\"/31;\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { pass; } }\n" #### v1 CLI RX| VCL compiled. ### v1 CLI STATUS 200 #### v1 CLI TX| vcl.use vcl3 ### v1 CLI STATUS 200 #### v1 CLI TX| vcl.inline vcl4 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a {\n\t\t\"1.2.3.4\";\n\t\t!\"1.2.3.4\";\n\t}\n\tsub vcl_recv { if (client.ip ~ a) { pass; } }\n" #### v1 CLI RX| Message from VCC-compiler:\n #### v1 CLI RX| Conflicting ACL entries:\n #### v1 CLI RX| (input Line 4 Pos 17)\n #### v1 CLI RX| "1.2.3.4";\n #### v1 CLI RX| ----------------#########-\n #### v1 CLI RX| vs:\n #### v1 CLI RX| (input Line 5 Pos 18)\n #### v1 CLI RX| !"1.2.3.4";\n #### v1 CLI RX| -----------------#########-\n #### v1 CLI RX| Running VCC-compiler failed, exit 1\n #### v1 CLI RX| VCL compilation failed ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) #### v1 CLI TX| vcl.inline vcl5 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"en.lille.nisse.rejste.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { pass; } }\n" #### v1 CLI RX| VCL compiled. ### v1 CLI STATUS 200 ---- v1 VCL compilation got 200 expected 106 ---- TEST FILE: tests/v00017.vtc ---- TEST DESCRIPTION: VCL compiler coverage test: vcc_acl.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 13 08:31:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 13 Feb 2010 08:31:05 -0000 Subject: [Varnish] #356: v00017.vtc fails on x86_64 In-Reply-To: <051.f99bddfcf0e83b27a73b71e0bb8abdaf@projects.linpro.no> References: <051.f99bddfcf0e83b27a73b71e0bb8abdaf@projects.linpro.no> Message-ID: <060.f2d770ed0d01181075bd71486c553d57@projects.linpro.no> #356: v00017.vtc fails on x86_64 -------------------------------+-------------------------------------------- Reporter: wiebe | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: v00017.vtc x86_64 | -------------------------------+-------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: (In [4559]) Change from a non-resolving to an illegal DNS name, to avoid spurious test-failures if peoples DNS servers lie to them. Fixes #356 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 09:26:47 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 09:26:47 -0000 Subject: [Varnish] #647: ESI and mod_deflate don't work together Message-ID: <051.0ef47d494c0215b39f0682170a19aff9@projects.linpro.no> #647: ESI and mod_deflate don't work together -------------------+-------------------------------------------------------- Reporter: iamer | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I know about #594 and I see http://varnish-cache.org/wiki/FAQ/Compression and I am at a loss at what am I supposed to do. It is good practice to gzip the objects before sending them to the client's browser, but then ESI won't work. If we don't use mod_deflate so we can take advantage of ESI, then we lose some of the response time advantage gained by using varnish in the first place. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 12:05:29 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 12:05:29 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.e85055705e9b4544bb6cd835ee95a82e@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Victor, this issue does not seem to be caused by the acceptor. See discussion "Child panics on OpenSolaris" on varnish-misc -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 13:31:08 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 13:31:08 -0000 Subject: [Varnish] #645: [PATCH] Log hits only with varnishncsa In-Reply-To: <055.8fdde5e0eb59f9e476abeac372c2b7bf@projects.linpro.no> References: <055.8fdde5e0eb59f9e476abeac372c2b7bf@projects.linpro.no> Message-ID: <064.36438edcc19f2510516771fa86b6c0dc@projects.linpro.no> #645: [PATCH] Log hits only with varnishncsa -------------------------+-------------------------------------------------- Reporter: bmizerany | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: duplicate Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: Dup of 646 (which has the patch attached) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 13:47:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 13:47:24 -0000 Subject: [Varnish] #647: ESI and mod_deflate don't work together In-Reply-To: <051.0ef47d494c0215b39f0682170a19aff9@projects.linpro.no> References: <051.0ef47d494c0215b39f0682170a19aff9@projects.linpro.no> Message-ID: <060.d646ff02c55576e283b3fcba911e4c9a@projects.linpro.no> #647: ESI and mod_deflate don't work together --------------------+------------------------------------------------------- Reporter: iamer | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => invalid Comment: Yes, we want to support outbound compression. No, we don't support it right now. We keep most feature enhancements in http://varnish- cache.org/wiki/PostTwoShoppingList and gzip-support is on the list, and a high priority. Basically: we're on it, but we don't use the bug tracker to track feature requests. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 14:58:54 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 14:58:54 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.9e11a9c1e5590624fb3298362744c347@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: kristian Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Changes (by kristian): * status: closed => reopened * resolution: fixed => Comment: Reopening this based on reports that this switches the deadlock into a spin. While better, obviously not optimal. This probably means there's some data "stuck" in a pipe that we're not picking up. This would also explain why the buffer space fills up. I've got a core dump to investigate and will follow it up. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 15 16:07:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Feb 2010 16:07:00 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> References: <053.77c789095146ba5f2d367e6e9973fa86@projects.linpro.no> Message-ID: <062.79e266f07c82fe79b41c29c36b962d44@projects.linpro.no> #644: Deadlock in 2.0.x under high load. ----------------------+----------------------------------------------------- Reporter: kmcfate | Owner: kristian Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: deadlock | ----------------------+----------------------------------------------------- Comment (by kmcfate): After testing, I agree this is a suboptimal patch. It no longer deadlocks, but load jumps greatly under high load and actual thread processing starts flapping between pipe drains. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 16 21:00:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Feb 2010 21:00:19 -0000 Subject: [Varnish] #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> References: <059.86cbd22e616d124a82dcd8aabaf578aa@projects.linpro.no> Message-ID: <068.8852aeccbe21029f13f8ff135041e55b@projects.linpro.no> #588: Varnish crashes every other second with Assert error in VCA_Prep(), cache_acceptor.c line 148 ---------------------------+------------------------------------------------ Reporter: erik.berglund | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: See #626 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 16 21:00:48 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Feb 2010 21:00:48 -0000 Subject: [Varnish] #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 In-Reply-To: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> References: <053.088595cdaa95b65d1dc7d5db8ed60eaa@projects.linpro.no> Message-ID: <062.6033c0ffc9795f23ddc34a1b75a4a13c@projects.linpro.no> #615: Varnish crashes every few minutes with Assert error in VCA_Prep(), cache_acceptor.c line 148 ----------------------+----------------------------------------------------- Reporter: jhayter | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: see #626 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 16 21:01:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Feb 2010 21:01:57 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c In-Reply-To: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> References: <053.d1ac0ffa95c861330f302ab89c8faa7f@projects.linpro.no> Message-ID: <062.893697481cc938061c662d2dbe4a177d@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * owner: => tfheen Comment: This is a build issue. On Solaris, the native C-compiler needs a -mt argument, or the errno variable will not be made per-thread. Apperantly our present autocrap stuff does not know this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 09:58:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 09:58:38 -0000 Subject: [Varnish] #522: Odd TCP reset problems with trunk 4080 In-Reply-To: <052.9e4f22a7767a39fc57cd165effa2904d@projects.linpro.no> References: <052.9e4f22a7767a39fc57cd165effa2904d@projects.linpro.no> Message-ID: <061.dfc1f50e798125c79497ce4630e72f31@projects.linpro.no> #522: Odd TCP reset problems with trunk 4080 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Time out this ticket, issue belived fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 09:59:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 09:59:27 -0000 Subject: [Varnish] #548: Sig 11 crash in trunk 4199 In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> Message-ID: <061.26bcd2c0414376179e6949f35fcee10d@projects.linpro.no> #548: Sig 11 crash in trunk 4199 ---------------------------------------------+------------------------------ Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: sig 11 segmentation fault trunk | ---------------------------------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: Close this ticket, this race is now fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 10:00:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 10:00:17 -0000 Subject: [Varnish] #636: Varnish crash in trunk 4492 In-Reply-To: <052.b3b04170667d1339a9de111bd59e3095@projects.linpro.no> References: <052.b3b04170667d1339a9de111bd59e3095@projects.linpro.no> Message-ID: <061.76feb34b9efcfacb56abbda237f3414a@projects.linpro.no> #636: Varnish crash in trunk 4492 ----------------------+----------------------------------------------------- Reporter: anders | 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: This race is belived to have been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 10:13:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 10:13:32 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.2386390ef311faf7fd55fb031011b705@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by slink): Hi Victor, could you please check your compiler/linker flags, see these posts: * http://projects.linpro.no/pipermail/varnish- misc/2010-February/003888.html * http://projects.linpro.no/pipermail/varnish- misc/2010-February/003889.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 11:34:11 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 11:34:11 -0000 Subject: [Varnish] #630: helpers to convert varnish time into struct timespec/timeval In-Reply-To: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> References: <051.2fd8e6a69b995e5e619ae7dc76996353@projects.linpro.no> Message-ID: <060.28058522528f52afca57eb50d2a44d56@projects.linpro.no> #630: helpers to convert varnish time into struct timespec/timeval -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Comment (by slink): Oh, sure you can do this in two lines of code wherever you need it. I just thought it would be a good idea to have helper functions and an appropriate test in order not to introduce conversion errors. But you're absolutely right that using modf was over the top. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 18:06:23 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 18:06:23 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.1b4900b9dd3a61df297a371b61ff8a6f@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Ya I looked into it yesterday. It still happens. I have documented it on my varnish blog post. http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ setsocketopt still fails on setting SO_LINGER in cache_acceptor.c every once in a while. I went even as far as making sure -pthreads does define _REENTRANT {{{ gcc -x c /dev/null -E -dM -pthreads | grep REENT #define _REENTRANT 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 19:12:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 19:12:16 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> References: <051.ec718367898a73a9b48ac138ee40e6ab@projects.linpro.no> Message-ID: <060.0ad7cca3628f0093c591addb8e1934c3@projects.linpro.no> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Oh yes, I forgot to mention the kicker. Yesterday, I deployed varnish that was compiled with the Sun Express Studio March 2009 release. Varnish that is compiled under suncc times out cache-misses randomly. There are no varnish failed backend attempts in the logs. I don't see this problem when varnish is compiled with GCC 4.3.2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 21:17:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 21:17:03 -0000 Subject: [Varnish] #648: http read error: 11 Message-ID: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> #648: http read error: 11 ----------------------+----------------------------------------------------- Reporter: benliles | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- I'm receiving an "http read error: 11" in my varnish log which corresponds to a blank page and a 503 response sent to the end user. I have a vcl_error block set up to make the 503's look nice but this error bypasses that process. Varnish 2.0.6 64bit architecture Virtual Machine (vmWare) 8GB RAM OS: Ubuntu 8.04 kernel 2.6.24-26-server x86_64 Backend: Plone 3.3.2 VCL attached with fragment of pertinent log. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 21:33:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 21:33:59 -0000 Subject: [Varnish] #648: http read error: 11 In-Reply-To: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> References: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> Message-ID: <063.8746091ade43aeed4a51717a533d82a4@projects.linpro.no> #648: http read error: 11 ----------------------+----------------------------------------------------- Reporter: benliles | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by benliles): This error does not occur when I run varnish on my Mac (10.6) using the same backend servers. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 22:37:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 22:37:37 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris Message-ID: <053.b0139b74db2ce618b696d95ff8f33149@projects.linpro.no> #649: Varnish LINGER crash on Solaris ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ OpenSolaris, SNV98; newest trunk r4576. {{{ + newtask -p highfile /opt/extra/sbin/varnishd -f /opt/extra/etc/varnish/default.vcl -a 0.0.0.0:80 -p listen_depth=8192 -p thread_pool_max=2000 -p thread_pool_min=50 -p thread_pools=4 -p cc_command='cc -Kpic -G -m64 -o %o %s' -s file,/sessions/varnish_cache.bin,512M -p sess_timeout=10s -p session_linger=120ms -p connect_timeout=0s -p lru_interval=20s -p thread_pool_add_delay=2ms -p waiter=poll -p cli_timeout=25s -p sess_workspace=65536 -T 0.0.0.0:8086 -u webservd -F storage_file: filename: /sessions/varnish_cache.bin size 512 MB. Message from C-compiler: "./vcl.JV7ixSxI.c", line 355: warning: initializer will be sign-extended: -1 Using old SHMFILE child (26102) Started Child (26102) said Closed fds: 3 5 6 9 10 12 13 Child (26102) said Child starts Child (26102) said managed to mmap 536870912 bytes of 536870912 Child (26102) not responding to ping, killing it. Child (26102) died signal=6 Child (26102) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 185: Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger))) not true. errno = 22 (Invalid argument) thread = (cache-worker) ident = -sfile,-hcritbit,poll Backtrace: 430f23: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f23] f: [0xf] sp = 968018 { fd = 15, id = 15, xid = 0, client = 67.170.196.64:52894, step = STP_FIRST, handling = deliver, restarts = 0, esis = 0 ws = 968088 { id = "sess", {s,f,r,e} = {968d90,+20,0,+65536}, }, http[req] = { ws = 968088[sess] "4", "/question/id/2241", "HTTP/1.1", "Host: fabulously40.com", "Connection: Keep-Alive", "Accept: */*", "Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01", "If-Modified-Since: Sat, 13 Feb 2010 19:13:17 GMT", "User-Agent: Yandex/1.01.001 (compatible; Win16; I)", "From: webadmin at yandex.ru", "X-Forwarded-For: 77.88.25.28", "Accept-Encoding: gzip", }, worker = fffffd7fd302ed10 { ws = fffffd7fd302ee58 { id = "wrk", {s,f,r,e} = {fffffd7fd301cc90,fffffd7fd301cc90,0,+65536}, }, }, }, Child cleanup complete child (27102) Started Child (27102) said Closed fds: 3 5 6 9 10 12 13 Child (27102) said Child starts Child (27102) said managed to mmap 536870912 bytes of 536870912 Child (27102) died signal=6 Child (27102) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 185: Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger))) not true. errno = 22 (Invalid argument) thread = (cache-worker) ident = -sfile,-hcritbit,poll Backtrace: 430f23: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f23] 18: [0x18] sp = 6eb018 { fd = 24, id = 24, xid = 0, client = 67.170.196.64:52889, step = STP_FIRST, handling = deliver, restarts = 0, esis = 0 ws = 6eb088 { id = "sess", {s,f,r,e} = {6ebd90,+20,0,+65536}, }, http[req] = { ws = 0[] }, worker = fffffd7fcc662d10 { ws = fffffd7fcc662e58 { id = "wrk", {s,f,r,e} = {fffffd7fcc650c90,fffffd7fcc650c90,0,+65536}, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Feb 17 22:46:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Feb 2010 22:46:57 -0000 Subject: [Varnish] #648: http read error: 11 In-Reply-To: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> References: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> Message-ID: <063.c8599108fb4ffcdaac28b2f9cd9aff02@projects.linpro.no> #648: http read error: 11 ----------------------+----------------------------------------------------- Reporter: benliles | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by benliles): This error appears to be occurring on any page that takes more than 20 seconds to render. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 18 19:17:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Feb 2010 19:17:21 -0000 Subject: [Varnish] #485: Virtualhost logging for varnishncsa In-Reply-To: <052.ad49d79f82c60083d4971a3f23a8564c@projects.linpro.no> References: <052.ad49d79f82c60083d4971a3f23a8564c@projects.linpro.no> Message-ID: <061.2b76d5bd39b3a34bf6092adb58918f97@projects.linpro.no> #485: Virtualhost logging for varnishncsa ---------------------------------------------------------+------------------ Reporter: rhalff | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: Keywords: varnishncsa, virtual hosts, apache, logging | ---------------------------------------------------------+------------------ Comment (by omero): I've posted an updated version of the patch. rhalff first version was nice, but just ADDED the vhost in front of the usual NCSA/vhost lighttpd format. Instead I wanted varnishncsa to produce EXACTLY the same format as standard lighttpd.access.log, so I hacked it a bit. Awstats configuration for this log format (which is the same as lighttpd default) LogFormat = "%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot") Enjoy, perfectly working on my FreeBSD box. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 18 19:50:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Feb 2010 19:50:53 -0000 Subject: [Varnish] #650: Varnish probes and nginx + FastCGI don't get on together. Message-ID: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- It seems to be well known (but somewhat obscure - took some effort to convince out of google) that varnish health checks don't play well with nginx when it is proxying content or serving FastCGI: E.g. http://www.docunext.com/wiki/Varnish#Working_VCL_Failover_Example http://sys-notes.com/bin/view/Main/NginxProblems This is as varnish closes the request socket before nginx starts sending a response, ergo nginx returns a 499 error code. I could use the workaround given in the first example, however this makes the varnish health checking useless to me - as the fact that nginx is up means nothing to me without the FCGI application it is serving being available. If it is felt that this behavior is incorrect on the part of nginx, then this should be documented to stop people falling into this trap. Otherwise, the connection varnish makes should be kept open until data is being recieved from the backend (polled) web server, or the timeout is reached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 18 22:21:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Feb 2010 22:21:37 -0000 Subject: [Varnish] #651: Can't run varnishd on OpenSolaris Message-ID: <050.100fd3c16a87c69b3e2ec86edc1f9d1b@projects.linpro.no> #651: Can't run varnishd on OpenSolaris -------------------+-------------------------------------------------------- Reporter: asyd | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Issue: Message from C-compiler: Undefined first referenced symbol in file main /usr/lib/crt1.o VRT_r_obj_status /var/tmp//ccvFaqqt.o VRT_re_match /var/tmp//ccvFaqqt.o VRT_r_req_request /var/tmp//ccvFaqqt.o VRT_int_string /var/tmp//ccvFaqqt.o VRT_init_dir /var/tmp//ccvFaqqt.o VRT_r_server_ip /var/tmp//ccvFaqqt.o VRT_r_req_url /var/tmp//ccvFaqqt.o Got the same error with gcc 3.4.3, in 32/64 bits, and SunStudio 12.1 64 bits (not exactly the same output, but same origin) Version: Last Changed Rev: 4578 Last Changed Date: 2010-02-18 12:48:32 +0100 (Thu, 18 Feb 2010) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Feb 18 22:26:51 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Feb 2010 22:26:51 -0000 Subject: [Varnish] #651: Can't run varnishd on OpenSolaris In-Reply-To: <050.100fd3c16a87c69b3e2ec86edc1f9d1b@projects.linpro.no> References: <050.100fd3c16a87c69b3e2ec86edc1f9d1b@projects.linpro.no> Message-ID: <059.087edf66f03c443cb84a92b7d51d6fa4@projects.linpro.no> #651: Can't run varnishd on OpenSolaris --------------------+------------------------------------------------------- Reporter: asyd | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by victori): http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ This should help you get it working on opensolaris. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 19 17:51:43 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Feb 2010 17:51:43 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris In-Reply-To: <053.b0139b74db2ce618b696d95ff8f33149@projects.linpro.no> References: <053.b0139b74db2ce618b696d95ff8f33149@projects.linpro.no> Message-ID: <062.2e7a430535ee9c6a1955ef4bfb69898d@projects.linpro.no> #649: Varnish LINGER crash on Solaris ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by wrighty): I've also hit this bug today, on r4573, OpenSolaris snv_111b i86pc i386 i86pc: {{{ Child (26791) died signal=6 Child (26791) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 184: Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger))) not true. errno = 22 (Invalid argument) thread = (cache-worker) ident = -smalloc,-hcritbit,poll Backtrace: 447b2b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b2b] 447e35: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e35] 41862a: /opt/sbin/varnishd'VCA_Prep+0x29a [0x41862a] 42a466: /opt/sbin/varnishd'cnt_first+0xb6 [0x42a466] 42cd6a: /opt/sbin/varnishd'CNT_Session+0x56a [0x42cd6a] 44a83f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a83f] 449db2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449db2] 44a365: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a365] fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5] fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0] sp = 10e8ae08 { fd = 73, id = 73, xid = 0, client = 94.196.213.123:50084, step = STP_FIRST, handling = deliver, restarts = 0, esis = 0 ws = 10e8ae78 { id = "sess", {s,f,r,e} = {10e8c400,+21,0,+65536}, }, http[req] = { ws = 10e8ae78[sess] "", "/pic/p2031b.jpg", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)", "Accept: image/png,image/*;q=0.8,*/*;q=0.5", "Accept-Language: en-us,en;q=0.5", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Connection: keep-alive", "Referer: http://www.affordablegiftsolutions.com/index.php?option=com_cmsshopbuilder&view=category&id=55&Itemid=5&limitstart=400", "host: media.firebox.com", "X-Forwarded-For: 67.234.17.245", }, worker = fffffd7ff2c96d30 { ws = fffffd7ff2c96e78 { id = "wrk", {s,f,r,e} = {fffffd7ff2c84c40,fffffd7ff2c84c40,0,+65536}, }, }, }, }}} {{{ Child (8098) died signal=6 Child (8098) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 184: Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger))) not true. errno = 22 (Invalid argument) thread = (cache-worker) ident = -smalloc,-hcritbit,poll Backtrace: 447b1b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b1b] 447e25: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e25] 41862a: /opt/sbin/varnishd'VCA_Prep+0x29a [0x41862a] 42a456: /opt/sbin/varnishd'cnt_first+0xb6 [0x42a456] 42cd5a: /opt/sbin/varnishd'CNT_Session+0x56a [0x42cd5a] 44a82f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a82f] 449da2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449da2] 44a355: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a355] fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5] fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0] sp = ee89a8 { fd = 17, id = 17, xid = 0, client = 217.111.162.2:58987, step = STP_FIRST, handling = deliver, restarts = 0, esis = 0 ws = ee8a18 { id = "sess", {s,f,r,e} = {ee9fa0,+20,0,+65536}, }, http[req] = { ws = ee8a18[sess] "", "/v/2000/2381/98x74.jpg", "HTTP/1.1", "Accept: */*", "Referer: http://www.firebox.com/product/2480/LEGO-Mindstorms- NXT-2.0?via=cat", "Accept-Language: en-gb", "UA-CPU: x86", "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2)", "Host: media.firebox.com", "Cache-Control: max-stale=0", "Connection: Keep-Alive", "X-BlueCoat-Via: A1EDA8423E101D0C", "X-Forwarded-For: 89.189.78.18, 82.114.160.35", }, worker = fffffd7ff83edd30 { ws = fffffd7ff83ede78 { id = "wrk", {s,f,r,e} = {fffffd7ff83dbc40,fffffd7ff83dbc40,0,+65536}, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 19 20:45:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Feb 2010 20:45:49 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris In-Reply-To: <053.b0139b74db2ce618b696d95ff8f33149@projects.linpro.no> References: <053.b0139b74db2ce618b696d95ff8f33149@projects.linpro.no> Message-ID: <062.75e95c19bd2ec9a5265f5b580d82776e@projects.linpro.no> #649: Varnish LINGER crash on Solaris ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by victori): {{{ if (need_linger) setsockopt(sp->fd, SOL_SOCKET, SO_LINGER, &linger, sizeof linger); }}} cache_acceptor.c in bin/varnishd/* Remove TCP_assert line, and it won't fail. I have not noticed any negative side effects. -- Ticket URL: Varnish The Varnish HTTP Accelerator From a3104 at accelia.net Wed Feb 17 13:15:26 2010 From: a3104 at accelia.net (Satoshi Abe) Date: Wed, 17 Feb 2010 22:15:26 +0900 Subject: BUG found Message-ID: <69e4c7971002170515q401a8e23g2228dfabfa1bb88d@mail.gmail.com> Dear varnish developpers. I found the bug. I use ESI function by HTTP 1.0. I send http-request with "Connection: keep-alive" header. When the content length is not understood, it is necessary to close the connection in HTTP/1.0 or less. However, varnish returned "Connection: keep-alive", and keep the connection. Then, HTTP-Client is waited for until the time-out because the end of contents is not understood. I hope to add the following codes to correct this bug. cache_response.c line 144 // Http 1.0 should be connection close. by a3104 if (sp->http->protover <= 1.0){ sp->doclose = "Connection: close"; } ------ /* Only HTTP 1.1 can do Chunked encoding */ if (!sp->disable_esi && !VTAILQ_EMPTY(&sp->obj->esibits)) { http_Unset(sp->http, H_Content_Length); if(sp->http->protover >= 1.1) http_PrintfHeader(sp->wrk, sp->fd, sp->http, "Transfer-Encoding: chunked"); // Http 1.0 should be disconnect http session. by a3104 if (sp->http->protover == 1.0){ sp->doclose = "Connection: close"; } } ------------ Thanks and regards. From varnish-bugs at projects.linpro.no Mon Feb 22 12:10:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Feb 2010 12:10:41 -0000 Subject: [Varnish] #650: Varnish probes and nginx + FastCGI don't get on together. In-Reply-To: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> References: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> Message-ID: <058.c7845724a297adffd58f2e08855303cc@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Which varnish version is this ? I was under the impression this was fixed in -trunk ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 22 12:16:33 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Feb 2010 12:16:33 -0000 Subject: [Varnish] #648: http read error: 11 In-Reply-To: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> References: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> Message-ID: <063.dfa6164051190138b031e52656652fb1@projects.linpro.no> #648: http read error: 11 ----------------------+----------------------------------------------------- Reporter: benliles | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: First off, check your timeout parameters if you have pages that take 20 seconds to render, you will need to increase some of them. Second, as far as I can see from your varnishlog, it does indeed go to vcl-error, which returns a "restart". It doesn't look like there are any bugs to me... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 22 14:08:20 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Feb 2010 14:08:20 -0000 Subject: [Varnish] #651: Can't run varnishd on OpenSolaris In-Reply-To: <050.100fd3c16a87c69b3e2ec86edc1f9d1b@projects.linpro.no> References: <050.100fd3c16a87c69b3e2ec86edc1f9d1b@projects.linpro.no> Message-ID: <059.e750f292e3035606480837baca3cde2e@projects.linpro.no> #651: Can't run varnishd on OpenSolaris --------------------+------------------------------------------------------- Reporter: asyd | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by asyd): in r4582, I tried with: VCC_CC="cc -Kpic-G -m64 -o %o %s" CC=cc CFLAGS="-xO3 -fast -xipo -L/opt/webcache/varnish-trunk-cc-64/lib -mt -m64" LDFLAGS="-lumem -mt" ./configure --prefix=/opt/webcache/varnish-trunk-cc-64 --sysconfdir=/opt/webcache/etc however, varnishd failed to start: % sudo truss -f -o /tmp/pwet /opt/webcache/varnish/sbin/varnishd -a :80 -T localhost:6081 -f /opt/webcache/etc/varnish/webapps.vlc -s file,/opt/webcache/data/cache,10G -p cc_command="/opt/sunstudio12.1/bin/cc -Kpic -G -m64 -L/opt/webcache/varnish/var/varnish/australis -o %o %s" storage_file: filename: /opt/webcache/data/cache size 10240 MB. Message from C-compiler: "./vcl.ORk8t3RP.c", line 355: warning: initializer will be sign-extended: -1 Creating new SHMFILE In logs: Feb 22 14:03:50 australis varnishd[4333]: [ID 763057 local0.error] Pushing vcls failed: dlopen(./vcl.ORk8t3RP.so): ld.so.1: varnishd: fatal: ./vcl.ORk8t3RP.so: open failed: No such file or directory. Same using cc_command="/opt/sunstudio12.1/bin/cc -Kpic -G -m64 -L/opt/webcache/varnish/lib -o %o %s" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Feb 22 15:28:58 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Feb 2010 15:28:58 -0000 Subject: [Varnish] #648: http read error: 11 In-Reply-To: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> References: <054.b599f0bcbf5432885d7279a23e3120a4@projects.linpro.no> Message-ID: <063.6f146d151efc5808d220dffaa02d61e0@projects.linpro.no> #648: http read error: 11 ----------------------+----------------------------------------------------- Reporter: benliles | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Comment (by benliles): More testing late last week indicates that its the sess_timeout parameter that can be set at run time that was the problem. Despite settings in the vcl for timeouts on the backend of 1s on first connect, 120s for first byte and default (60s I think) for further bytes. The default sess_timeout, which is labeled as being an idle client timeout, is 5s. The 20 seconds came from 4 retries with errors at 5s each time. I increased the sess_timeout to 30s and we have not had any more reports of the problem from users. At this point, I do have some remaining problems. Why would a client timeout be affected by a slow backend response? The client obviously isn't closing the connection since it receives the error from Varnish. When this sess_timeout is hit, the restart portion of the vcl_error block seems to run, but the error response portion isn't working properly like it does for other types of errors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 23 12:22:34 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Feb 2010 12:22:34 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> References: <051.737d6d36d061fcfcaa25a15de92bddc2@projects.linpro.no> Message-ID: <060.44e8c4b538959ade6f1ec030eb25dd39@projects.linpro.no> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by janne): I took away the seq.proto kludge, and I'm again getting quite a lot of " http read error: 0" FetchErrors with 503. So, it seems the problem still persists. Tried with revision r4585. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 23 14:16:53 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Feb 2010 14:16:53 -0000 Subject: [Varnish] #650: Varnish probes and nginx + FastCGI don't get on together. In-Reply-To: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> References: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> Message-ID: <058.793b9d26c055fa7ebdbe180b8d5b878c@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by t0m): I just tried trunk, however I didn't get as far as testing this as trunk currently uses 100% CPU when idle with my configuration/build. I'll follow up with some info about what's actually going on once I've done some more investigation. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 23 19:25:08 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Feb 2010 19:25:08 -0000 Subject: [Varnish] #650: Varnish probes and nginx + FastCGI don't get on together. In-Reply-To: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> References: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> Message-ID: <058.494605812c40e44e65681c38f7685221@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by t0m): strace doesn't show anything interesting when varnish is consuming 100% of CPU: {{{ button varnish $ sudo strace -p 713 Process 713 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>) = 1 read(10, "ping\n", 8191) = 5 time(NULL) = 1266953031 writev(13, [{"200 19 \n", 13}, {"PONG 1266953031 1.0", 19}, {"\n", 1}], 3) = 33 poll([{fd=10, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(10, "ping\n", 8191) = 5 time(NULL) = 1266953034 writev(13, [{"200 19 \n", 13}, {"PONG 1266953034 1.0", 19}, {"\n", 1}], 3) = 33 poll([{fd=10, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(10, "ping\n", 8191) = 5 time(NULL) = 1266953037 writev(13, [{"200 19 \n", 13}, {"PONG 1266953037 1.0", 19}, {"\n", 1}], 3) = 33 poll( Process 713 detached }}} I'll attach a varnishstat and my config. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Feb 23 19:30:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Feb 2010 19:30:31 -0000 Subject: [Varnish] #650: Varnish probes and nginx + FastCGI don't get on together. In-Reply-To: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> References: <049.f13574f65bc7606b96ab592d291c426c@projects.linpro.no> Message-ID: <058.75fcea254fd260d5b5257b81b4823f0f@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by t0m): Attached. I'm trying r4585 of varnish, built by making slight tweaks to the debian/ directory included via svn:externals. The varnish process appears to perform as expected, despite the massive CPU consumption. I haven't got as far as testing if the originally described issue is fixed however. Let me know if I can provide more information as this issue is trivially reproducible on a non-production system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 26 09:42:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Feb 2010 09:42:31 -0000 Subject: [Varnish] #652: restart; loses POST data Message-ID: <053.e97eb7bbd6efe51e0d38291297e25e8a@projects.linpro.no> #652: restart; loses POST data ---------------------+------------------------------------------------------ Reporter: jespern | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ We're using a trick to emulate internal redirects, involving 'restart;' in vcl_fetch. Basically our 'default' backend is a small HTTP application that sets a header called 'Select-Shard', and varnish will restart the request with another backend selected. Unfortunately, once the request re-enters vcl_recv, if the request is a POST, the body will be gone. I believe anything involving 'restart;' suffers from this, from what I can understand after discussing this on IRC. Here's the VCL: {{{ backend default { .host = "127.0.0.1"; .port = "8089"; } backend web { .host = "127.0.0.1"; .port = "8000"; } backend web2 { .host = "127.0.0.1"; .port = "8001"; } director www_dir round-robin { { .backend = web; } # { .backend = web2; } } sub vcl_recv { if (req.http.Select-Shard == "web") { set req.backend = web; } elsif (req.http.Select-Shard == "web2") { set req.backend = web2; } elsif (req.http.Select-Shard == "rr") { set req.backend = www_dir; } } sub vcl_fetch { if (obj.http.Select-Shard) { set req.http.Select-Shard = obj.http.Select-Shard; restart; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 26 15:44:44 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Feb 2010 15:44:44 -0000 Subject: [Varnish] #653: TCP connections are not closed properly Message-ID: <051.1a9e9d86caf97f8db8395be4427f5f03@projects.linpro.no> #653: TCP connections are not closed properly -------------------+-------------------------------------------------------- Reporter: Sesse | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Hi, For some reason Varnish uses RST packets instead of FIN to close connections. This is a problem because: a) It breaks if packets are delivered out-of-order. b) It's contrary to ordinary TCP best practices. c) It confuses some client-side NATs; in particular, some Juniper implementations, which end up thinking the connection is still alive and sending bogus packets to both sides to revalidate it. Please, at the very least, add an option for using the normal close() FIN handshake. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 26 16:37:08 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Feb 2010 16:37:08 -0000 Subject: [Varnish] #654: VCL with Embeded C Message-ID: <057.242bd2b1961b54c201543c718f4f640b@projects.linpro.no> #654: VCL with Embeded C ---------------------------------+------------------------------------------ Reporter: MosheKaplan | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: 2.0 | Severity: normal Keywords: | ---------------------------------+------------------------------------------ I'm using Varnish 2.0.6 I installed the version on Fedora 8 and started it successfuly using a simple configuration adding google.com as my backend server. I successed as well in embedding a simple Embeded C inside the vcl_recv function. However when I tried to add simple code (both #include and/or global variables) outside the vcl functions, I received the following error: Expected 'acl', 'sub' or 'backend', found C{ ... }C at (/etc/varnish/default.vcl Line 5 Pos 1) C{ ## This is the VCL file: backend default { set backend.host = "www.google.com"; set backend.port = "80"; } C{ int j; }C sub vcl_recv { C{ int i = 0; i++; }C } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Feb 26 16:46:13 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Feb 2010 16:46:13 -0000 Subject: [Varnish] #654: VCL with Embeded C In-Reply-To: <057.242bd2b1961b54c201543c718f4f640b@projects.linpro.no> References: <057.242bd2b1961b54c201543c718f4f640b@projects.linpro.no> Message-ID: <066.a16d6022668e0eee52bb77e891c8cd4c@projects.linpro.no> #654: VCL with Embeded C -------------------------+-------------------------------------------------- Reporter: MosheKaplan | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by MosheKaplan): embedded :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 12:01:04 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 12:01:04 -0000 Subject: [Varnish] #655: Mismatching /* ... */ might cause confusion Message-ID: <054.f84e27ef66105b699839d85eb1189a5b@projects.linpro.no> #655: Mismatching /* ... */ might cause confusion -------------------------+-------------------------------------------------- Reporter: zviratko | Owner: phk Type: enhancement | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- They certainly did for me when the following is compiled, it results in a seemingly incorrect C code: backend default { .host = "localhost"; .port = "80"; } sub vcl_recv { if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE" && req.request != "PURGE") { /* Non-RFC2616 or CONNECT which is weird. */ pipe; } if (req.request != "GET" && req.request != "HEAD" && req.request != "PURGE" && req.request != "POST" ) { /* We only deal with GET and HEAD by default */ /* Zviratko - and with zero-sized POST as well, 3v1l h4ck * pass; } if ( req.request == "POST" ) { /* Zviratko - zero-sized POST is an AJAX hack, fsck it! */ set req.http.X-Request = "GETTED"; pass; } else if ( req.request == "POST" ) { set req.http.X-Request = "POSTED"; pass; } } while in fact there is / missing: /* Zviratko - and with zero-sized POST as well, 3v1l h4ck * and so the comment is matched up to: /* Zviratko - zero-sized POST is an AJAX hack, fsck it! */ maybe you might spit a warning when /* and */ numbers mismatch? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 12:01:17 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 12:01:17 -0000 Subject: [Varnish] #656: Mismatching /* ... */ might cause confusion Message-ID: <054.ee4f6a089044d5673ba3abc7ee641f70@projects.linpro.no> #656: Mismatching /* ... */ might cause confusion ----------------------+----------------------------------------------------- Reporter: zviratko | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- They certainly did for me when the following is compiled, it results in a seemingly incorrect C code: backend default { .host = "localhost"; .port = "80"; } sub vcl_recv { if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE" && req.request != "PURGE") { /* Non-RFC2616 or CONNECT which is weird. */ pipe; } if (req.request != "GET" && req.request != "HEAD" && req.request != "PURGE" && req.request != "POST" ) { /* We only deal with GET and HEAD by default */ /* Zviratko - and with zero-sized POST as well, 3v1l h4ck * pass; } if ( req.request == "POST" ) { /* Zviratko - zero-sized POST is an AJAX hack, fsck it! */ set req.http.X-Request = "GETTED"; pass; } else if ( req.request == "POST" ) { set req.http.X-Request = "POSTED"; pass; } } while in fact there is / missing: /* Zviratko - and with zero-sized POST as well, 3v1l h4ck * and so the comment is matched up to: /* Zviratko - zero-sized POST is an AJAX hack, fsck it! */ maybe you might spit a warning when /* and */ numbers mismatch? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 15:07:47 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 15:07:47 -0000 Subject: [Varnish] #656: Mismatching /* ... */ might cause confusion In-Reply-To: <054.ee4f6a089044d5673ba3abc7ee641f70@projects.linpro.no> References: <054.ee4f6a089044d5673ba3abc7ee641f70@projects.linpro.no> Message-ID: <063.5a3cc325881143eb530bbf8680c659ee@projects.linpro.no> #656: Mismatching /* ... */ might cause confusion ----------------------+----------------------------------------------------- Reporter: zviratko | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: dup of #655 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 23:01:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 23:01:31 -0000 Subject: [Varnish] #654: VCL with Embeded C In-Reply-To: <057.242bd2b1961b54c201543c718f4f640b@projects.linpro.no> References: <057.242bd2b1961b54c201543c718f4f640b@projects.linpro.no> Message-ID: <066.9fa98e8213b48694cc1cb07812dc78ab@projects.linpro.no> #654: VCL with Embeded C -------------------------+-------------------------------------------------- Reporter: MosheKaplan | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by MosheKaplan): Seems that it not really works with the stable version 2.0.6. It does work with the trunk version. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 23:06:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 23:06:05 -0000 Subject: [Varnish] #657: Log File Message-ID: <057.81c91ca1ce78450dc3d3333302b8e217@projects.linpro.no> #657: Log File ---------------------------------+------------------------------------------ Reporter: MosheKaplan | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: trunk | Severity: normal Keywords: | ---------------------------------+------------------------------------------ Using trunk version (Feb 26, 2010) on Fedora: I tried to read the log file using either varnishncsa or varnishlog and received the following error: # varnishncsa Cannot open /var/lib/varnish/domU-12-31-38-04-6C-93/_.vsl: No such file or directory When I created the file and directory I received: # varnishncsa Cannot read /var/lib/varnish/domU-12-31-38-04-6C-93/_.vsl: Success It seems like no log file was created and nothing could be read by varnishlog and varnishncsa Moshe -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 23:14:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 23:14:00 -0000 Subject: [Varnish] #657: Log File In-Reply-To: <057.81c91ca1ce78450dc3d3333302b8e217@projects.linpro.no> References: <057.81c91ca1ce78450dc3d3333302b8e217@projects.linpro.no> Message-ID: <066.d364e625f8b669bc527e6cc9e78eec57@projects.linpro.no> #657: Log File -------------------------+-------------------------------------------------- Reporter: MosheKaplan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Make sure you give the log programs the same -n argument as you give varnishd. If the _.vsl file is not there, then varnishd has not been started and run with the -n argument you are using. This kind of problem is usually better handled in the mailing lists or IRC channel, we only use tickets for bugs in the code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Feb 27 23:45:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 27 Feb 2010 23:45:03 -0000 Subject: [Varnish] #658: Response Content Change Message-ID: <057.9ef0138f4dc510f010ce041d6e9e7405@projects.linpro.no> #658: Response Content Change ---------------------------------+------------------------------------------ Reporter: MosheKaplan | Type: documentation Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: trunk | Severity: normal Keywords: | ---------------------------------+------------------------------------------ We would like to modify the returned response from the back end (not only the response headers, but the content itself as well): 1. Is it possible? 2. If so, using VCL or inline/embedded C? 3. What functions should be used for that? Best, Moshe -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Feb 28 19:02:46 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Feb 2010 19:02:46 -0000 Subject: [Varnish] #659: Varnish hcb_cleaner asset crash Message-ID: <053.23595e49b351a28cb0715b008df2ec8e@projects.linpro.no> #659: Varnish hcb_cleaner asset crash ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ {{{ Feb 28 16:48:58 web varnishd[12]: [ID 192877 local0.error] Child (21) not responding to ping, killing it. Feb 28 16:49:01 web last message repeated 1 time Feb 28 16:49:01 web varnishd[12]: [ID 214034 local0.error] Child (21) Panic message: Assert error in hcb_cleaner(), hash_critbit.c line 362: Feb 28 08:49:01 web Condition((oh->refcnt) == 0) not true. Feb 28 08:49:01 web thread = (hcb_cleaner) Feb 28 08:49:01 web ident = -sfile,-hcritbit,poll Feb 28 08:49:01 web Backtrace: Feb 28 08:49:01 web 430f73: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f73] Feb 28 08:49:01 web 18b41c0: [0x18b41c0] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Feb 28 21:54:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Feb 2010 21:54:49 -0000 Subject: [Varnish] #659: Varnish hcb_cleaner asset crash In-Reply-To: <053.23595e49b351a28cb0715b008df2ec8e@projects.linpro.no> References: <053.23595e49b351a28cb0715b008df2ec8e@projects.linpro.no> Message-ID: <062.8d04d6fa7c3c09d175a98cbce18032db@projects.linpro.no> #659: Varnish hcb_cleaner asset crash ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by victori): I am using varnish 4596M from trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator