From varnish-bugs at projects.linpro.no Mon Mar 1 09:47:05 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 09:47:05 -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.f96b477b63082e1feb5369a3c3732424@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 kristian): r4597 should take care of this: The timeout thread and pipe was set to level-triggered, but was working by means of: "Write(); sleep(); read();" in a single thread - and the actual acceptor thread never read the data, causing things to spin out of control. Should be fixed. Can anyone test and confirm? Besides myself. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 12:08:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 12:08:27 -0000 Subject: [Varnish] #658: Response Content Change In-Reply-To: <057.9ef0138f4dc510f010ce041d6e9e7405@projects.linpro.no> References: <057.9ef0138f4dc510f010ce041d6e9e7405@projects.linpro.no> Message-ID: <066.192455c118a2a197b101443e7d88c019@projects.linpro.no> #658: Response Content Change ---------------------------+------------------------------------------------ Reporter: MosheKaplan | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => wontfix Comment: We don't currently support this with anything that looks like a sensible API. You can probably do it with inline-C, but it is not a small matter of programming. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 12:13:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 12:13:39 -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.23a2d94e8f5d4b8808fc345828884dee@projects.linpro.no> #654: VCL with Embeded C -------------------------+-------------------------------------------------- Reporter: MosheKaplan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This is known to work. Be very careful about using variable names like 'i' and 'j', they could very easily clash with variables used in the compiled VCL code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 12:33:30 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 12:33:30 -0000 Subject: [Varnish] #652: restart; loses POST data In-Reply-To: <053.e97eb7bbd6efe51e0d38291297e25e8a@projects.linpro.no> References: <053.e97eb7bbd6efe51e0d38291297e25e8a@projects.linpro.no> Message-ID: <062.3b0088b6719fdd3f4cef3ad6096545e1@projects.linpro.no> #652: restart; loses POST data ---------------------+------------------------------------------------------ Reporter: jespern | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => invalid Comment: We throw away the body when we do the hash-lookup, and there is not much we can do about that in the present architecture. The present Varnish attitude to POST/PUT is that you pass or pipe them, that's all we do, changing that is not a trivial job. It sounds to me like you should implement a director that does what you want, that would solve the problem... Feel free to add this to our PostTwoShoppingList wiki page, but make sure to explain well how you think it should work, and why. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 12:37:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 12:37:38 -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.eb183f7bb1b22a3bdefaf0d72d9a9b7b@projects.linpro.no> #650: Varnish probes and nginx + FastCGI don't get on together. ----------------------+----------------------------------------------------- Reporter: t0m | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: The CPU usage problem is probably because you hit a half-fix for #644. And as I read it, -trunk does the right thing for your probes. 2.1 should work great for you when we release it this month :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 16:41:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 16:41:01 -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.7cb1e062346afb2f6f33d11ef4f4899c@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): I will verify.. I am also testing the following: {{{ --- cache_acceptor_epoll.c 2009-11-06 02:43:32.000000000 -0600 +++ cache_acceptor_epoll.c.new 2010-03-01 10:39:30.000000000 -0600 @@ -109,21 +109,22 @@ AN(ep->data.ptr); if (ep->data.ptr == vca_pipes) { if (ep->events & EPOLLIN || ep->events & EPOLLPRI) { - j = 0; - i = read(vca_pipes[0], ss, sizeof ss); - if (i == -1 && errno == EAGAIN) - return; - while (i >= sizeof ss[0]) { - CHECK_OBJ_NOTNULL(ss[j], SESS_MAGIC); - assert(ss[j]->fd >= 0); - AZ(ss[j]->obj); - VTAILQ_INSERT_TAIL(&sesshead, ss[j], list); - vca_cond_modadd(ss[j]->fd, ss[j]); - j++; - i -= sizeof ss[0]; - } - assert(i == 0); - } + while (i = read(vca_pipes[0], ss, sizeof ss)){ + j = 0; + if (i == -1 && errno == EAGAIN) + return; + while (i >= sizeof ss[0]) { + CHECK_OBJ_NOTNULL(ss[j], SESS_MAGIC); + assert(ss[j]->fd >= 0); + AZ(ss[j]->obj); + VTAILQ_INSERT_TAIL(&sesshead, ss[j], list); + vca_cond_modadd(ss[j]->fd, ss[j]); + j++; + i -= sizeof ss[0]; + } + assert(i == 0); + } + } } else { CAST_OBJ_NOTNULL(sp, ep->data.ptr, SESS_MAGIC); if (ep->events & EPOLLIN || ep->events & EPOLLPRI) { }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 1 16:48:21 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Mar 2010 16:48:21 -0000 Subject: [Varnish] #660: Varnish LINGER crash in tcp.c Message-ID: <053.1e55659133f8aa892e16a73728e68f22@projects.linpro.no> #660: Varnish LINGER crash in tcp.c ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ varnishd (varnish-trunk SVN 4596M) / opensolaris snv98 {{{ Mar 1 02:33:00 web varnishd[28390]: [ID 214034 local0.error] Child (28407) Panic message: Assert error in TCP_linger(), tcp.c line 271: Feb 28 18:33:00 web Condition(TCP_Check(i)) not true. Feb 28 18:33:00 web errno = 22 (Invalid argument) Feb 28 18:33:00 web thread = (cache-poll) Feb 28 18:33:00 web ident = -sfile,-hclassic,poll Feb 28 18:33:00 web Backtrace: Feb 28 18:33:00 web 430f73: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f73] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 2 20:46:51 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Mar 2010 20:46:51 -0000 Subject: [Varnish] #660: Varnish LINGER crash in tcp.c In-Reply-To: <053.1e55659133f8aa892e16a73728e68f22@projects.linpro.no> References: <053.1e55659133f8aa892e16a73728e68f22@projects.linpro.no> Message-ID: <062.a23a08d9fc604ddeb106b0a81ffa5875@projects.linpro.no> #660: Varnish LINGER crash in tcp.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by jack93250): Replying to [ticket:660 victori]: > varnishd (varnish-trunk SVN 4596M) / opensolaris snv98 > > {{{ > > Mar 1 02:33:00 web varnishd[28390]: [ID 214034 local0.error] Child (28407) Panic message: Assert error in TCP_linger(), tcp.c line 271: > Feb 28 18:33:00 web Condition(TCP_Check(i)) not true. > Feb 28 18:33:00 web errno = 22 (Invalid argument) > Feb 28 18:33:00 web thread = (cache-poll) > Feb 28 18:33:00 web ident = -sfile,-hclassic,poll > Feb 28 18:33:00 web Backtrace: > Feb 28 18:33:00 web 430f73: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f73] > > > }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From phk at phk.freebsd.dk Thu Mar 4 09:55:28 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 04 Mar 2010 09:55:28 +0000 Subject: BUG found In-Reply-To: Your message of "Wed, 17 Feb 2010 22:15:26 +0900." <69e4c7971002170515q401a8e23g2228dfabfa1bb88d@mail.gmail.com> Message-ID: <62024.1267696528@critter.freebsd.dk> In message <69e4c7971002170515q401a8e23g2228dfabfa1bb88d at mail.gmail.com>, Satos hi Abe writes: >Dear varnish developpers. > >I found the bug. Apologies for the delay in getting back to you, you email got buried in my inbox. This was fixed in r4529. Poul-Henning >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. >_______________________________________________ >varnish-bugs mailing list >varnish-bugs at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-bugs > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish-bugs at projects.linpro.no Sat Mar 6 00:36:24 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 06 Mar 2010 00:36:24 -0000 Subject: [Varnish] #661: More Varnish Crashes Message-ID: <053.4bf35d09bdd0a38f3b84211cc40d52c7@projects.linpro.no> #661: More Varnish Crashes ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ OpenSolaris / SNV98 - varnish-trunk SVN 4602M Panicked an hour apart {{{ Mar 5 08:57:38 web varnishd[19862]: [ID 214034 local0.error] Child (19895) Panic message: Assert error in http_copyheader(), cache_http.c line 647: Mar 5 00:57:38 web Condition(n < to->shd) not true. Mar 5 00:57:38 web errno = 131 (Connection reset by peer) Mar 5 00:57:38 web thread = (cache-worker) Mar 5 00:57:38 web ident = -sfile,-hclassic,poll Mar 5 00:57:38 web Backtrace: Mar 5 00:57:38 web 430f73: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f73] Mar 5 00:57:38 web fffffd7fc708ee58: [0xfffffd7fc708ee58] Mar 5 00:57:38 web sp = 82f018 { Mar 5 00:57:38 web fd = 27, id = 27, xid = 574842892, Mar 5 00:57:38 web client = 91.214.45.47:58417, Mar 5 00:57:38 web step = STP_FETCH, Mar 5 00:57:38 web handling = pass, Mar 5 00:57:38 web err_code = 206, err_reason = (null), Mar 5 00:57:38 web restarts = 0, esis = 0 Mar 5 00:57:38 web ws = 82f088 { Mar 5 00:57:38 web id = "sess", Mar 5 00:57:38 web {s,f,r,e} = {82fd90,+306,0,+65536}, Mar 5 00:57:38 web }, Mar 5 00:57:38 web http[req] = { Mar 5 00:57:38 web ws = 82f088[sess] Mar 5 00:57:38 web "GET", Mar 5 00:57:38 web "/blog/id", Mar 5 00:57:38 web "HTTP/1.0", Mar 5 00:57:38 web "Host: fabulously40.com", Mar 5 00:57:38 web "Cookie: X-SERVERID=2", Mar 5 00:57:38 web "Range: bytes=1-5000000", Mar 5 00:57:38 web "User-Agent: Mozilla 5.0 (Windows; U; Windows NT 5.0; us; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6)", Mar 5 00:57:38 web "Referer: http://fabulously40.com/blog/id/", Mar 5 00:57:38 web "X-Forwarded-For: 9 }}} {{{ Mar 5 09:28:53 web varnishd[19862]: [ID 214034 local0.error] Child (7137) Panic message: Assert error in http_copyheader(), cache_http.c line 647: Mar 5 01:28:53 web Condition(n < to->shd) not true. Mar 5 01:28:53 web thread = (cache-worker) Mar 5 01:28:53 web ident = -sfile,-hclassic,poll Mar 5 01:28:53 web Backtrace: Mar 5 01:28:53 web 430f73: /opt/extra/sbin/varnishd'pan_ic+0xc3 [0x430f73] Mar 5 01:28:53 web fffffd7fcc861e58: [0xfffffd7fcc861e58] Mar 5 01:28:53 web sp = 81e018 { Mar 5 01:28:53 web fd = 33, id = 33, xid = 1439605690, Mar 5 01:28:53 web client = 91.214.45.45:35662, Mar 5 01:28:53 web step = STP_FETCH, Mar 5 01:28:53 web handling = pass, Mar 5 01:28:53 web err_code = 206, err_reason = (null), Mar 5 01:28:53 web restarts = 0, esis = 0 Mar 5 01:28:53 web ws = 81e088 { Mar 5 01:28:53 web id = "sess", Mar 5 01:28:53 web {s,f,r,e} = {81ed90,+454,0,+65536}, Mar 5 01:28:53 web }, Mar 5 01:28:53 web http[req] = { Mar 5 01:28:53 web ws = 81e088[sess] Mar 5 01:28:53 web "GET", Mar 5 01:28:53 web "/view/blog/user/wicket:interface/:0:useractionsmenu:signupform::IFormSubmitListener::", Mar 5 01:28:53 web "HTTP/1.0", Mar 5 01:28:53 web "Host: fabulously40.com", Mar 5 01:28:53 web "Cookie: X-SERVERID=2", Mar 5 01:28:53 web "Range: bytes=1-5000000", Mar 5 01:28:53 web "User-Agent: Mozilla 5.0 (Windows; U; Windows NT 5.0; us; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6)", Mar 5 01:28:53 web "Referer: http://fabulously40.co Mar 5 09:28:53 web varnishd[19862]: [ID 584186 local0.notice] child (9360) Started }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 6 05:37:25 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 06 Mar 2010 05:37:25 -0000 Subject: [Varnish] #661: More Varnish Crashes In-Reply-To: <053.4bf35d09bdd0a38f3b84211cc40d52c7@projects.linpro.no> References: <053.4bf35d09bdd0a38f3b84211cc40d52c7@projects.linpro.no> Message-ID: <062.12cf453755a59f8bc09e290ac4cf4da5@projects.linpro.no> #661: More Varnish Crashes ---------------------+------------------------------------------------------ Reporter: victori | 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: This is already fixed in r4603 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Mar 9 19:29:14 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Mar 2010 19:29:14 -0000 Subject: [Varnish] #632: Varnish fails to accept connections in deamon mode. In-Reply-To: <053.46f7b7bb7c412713a926a10d2a281828@projects.linpro.no> References: <053.46f7b7bb7c412713a926a10d2a281828@projects.linpro.no> Message-ID: <062.eb2c6375b623381ef14a386981ba8bba@projects.linpro.no> #632: Varnish fails to accept connections in deamon mode. ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by jan): I can confirm this. did a little bit of debugging and it looks like a race condition: 1. parent compiles vcl file 2. forks child process 3. tells child to load compiled file 4. exits 5. unlinks compiled vcl in mgt_vcc_atexit 6. child tries to load compiled vcl => not found If 5. happens before 6. the child process won't find the file. Removing unlink() fixes the problem (but is obviously not a solution) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Mar 10 08:53:01 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Mar 2010 08:53:01 -0000 Subject: [Varnish] #662: "Connection refused" crashes Message-ID: <053.2abb3a05f7b39cf7ac697af282a281d6@projects.linpro.no> #662: "Connection refused" crashes ----------------------+----------------------------------------------------- Reporter: wrighty | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: critical | Keywords: ----------------------+----------------------------------------------------- Sent this to the mailing list but realised it's probably better reported here. We're seeing assert errors from TCP_blocking() and the errno is 146 (Connection refused). The client looks to be unknown at this point: client = ?.?.?.?:?, not sure if that helps pinpoint things. r4605 built with gcc on OpenSolaris snv_111b {{{ Child (9544) died signal=6 Child (9544) Panic message: Assert error in TCP_blocking(), tcp.c line 164: Condition(TCP_Check(j)) not true. errno = 146 (Connection refused) thread = (cache-worker) ident = -smalloc,-hcritbit,poll Backtrace: 42fc51: /opt/sbin/varnishd'pan_ic+0xb1 [0x42fc51] 8d: [0x8d] sp = 1c1b018 { fd = 141, id = 141, xid = 0, client = ?.?.?.?:?, step = STP_FIRST, handling = deliver, restarts = 0, esis = 0 ws = 1c1b088 { id = "sess", {s,f,r,e} = {1c1bd90,1c1bd90,0,+65536}, }, http[req] = { ws = 1c1b088[sess] "", "/pic/p2631_search.jpg", "HTTP/1.1", "Accept: */*", "Referer: http://sn112w.snt112.mail.live.com/mail/InboxLight.aspx?n=889024254", "Accept-Language: en-gb", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.4; SLCC1; .NET CLR 2.0.50727; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 3.0.30618)", "Host: media.firebox.com", "Connection: Keep-Alive", "X-Forwarded-For: 89.243.14.129", }, worker = fffffd7ff3de0d90 { ws = fffffd7ff3de0ed8 { id = "wrk", {s,f,r,e} = {fffffd7ff3dcecc0,fffffd7ff3dcecc0,0,+65536}, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 11 17:56:49 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Mar 2010 17:56:49 -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.b4edd6ac2381ef9f69253b84af77df78@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 | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): My understanding is that for this fix, not regressions have been found. The errno issue is due to missing compiler flags (-mt for SunCC), see discussion on varnish-misc. Correct? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 11 18:24:37 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Mar 2010 18:24:37 -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.bbbb33d7c3fc2ceb53dd3eb6a643d8ef@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 | Keywords: ----------------------+----------------------------------------------------- Comment(by victori): The errno issue is still there even with the thread-safety arguments passed to SunCC(-mt) or GCC. What causes the panics is the assert lines on setting linger in tcp.c and cache_acceptor.c. When I comment out the asserts calls around setting linger, varnish works reliably. cache_acceptor.c triggers panics a lot more frequently than the one in tcp.c. Cache_acceptor.c would trigger a panic every 20 minutes or so while tcp.c would do it in a day or two. As to the poll vs eventports debate, I have stuck to poll. Poll has been a lot more smooth in production than eventports. Last time I checked eventports had "stalls" on cache misses at semi-frequent random occasions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 10:49:07 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 10:49:07 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC Message-ID: <051.2a49e75ac791abb3ece85dc337872fdf@projects.linpro.no> #663: Varnish should auto-configure pthread support and VCC_CC --------------------------------------------------+------------------------- Reporter: slink | Type: enhancement Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: errno, mt-safety, pthread, reentrant | --------------------------------------------------+------------------------- The issues described in [http://lists.varnish-cache.org/pipermail/varnish- misc/2010-February/003831.html this thread] on varnish-misc were found to be root-caused in missing compiler flags for an MT-safety. I'll attach a patch to amend configure.ac with the ax_pthread macro, which hopefully will do the job of determining the correct settings cross platform. I've tested this change with trunk (4606) on OpenSolaris snv_111 with both * gcc version 3.4.3 (csl-sol210-3_4-20050802) * cc: Sun Ceres C 5.10 SunOS_i386 2009/03/06 and make check has not shown any reproducible issues. (I've seen random issues which were not reproducible and probably timing related, which I will have to investigate further). Also I have improved auto-configuration of VCC_CC. I am currently writing a test specific to errno MT-safety. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 11:38:07 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 11:38:07 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC In-Reply-To: <051.2a49e75ac791abb3ece85dc337872fdf@projects.linpro.no> References: <051.2a49e75ac791abb3ece85dc337872fdf@projects.linpro.no> Message-ID: <060.d4c2326ce7e34bc7465c47ad9db8bb75@projects.linpro.no> #663: Varnish should auto-configure pthread support and VCC_CC --------------------------------------------------+------------------------- Reporter: slink | Type: enhancement Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: errno, mt-safety, pthread, reentrant | --------------------------------------------------+------------------------- Comment(by slink): When I tested a specific VTC file to check errno behavior, I noticed that phk had already committed [4567]. Great: {{{ ### v1 debug| Child (13140) died signal=6 (core dumped)\n ### v1 debug| Child (13140) Panic message: Assert error in wrk_herdtimer_thread(), cache_pool.c line 419:\n ### v1 debug| Condition(errno_is_multi_threaded != 0) not true.\n ### v1 debug| thread = (wrk_herdtimer)\n ### v1 debug| ident = -sfile,-hcritbit,no_waiter\n ### v1 debug| Backtrace:\n ### v1 debug| 8072b4d: /export/home/slink/Devel/varnish/trunk /varnish-cache/bin/varnishd/.libs/varnishd'pan_ic+0xa9 [0x8072b4d]\n ### v1 debug| 807470e: /export/home/slink/Devel/varnish/trunk /varnish-cache/bin/varnishd/.libs/varnishd'wrk_herdtimer_thread+0x86 [0x807470e]\n ### v1 debug| fedacd56: /lib/libc.so.1'_thrp_setup+0x7e [0xfedacd56]\n ### v1 debug| fedacfe0: /lib/libc.so.1'_lwp_start+0x0 [0xfedacfe0]\n ### v1 debug| \n ### v1 debug| \n ### v1 debug| Child cleanup complete\n }}} I'll attach my VTC code anyway, just in case... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 12:58:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 12:58:06 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC In-Reply-To: <051.2a49e75ac791abb3ece85dc337872fdf@projects.linpro.no> References: <051.2a49e75ac791abb3ece85dc337872fdf@projects.linpro.no> Message-ID: <060.831f79e3d663cfde7fce27815e7cea0e@projects.linpro.no> #663: Varnish should auto-configure pthread support and VCC_CC --------------------------------------------------+------------------------- Reporter: slink | Type: enhancement Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: errno, mt-safety, pthread, reentrant | --------------------------------------------------+------------------------- Comment(by slink): For the record: The changeset I was referring to is [4569] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 13:34:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 13:34:42 -0000 Subject: [Varnish] #664: Trac notifications should have To: header Message-ID: <051.5d52e85b62298886e851a3d2b9405479@projects.linpro.no> #664: Trac notifications should have To: header -------------------+-------------------------------------------------------- Reporter: slink | Type: defect Status: new | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Current varnish trac notifications don't have a To: header and trigger this SpamAssassin Rule: {{{ pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 MISSING_HEADERS Missing To: header }}} It would be great if this was changed. Thank you, Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 13:45:00 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 13:45:00 -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.ddf48bb85b35f73a2077f8818645fc80@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 | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): Victor, thank you for your feedback. I am a bit resistant to accept that the TCP_linger issues have anything to do with the port acceptor, as I am not using the former and don't see any issues. Please do also note that phk has committed a change to remove lingering for the time being: [4605] The performance improvement of ports can be quite significant, I've seen a 25% drop in CPU usage on a heavily loaded site. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Mar 12 15:57:07 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Mar 2010 15:57:07 -0000 Subject: [Varnish] #665: should provide function for aligned allocations on the workspace Message-ID: <051.f1c589c0d2b0e8b492f9afff83768ad1@projects.linpro.no> #665: should provide function for aligned allocations on the workspace -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ws_alloc workspace allocation alignment -------------------------+-------------------------------------------------- When WS_Malloc was implemented, it was probably designed for the purpose of allocating memory for strings only, but it is now being used for allocation of space for arbitrary data structures. In general, such allocations may have alignment requirements. While alignment is enforced only on some harware platforms (many of which have become less popular (such as SPARC (unfortunetely) or MIPS)), also AMD makes a clear recommendation for the popular AMD64 platform: http://www.amd.com/us- en/assets/content_type/DownloadableAssets/dwamd_AMD64_Porting_FAQ.pdf What are the memory alignment requirements for code and data in each of these operating systems? There are no alignment requirements. x86 architecture has never had any alignment requirements and the 64-bit extensions have not added any. However, the ABI for 64-bit software has been designed to improve performance by striving for natural alignment of most memory operands. Natural alignment means that 2-byte objects are stored on 2-byte boundaries, 4-byte objects on 4-byte boundaries, etc. The performance side-effects of poorly aligned operands can be large. or here: http://developer.amd.com/pages/11112003167.aspx [...] a misaligned memory access can require more bus cycles than an aligned access. For maximum performance, avoid misaligned memory accesses. Therefor I am suggesting to introduce WS_Malloc for generic pointer-size aligned allocations (and WS_Calloc as a convenience function while I was at it already). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 13 14:04:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 13 Mar 2010 14:04:16 -0000 Subject: [Varnish] #665: should provide function for aligned allocations on the workspace In-Reply-To: <051.f1c589c0d2b0e8b492f9afff83768ad1@projects.linpro.no> References: <051.f1c589c0d2b0e8b492f9afff83768ad1@projects.linpro.no> Message-ID: <060.9975c703024bb4d20fddf0f91775d5c5@projects.linpro.no> #665: should provide function for aligned allocations on the workspace -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ws_alloc workspace allocation alignment -------------------------+-------------------------------------------------- Comment(by slink): I'll attach an update of the patch * macros for common code snippts * added WS_Mreserve (aligned reservation) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 13 15:34:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 13 Mar 2010 15:34:03 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references Message-ID: <051.4ef8029cb925c00a040e9abe54189f50@projects.linpro.no> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- == Intro == The patch in this ticket adds the "pmatch" feature to the VCL to reference sub-expressions specified in the regular expression used with the match (~) operator. Please refer to [http://perldoc.perl.org/perlre.html Perl Regular Expression Syntax documentation] for information on the regular expressions accepted by the match operator in varnish trunk. == Usage == Usage of the pmatch feature is simple. The variable pmatch.'''' contains the ''nth'' subexpression of the last successful match operator preceding the statement in the current VCL procedure. pmatch.0 contains the full match. pmatch scope is local to the VCL procedure (sub ) it is used in, so pmatch will never contain sub-expressions from matches in other VCL procedures. Note that it is not possible to use pmatch to retrieve matches from a match before the last successful match. It will only ever contain matches from the previous successful match within the same VCL procedure. Unsuccessful matches will not alter pmatch, neither will the regsub nor regsuball expressions. Use on invalid subexpression returns the empty string (""). To summarize, pmatch should behave like the ($1, $2, ...) variables in perl. == Examples == The following two simple examples, derived from the bundled test (tests/v00027.vtc), should illustrate the use: {{{ # back reference to whole matched string if (resp.http.Foobar ~ "ar") { set resp.http.Snafu1 = pmatch.0 } }}} After a successful match, pmatch.0 references the whole matched string, so in this example, the Snafu1 header will be set to "ar". {{{ if (resp.http.Foobar ~ "(b)(a)(r)(f)") { # back references to other sub-res set resp.http.Snafu3 = "_" pmatch.0 "_" pmatch.5 pmatch.4 pmatch.3 pmatch.2 "p_"; }}} This example illustrates several aspects: * pmatch.5 refers to an undefined sub-expression, so it will return the empty string (there is no fifth sub-expression in the regular expression). * pmatch.0 contains the full match, "barf" So, upon a successful match, the Snafu3 header will be set to "_barf_frap_". The examples were taken from the regsub test. == Implementation notes == * The name "pmatch" stems from the fact that I have originally implemented this feature for Varnish 2.0, which uses the C library RE functions. I'm open to suggestions for better names. * To hold references, a struct vrt_pmatch called local_pmatch is declared and initialized for each VCL procedure using VRT_init_proc. (include/vrt.h, lib/libvcl/vcc_parse.c) I've chosen this approach after I had used truly VCL-global scope using state saved in the sp for some time and realized that this implies too many additional problems (unclear state of pmatch in procedures, question of memory management). * The struct vrt_pmatch does not provide space to store the actual matches, this is allocated from sp->http->ws (as I don't know of a better alternative). (bin/varnishd/cache_vrt_re.c:VRT_re_match()) * I've put some effort into trying to minimize the space consumed by only keeping in the workspace those references which could possibly be reached. * Also, at VCL compile time, an upper bound on the maximum pmatch reference for each match is determined to minimize ws space requirements. (lib/libvcl/vcc_string.c:_vcc_regexp()) One aspect I am not completely happy with is that I need a list per struct proc in the VCC parser, so I moved the declarations of structures private to vcc_xref.c to vcc_compile.h. If this is considered unclean, I shall implement a more general service for other components to store information per procedure. * While space for the matches is allocated in VRT_re_match (if at all), the substrings themselves are only copied in VRT_r_pmatch, so subexpressions which are not referenced should never consume space on the ws for the strings, and only use minimal space for references if it has been determined that they could ever be accessed. (Note that subexpressions should be avoided if they are not needed, for instance by using the (?:) pcre syntax for grouping) * On the other hand, currently each VRT_re_match will result in a seperate copy of the subexpression. I've added code to implement a caching mechanism, but disabled it, because I think that without additional usage statistics, we cannot determine when caching the subexpression strings will pay off (see bin/varnishd/cache_vrt.c) * I've added pcre_study to VRE_compile to get best performance at run time and added a minor memory management optimization to VRE_exec. Please note that the patch depends on the patch in ticket #665 (and the patch in #663 should also be applied). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 13 18:29:51 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 13 Mar 2010 18:29:51 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <051.4ef8029cb925c00a040e9abe54189f50@projects.linpro.no> References: <051.4ef8029cb925c00a040e9abe54189f50@projects.linpro.no> Message-ID: <060.eb1bcc67bc7b7c7024e876c3b5daf4a1@projects.linpro.no> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by slink): I've realized that I've added code specific to the regexp-matching library used outside vre.c, so to wrap all of this, I should probably move more of what is in VRT_r_pmatch and VRT_re_match now into vre.c. I'll wait a little if more feedback arrives and, if this needs to be reworked again, change this too. Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:39:03 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:39:03 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.8237d66a8f5d21625888f0c4dd58e267@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: I'm closing this now, I am 99.9% certain this was the wrong compiler flags for multithreading tripping us up. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:40:28 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:40:28 -0000 Subject: [Varnish] #337: varnish doesn't work if compiled as 64bit in MacOSX In-Reply-To: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> References: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> Message-ID: <061.1c28c77ef3bf25bd669abb2fb1df8ba0@projects.linpro.no> #337: varnish doesn't work if compiled as 64bit in MacOSX ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: minor | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Time out this ticket. Please re-open if still issues. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:41:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:41:39 -0000 Subject: [Varnish] #555: died signal=6 , panic and restart every few sec. to min. In-Reply-To: <052.ceb4b4d9f15ca598018bb91e7d89e5e4@projects.linpro.no> References: <052.ceb4b4d9f15ca598018bb91e7d89e5e4@projects.linpro.no> Message-ID: <061.1c44567416323d7f0c253613865cc0b6@projects.linpro.no> #555: died signal=6 , panic and restart every few sec. to min. -------------------------+-------------------------------------------------- Reporter: skyfox | Type: defect Status: closed | Priority: highest Milestone: | Component: build Version: trunk | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I belive this was resolved in email, it's a classic out of workspace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:43:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:43:16 -0000 Subject: [Varnish] #535: Backend enver receives request... In-Reply-To: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> References: <051.a55307e8587098449b62a13a936d5873@projects.linpro.no> Message-ID: <060.734c0775336ed90f61e1e5cfcc5fcd62@projects.linpro.no> #535: Backend enver receives request... ----------------------+----------------------------------------------------- Reporter: seanc | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: solaris | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: Close this, it's a variant of the wrong pthread linker/compiler flags. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:45:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:45:52 -0000 Subject: [Varnish] #527: String representation of 'obj.ttl' not implemented yet. In-Reply-To: <048.41d80f2a68c7fedd71fd1a5c4f6d3db6@projects.linpro.no> References: <048.41d80f2a68c7fedd71fd1a5c4f6d3db6@projects.linpro.no> Message-ID: <057.423efb3b32039846691d649a63fd85d7@projects.linpro.no> #527: String representation of 'obj.ttl' not implemented yet. ----------------------+----------------------------------------------------- Reporter: aj | 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: This has been fixed in the meantime. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 08:49:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 08:49:52 -0000 Subject: [Varnish] #567: Varnish freeze in trunk/4199 In-Reply-To: <043.d82e1c6be61614de8c2b0af352505c5f@projects.linpro.no> References: <043.d82e1c6be61614de8c2b0af352505c5f@projects.linpro.no> Message-ID: <052.48bef5ce4aeeed05a147e19b09dcffaa@projects.linpro.no> #567: Varnish freeze in trunk/4199 ----------------------+----------------------------------------------------- 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'm going to close this one, it is likely a manifestation of some other bug, since fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 09:05:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 09:05:42 -0000 Subject: [Varnish] #632: Varnish fails to accept connections in deamon mode. In-Reply-To: <044.5d67bd9aebcaf7298a418e2d8d52aac0@projects.linpro.no> References: <044.5d67bd9aebcaf7298a418e2d8d52aac0@projects.linpro.no> Message-ID: <053.b665a571312a4b52a3abc0b73cf1ac56@projects.linpro.no> #632: Varnish fails to accept connections in deamon mode. ----------------------+----------------------------------------------------- Reporter: victori | Type: defect Status: closed | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4607 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Mar 15 09:08:27 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Mar 2010 09:08:27 -0000 Subject: [Varnish] #651: Can't run varnishd on OpenSolaris In-Reply-To: <041.555d674f43c74e18cb11fd9ac6a9a401@projects.linpro.no> References: <041.555d674f43c74e18cb11fd9ac6a9a401@projects.linpro.no> Message-ID: <050.8f99b0ed6c546a4b6729fa03e33e9156@projects.linpro.no> #651: Can't run varnishd on OpenSolaris ---------------------+------------------------------------------------------ Reporter: asyd | 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: Duplicate of #632, just fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Mar 17 20:22:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Mar 2010 20:22:59 -0000 Subject: [Varnish] #667: bug with cacheable false in vcl_fetch Message-ID: <041.157cd4f2d01f21d079aef06eaec55b91@projects.linpro.no> #667: bug with cacheable false in vcl_fetch ----------------------+----------------------------------------------------- Reporter: kali | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- Setting bereq.cacheable to false in vcl_fetch let requests identical to the one being fetch deadlocked. VCL: {{{ backend b { .host = "localhost"; .port = "4567"; } sub vcl_fetch { set beresp.cacheable = false; } }}} Backend: it just has to be something slow {{{ ruby -e 'require "rubygems" ; require "sinatra"; get "/" do sleep 30; "Hello there" end' }}} Varnish: {{{ varnishd -a :9000 -f /tmp/test.vcl -n /tmp -p default_gracet=0 }}} Client: {{{ 17/03 20:18 ~% curl http://localhost:9000 & [1] 2346 17/03 20:18 ~% curl http://localhost:9000 & [2] 2347 17/03 20:18 ~% Hello there [1] - 2346 done curl http://localhost:9000 }}} Only the first query is passed to the backend, and returns as expected after 30 seconds, the second stays in varnish cyberspace forever. It is not send to the backend, neither on reception of the request, nor when the reponse comes back. Varnishlog: {{{ 13 SessionOpen c ::1 48067 :9000 13 ReqStart c ::1 48067 265112395 13 RxRequest c GET 13 RxURL c / 13 RxProtocol c HTTP/1.1 13 RxHeader c User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10 13 RxHeader c Host: localhost:9000 13 RxHeader c Accept: */* 13 VCL_call c recv 13 VCL_return c lookup 13 VCL_call c hash 13 VCL_return c hash 13 VCL_call c miss 13 VCL_return c fetch 14 BackendOpen b b 127.0.0.1 47798 127.0.0.1 4567 13 Backend c 14 b b 14 TxRequest b GET 14 TxURL b / 14 TxProtocol b HTTP/1.1 14 TxHeader b User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10 14 TxHeader b Host: localhost:9000 14 TxHeader b Accept: */* 14 TxHeader b X-Forwarded-For: ::1 14 TxHeader b X-Varnish: 265112395 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1268857099 1.0 15 SessionOpen c ::1 48069 :9000 15 ReqStart c ::1 48069 265112396 15 RxRequest c GET 15 RxURL c / 15 RxProtocol c HTTP/1.1 15 RxHeader c User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10 15 RxHeader c Host: localhost:9000 15 RxHeader c Accept: */* 15 VCL_call c recv 15 VCL_return c lookup 15 VCL_call c hash 15 VCL_return c hash 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1268857102 1.0 [...] 0 CLI - Wr 200 PONG 1268857126 1.0 14 RxProtocol b HTTP/1.1 14 RxStatus b 200 14 RxResponse b OK 14 RxHeader b Connection: Keep-Alive 14 RxHeader b Content-Type: text/html 14 RxHeader b Date: Wed, 17 Mar 2010 20:18:49 GMT 14 RxHeader b Server: WEBrick/1.3.1 (Ruby/1.8.7/2008-08-11) 14 RxHeader b Content-Length: 11 13 TTL c 265112395 RFC 120 1268857129 0 0 0 0 13 VCL_call c fetch 13 VCL_return c pass 13 ObjProtocol c HTTP/1.1 13 ObjStatus c 200 13 ObjResponse c OK 13 ObjHeader c Content-Type: text/html 13 ObjHeader c Date: Wed, 17 Mar 2010 20:18:49 GMT 13 ObjHeader c Server: WEBrick/1.3.1 (Ruby/1.8.7/2008-08-11) 14 BackendReuse b b 13 Length c 11 13 VCL_call c deliver 13 VCL_return c deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 200 13 TxResponse c OK 13 TxHeader c Content-Type: text/html 13 TxHeader c Server: WEBrick/1.3.1 (Ruby/1.8.7/2008-08-11) 13 TxHeader c Content-Length: 11 13 TxHeader c Date: Wed, 17 Mar 2010 20:18:49 GMT 13 TxHeader c X-Varnish: 265112395 13 TxHeader c Age: 0 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: keep-alive 13 ReqEnd c 265112395 1268857099.029391527 1268857129.035051823 0.000235796 30.005545616 0.000114679 13 SessionClose c EOF 13 ReqEnd c 0 1268857129.035354376 1268857129.035354376 0.000302553 0.000000000 0.000000000 13 StatSess c ::1 48067 30 1 1 0 0 1 221 11 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1268857129 1.0 }}} I tried changing default_grace to 0, but it did not change anything. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Mar 17 20:41:19 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Mar 2010 20:41:19 -0000 Subject: [Varnish] #667: bug with cacheable false in vcl_fetch In-Reply-To: <041.157cd4f2d01f21d079aef06eaec55b91@projects.linpro.no> References: <041.157cd4f2d01f21d079aef06eaec55b91@projects.linpro.no> Message-ID: <050.b509a3564f260546a28031822b38d8aa@projects.linpro.no> #667: bug with cacheable false in vcl_fetch ----------------------+----------------------------------------------------- Reporter: kali | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- Comment(by kali): There is a typo in the varnish command line, I cut & paste the bad one. The good ones are {{{ varnishd -a :9000 -f /tmp/test.vcl -n /tmp varnishd -a :9000 -f /tmp/test.vcl -n /tmp -p default_grace=0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 18 08:16:32 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Mar 2010 08:16:32 -0000 Subject: [Varnish] #655: Mismatching /* ... */ might cause confusion In-Reply-To: <045.a5a7ba83a9255a1b27953f5253dab3e4@projects.linpro.no> References: <045.a5a7ba83a9255a1b27953f5253dab3e4@projects.linpro.no> Message-ID: <054.944d1406c4fcd9cd8d6b3fbf066b4a8a@projects.linpro.no> #655: Mismatching /* ... */ might cause confusion -------------------------+-------------------------------------------------- Reporter: zviratko | Owner: phk Type: enhancement | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r4627 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 18 11:15:06 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Mar 2010 11:15:06 -0000 Subject: [Varnish] #667: bug with cacheable false in vcl_fetch In-Reply-To: <041.157cd4f2d01f21d079aef06eaec55b91@projects.linpro.no> References: <041.157cd4f2d01f21d079aef06eaec55b91@projects.linpro.no> Message-ID: <050.67a95398e5cb1e6b607422d5623b1ec6@projects.linpro.no> #667: bug with cacheable false in vcl_fetch ----------------------+----------------------------------------------------- Reporter: kali | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Good catch! Fixed in r4632 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 18 11:39:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Mar 2010 11:39:42 -0000 Subject: [Varnish] #653: TCP connections are not closed properly In-Reply-To: <042.013e4460867d2cc1f93eb7ecebe2dc40@projects.linpro.no> References: <042.013e4460867d2cc1f93eb7ecebe2dc40@projects.linpro.no> Message-ID: <051.e566ac132a8bc3f4523d98dcdd387326@projects.linpro.no> #653: TCP connections are not closed properly ---------------------+------------------------------------------------------ Reporter: Sesse | 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: This was fixed last week. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 18 11:41:52 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Mar 2010 11:41:52 -0000 Subject: [Varnish] #603: admin interface gets confused (2.0.5) In-Reply-To: <041.5b96cfda54dfe494f8f87180b44a79d3@projects.linpro.no> References: <041.5b96cfda54dfe494f8f87180b44a79d3@projects.linpro.no> Message-ID: <050.1f99618852f5150972484928791ecb21@projects.linpro.no> #603: admin interface gets confused (2.0.5) ----------------------+----------------------------------------------------- Reporter: knan | 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: I have not been able to reproduce this at all. If this still happens with 2.1/-trunk, please reopen the ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Mar 18 11:42:41 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Mar 2010 11:42:41 -0000 Subject: [Varnish] #534: Threads stuck in trunk (critbit) In-Reply-To: <043.829b9d21ff394496b34753e60646af59@projects.linpro.no> References: <043.829b9d21ff394496b34753e60646af59@projects.linpro.no> Message-ID: <052.bf699d7843ed32f0e9ba2a4a30b9a89d@projects.linpro.no> #534: Threads stuck in trunk (critbit) ---------------------------+------------------------------------------------ Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: critical | Resolution: fixed Keywords: threads stuck | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: I belive this is fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From yvan.taviaud at gmail.com Sun Mar 21 08:19:22 2010 From: yvan.taviaud at gmail.com (Yvan Taviaud) Date: Sun, 21 Mar 2010 09:19:22 +0100 Subject: Bug in varnishlog (-u and -o flags) Message-ID: <4BA5D68A.4030708@gmail.com> Hello, I think I've found a bug after struggling for many hours with STDIN buffering. The fact is that I'm not a C developer, hence the time to understand the issue was in varnishlog took me hours :-) So, I was trying to use it with the following command: varnishlog -u -c -o TxStatus '^503$' > /tmp/varnish.test (in order to match all 503 errors) But this wasn't working good, as the output sent to the log file was buffered, even if the -u flag was used. I think the issue is here: (bin/varnishlog.c, around line 388, release is 2.0.6) if (o_flag) do_order(vd, argc - optind, argv + optind); if (u_flag) setbuf(stdout, NULL); So, as the do_order() is an infinite loop, the u_flag test is never seen. If I reverse both tests, everything seems to work as expected. Is there any issue inverting those tests? Also I'd like to know if there's a reason to disable -w when -o is used? It can be really useful, for example in this case I'm trying to track 503 errors, so logging to file with grouped requests would be great. Best regards, Yvan. From varnish-bugs at projects.linpro.no Sat Mar 20 09:26:16 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:26:16 -0000 Subject: [Varnish] #580: Esoteric path problem on Solaris 10 using SMF (unable to load compiled VCL file) In-Reply-To: <045.3e246d1fca3a7b41b176c1fcab2191bf@projects.linpro.no> References: <045.3e246d1fca3a7b41b176c1fcab2191bf@projects.linpro.no> Message-ID: <054.65dcb727c79fd72813f3403e57391456@projects.linpro.no> #580: Esoteric path problem on Solaris 10 using SMF (unable to load compiled VCL file) -------------------------+-------------------------------------------------- Reporter: whocares | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: Solaris SMF | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This was fixed last week, by mistake our compat daemon() function would run the atexit() calls. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 10:14:59 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 10:14:59 -0000 Subject: [Varnish] #565: "git: command not found" messages during build w/o git In-Reply-To: <045.a29fbd2129821e15a57bbf8e2cf2da04@projects.linpro.no> References: <045.a29fbd2129821e15a57bbf8e2cf2da04@projects.linpro.no> Message-ID: <054.8f4655ff9523da16cd38334dabfe1d47@projects.linpro.no> #565: "git: command not found" messages during build w/o git ----------------------+----------------------------------------------------- Reporter: kristian | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: minor | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: It looks to me like this is a harmless diagnostic from the production of svn_versionc.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 09:44:33 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:44:33 -0000 Subject: [Varnish] #497: Overflow in vrt_assemble_string In-Reply-To: <040.7e9c95bbbb1e3362f50161686042cc50@projects.linpro.no> References: <040.7e9c95bbbb1e3362f50161686042cc50@projects.linpro.no> Message-ID: <049.b1a8e1dd21658a7e0cbc3e8c10fa15b7@projects.linpro.no> #497: Overflow in vrt_assemble_string --------------------+------------------------------------------------------- Reporter: sky | 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: I belive this has been fixed, otherwise more concrete evidence is necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 09:19:50 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:19:50 -0000 Subject: [Varnish] #616: Persistent crash (sig11) in trunk 4434 In-Reply-To: <043.284fd0112f8b755e3acfab1d564d3fc8@projects.linpro.no> References: <043.284fd0112f8b755e3acfab1d564d3fc8@projects.linpro.no> Message-ID: <052.755074f3f395e7b1aa2d22b3b96a509f@projects.linpro.no> #616: Persistent crash (sig11) in trunk 4434 ----------------------+----------------------------------------------------- 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: I belive this was fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 09:18:39 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:18:39 -0000 Subject: [Varnish] #582: Varhish crash with no error code In-Reply-To: <045.433b00be43824a680b2e3080274de2d9@projects.linpro.no> References: <045.433b00be43824a680b2e3080274de2d9@projects.linpro.no> Message-ID: <054.5c7bab65941f8d0e8d31c36f2d702de3@projects.linpro.no> #582: Varhish crash with no error code ------------------------------------------------------------------------------------------+ Reporter: doserror | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: varnishd (varnish-2.0.4) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS | ------------------------------------------------------------------------------------------+ 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 Sat Mar 20 09:41:02 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:41:02 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <044.08f2066546c84908892fd245840e0845@projects.linpro.no> References: <044.08f2066546c84908892fd245840e0845@projects.linpro.no> Message-ID: <053.22ce6b4d389cb9d570ac9719e134c416@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Closing this one. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 10:01:26 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 10:01:26 -0000 Subject: [Varnish] #526: expiring objects with too large headers crashes varnish In-Reply-To: <043.50a7eddcced7d17429074091503f20a1@projects.linpro.no> References: <043.50a7eddcced7d17429074091503f20a1@projects.linpro.no> Message-ID: <052.c49582500297a9fbc3a9f51c97b338eb@projects.linpro.no> #526: expiring objects with too large headers crashes varnish ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): Can you still reproduce this ? I tried to, but could not provoke it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 09:29:31 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:29:31 -0000 Subject: [Varnish] #544: Some VCL variables may be missing in wiki VCL doc In-Reply-To: <045.cf01f4e9813d5d27ae7926518eed79ed@projects.linpro.no> References: <045.cf01f4e9813d5d27ae7926518eed79ed@projects.linpro.no> Message-ID: <054.492f23b4af128448c5778ec7ed0d5fdd@projects.linpro.no> #544: Some VCL variables may be missing in wiki VCL doc -----------------------+---------------------------------------------------- Reporter: walraven | Type: documentation Status: closed | Priority: low Milestone: | Component: documentation Version: trunk | Severity: normal Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Both of those variables have since vanished. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 13:03:34 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 13:03:34 -0000 Subject: [Varnish] #589: Round robin director not using healthy backend In-Reply-To: <044.44f87b9d6e6b595adaac5350515b208e@projects.linpro.no> References: <044.44f87b9d6e6b595adaac5350515b208e@projects.linpro.no> Message-ID: <053.e877409d9a63382998722291c04fce7c@projects.linpro.no> #589: Round robin director not using healthy backend ----------------------+----------------------------------------------------- Reporter: jrieger | 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 can't reproduce this in r4633. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 10:16:11 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 10:16:11 -0000 Subject: [Varnish] #595: segfault in 2.0.5 In-Reply-To: <051.9f2fd9926e68cd9d516464ec8ba7b91c@projects.linpro.no> References: <051.9f2fd9926e68cd9d516464ec8ba7b91c@projects.linpro.no> Message-ID: <060.1f65d24d4cce7aeb377bc0d4c6b28dd1@projects.linpro.no> #595: segfault in 2.0.5 ----------------------------------+----------------------------------------- Reporter: maheshollalwar | Type: defect Status: closed | Priority: high Milestone: Varnish 2.1 release | Component: build Version: 2.0 | Severity: major Resolution: worksforme | Keywords: ----------------------------------+----------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Whatever this was, it seems fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 10:04:42 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 10:04:42 -0000 Subject: [Varnish] #556: varnish error: Manager got SIGINT In-Reply-To: <056.a9ba96f067f8c17d297f2d1344b42092@projects.linpro.no> References: <056.a9ba96f067f8c17d297f2d1344b42092@projects.linpro.no> Message-ID: <065.7ec578fb5fec36bb7a28e1d9ecf45ded@projects.linpro.no> #556: varnish error: Manager got SIGINT ----------------------------------+----------------------------------------- Reporter: guobinchn@? | Type: defect Status: closed | Priority: normal Milestone: After Varnish 2.1 | Component: build Version: trunk | Severity: normal Resolution: worksforme | Keywords: ----------------------------------+----------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Sorry for taking so long in replying to this, but I have absolutely no idea where the SIGINTs come from and thus have very little to add. My best guess is that your kernel might be running out of something (VM?) and tries to kill the process which looks like it is hogging this resource. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 10:02:38 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 10:02:38 -0000 Subject: [Varnish] #543: vcl.discard causes crash In-Reply-To: <040.77994a6127d2724f6aaeaf5c7e2e863a@projects.linpro.no> References: <040.77994a6127d2724f6aaeaf5c7e2e863a@projects.linpro.no> Message-ID: <049.6671b3e4e8031f22c3c5851fc8e59f8e@projects.linpro.no> #543: vcl.discard causes crash ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Old description: > {{{ > Aug 17 23:55:31 varnish2 varnishd[16391]: > Child (308) Panic message: > Assert error in STV_alloc(), stevedore.c line 71: > Condition((st) != NULL) not true. > errno = 104 (Connection reset by peer) > thread = (cache-worker) > sp = 0x7f93ffc02008 { > fd = 1654, id = 1654, xid = 741934159, > client = 208.68.167.133:56858, > step = STP_FETCH, > handling = discard, > err_code = 200, > err_reason = (null), > ws = 0x7f93ffc02080 { > id = "sess", > {s,f,r,e} = {0x7f93ffc02820,,+3084,(nil),+131072}, > }, > worker = 0x7f98f4b90bd0 { > }, > vcl = { > srcname= { > "input", > "Default", > "/etc/varnish/yellowiki.vcl", > "/etc/varnish/SJC_backends.vcl", > "/etc/varnish/routing.vcl", > }, > }, > obj = 0x7fb986e90000 { > refcnt = 1, xid = 741934159, > ws = 0x7fb986e90028 { > id = "obj", > {s,f,r,e} = {0x7fb986e90358,,+238,(nil),+3240}, > }, > http = { > ws = 0x7fb986e90028 { > id = "obj", > {s,f,r,e} = {0x7fb986e90358,,+238,(nil),+3240}, > }, > }}} New description: {{{ Aug 17 23:55:31 varnish2 varnishd[16391]: Child (308) Panic message: Assert error in STV_alloc(), stevedore.c line 71: Condition((st) != NULL) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) sp = 0x7f93ffc02008 { fd = 1654, id = 1654, xid = 741934159, client = 208.68.167.133:56858, step = STP_FETCH, handling = discard, err_code = 200, err_reason = (null), ws = 0x7f93ffc02080 { id = "sess", {s,f,r,e} = {0x7f93ffc02820,,+3084,(nil),+131072}, }, worker = 0x7f98f4b90bd0 { }, vcl = { srcname= { "input", "Default", "/etc/varnish/yellowiki.vcl", "/etc/varnish/SJC_backends.vcl", "/etc/varnish/routing.vcl", }, }, obj = 0x7fb986e90000 { refcnt = 1, xid = 741934159, ws = 0x7fb986e90028 { id = "obj", {s,f,r,e} = {0x7fb986e90358,,+238,(nil),+3240}, }, http = { ws = 0x7fb986e90028 { id = "obj", {s,f,r,e} = {0x7fb986e90358,,+238,(nil),+3240}, }, }}} -- Comment(by phk): Is this still relevant ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Mar 20 09:30:57 2010 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Mar 2010 09:30:57 -0000 Subject: [Varnish] #626: Varnish Crashses cache_acceptor.c In-Reply-To: <044.56e5663afda9f508fe899928ffee4f17@projects.linpro.no> References: <044.56e5663afda9f508fe899928ffee4f17@projects.linpro.no> Message-ID: <053.a69f2865ecfae2ce1e683928386f5c0c@projects.linpro.no> #626: Varnish Crashses cache_acceptor.c ---------------------+------------------------------------------------------ Reporter: victori | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Close this, see #663 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:42:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:42:09 -0000 Subject: [Varnish] #533: Varnishncsa stucks after error vcl message In-Reply-To: <043.59a1b47ea95a67bded6623765a0d0b19@varnish-cache.org> References: <043.59a1b47ea95a67bded6623765a0d0b19@varnish-cache.org> Message-ID: <052.cae5a4f65dc5b23fe53232106a48762e@varnish-cache.org> #533: Varnishncsa stucks after error vcl message -------------------------+-------------------------------------------------- Reporter: Tarick | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 2.0 | Severity: major Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: The patch does not look correct to me. Please test -trunk to see if this has been solved, and if not, reopen this ticket with varnishlog output that stalls varnishncsa. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:44:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:44:01 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.ba0a7e2e36e6d85896ed1ce3b4cca67d@varnish-cache.org> #633: varnishncsa segfaults ---------------------+------------------------------------------------------ Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------+------------------------------------------------------ Comment(by phk): Is this still a problem ? Please capture varnishlog output at the same time you run varnishncsa, so we can see what the input sequence is. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:49:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:49:58 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. In-Reply-To: <044.097d4b9dc9d406f4c1dbc047325322e9@varnish-cache.org> References: <044.097d4b9dc9d406f4c1dbc047325322e9@varnish-cache.org> Message-ID: <053.0d170cf5b1dac74f95a1355f1be07189@varnish-cache.org> #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: reopened => closed * resolution: => fixed Comment: The fix seems to be working out, thus closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From noreply at boxbe.com Wed Mar 24 09:50:41 2010 From: noreply at boxbe.com (noreply at boxbe.com) Date: Wed, 24 Mar 2010 09:50:41 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. (Action Required) Message-ID: <1688456458.67086.1269424236860.JavaMail.prod@app010.dmz> Hello Varnish, Your message about "Re: [Varnish] #644: Deadlock in 2.0.x under high load." has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc=2065179064_748381759 Thank you, kmcfate at darkink.com About this Notice Boxbe prioritizes and screens email using a Guest List and your extended social network. Focus on email from the people who matter to you. Visit http://www.boxbe.com/how-it-works?tc=2065179064_748381759 End Email Overload -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Varnish" Subject: Re: [Varnish] #644: Deadlock in 2.0.x under high load. Date: Wed, 24 Mar 2010 09:49:54 -0000 Size: 2629 URL: From noreply at boxbe.com Wed Mar 24 09:50:44 2010 From: noreply at boxbe.com (noreply at boxbe.com) Date: Wed, 24 Mar 2010 09:50:44 -0000 Subject: [Varnish] #644: Deadlock in 2.0.x under high load. (Action Required) Message-ID: <1862672344.67098.1269424241011.JavaMail.prod@app010.dmz> Hello Varnish, Your message about "Re: [Varnish] #644: Deadlock in 2.0.x under high load." has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc=2065179073_1281526910 Thank you, kmcfate at darkink.com About this Notice Boxbe prioritizes and screens email using a Guest List and your extended social network. Focus on email from the people who matter to you. Visit http://www.boxbe.com/how-it-works?tc=2065179073_1281526910 End Email Overload -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Varnish" Subject: Re: [Varnish] #644: Deadlock in 2.0.x under high load. Date: Wed, 24 Mar 2010 09:49:54 -0000 Size: 2629 URL: From varnish-bugs at varnish-cache.org Wed Mar 24 19:19:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 19:19:35 -0000 Subject: [Varnish] #669: taking to long on startup when RLIMIT_NOFILE is very high Message-ID: <042.234bda83da426b84ee5fc3efa690fdd4@varnish-cache.org> #669: taking to long on startup when RLIMIT_NOFILE is very high ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When RLIMIT_NOFILE is set really high, the varnishd worker child spends a long time closing all possible fds - so long that the master process will give up on it. Workaround: set RLIMIT_NOFILE to a reasonable value (e.g. ulimit -n 128000) {{{ root at haggis:~# ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 1048576 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 29995 virtual memory (kbytes, -v) unlimited }}} excepts from a truss: {{{ 19795: sigaction(SIGCLD, 0xFFFFFD7FFFDFF120, 0x00000000) = 0 19795: sigaction(SIGPIPE, 0xFFFFFD7FFFDFF160, 0x00000000) = 0 19795: sigaction(SIGHUP, 0xFFFFFD7FFFDFF160, 0x00000000) = 0 19795: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) = 7 19795: setsockopt(7, SOL_SOCKET, SO_REUSEADDR, 0xFFFFFD7FFFDFF110, 4, SOV_DEFAULT) = 0 19795: bind(7, 0x0048D160, 16, SOV_SOCKBSD) = 0 19795: ioctl(7, FIONBIO, 0xFFFFFD7FFFDFF118) = 0 19795: pipe() = 8 [9] 19795: pipe() = 10 [11] 19795: pipe() = 12 [13] 19795: forkx(0) = 19797 19797: forkx() (returning as child ...) = 19795 19797: getpid() = 19797 [19795] 19797: lwp_self() = 1 19797: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF] 19797: getuid() = 0 [0] 19797: setgid(60001) = 0 19797: setuid(60001) = 0 19797: close(0) = 0 19797: open("/dev/null", O_RDONLY) = 0 19797: fcntl(13, F_DUP2FD, 0x00000001) = 1 19797: fcntl(13, F_DUP2FD, 0x00000002) = 2 19797: fstat(4294967295, 0xFFFFFD7FFFDFF0C0) Err#9 EBADF 19797: write(1, " C l o s e d f d s :", 11) = 11 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(3) = 0 19797: write(1, " 3", 2) = 2 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(4) = 0 19797: write(1, " 4", 2) = 2 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(5) = 0 19797: write(1, " 5", 2) = 2 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(6) = 0 19797: write(1, " 6", 2) = 2 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(9) = 0 19797: write(1, " 9", 2) = 2 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(10) = 0 19797: write(1, " 1 0", 3) = 3 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(12) = 0 19797: write(1, " 1 2", 3) = 3 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(13) = 0 19797: write(1, " 1 3", 3) = 3 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(14) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(15) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(16) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(17) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(18) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(19) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(20) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(21) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(22) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(23) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(24) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(25) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(26) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(27) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(28) Err#9 EBADF ... 19797: close(261) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: write(9, 0x004824E0, 32) = 32 19795: v c l . l o a d b o o t . / v c l . O R k 8 t 3 R P . s o\n 19797: close(262) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 ... 9797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: pollsys(0xFFFFFD7FFFDFEF30, 1, 0xFFFFFD7FFFDFEF00, 0x00000000) (sleeping...) 19797: close(33129) Err#9 EBADF ... 19797: close(977638) Err#9 EBADF 19795: pollsys(0xFFFFFD7FFFDFEF30, 1, 0xFFFFFD7FFFDFEF00, 0x00000000) = 0 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(977639) Err#9 EBADF 19795: write(2, 0x00452392, 21) = 21 19795: P u s h i n g v c l s f a i l e d : 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(977640) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: write(2, 0x0048AF30, 23) = 23 19795: C L I c o m m u n i c a t i o n e r r o r 19795: write(2, "\n", 1) = 1 19795: fstat(14, 0xFFFFFD7FFFDFE640) = 0 19795: time() = 1269457119 19797: close(977641) Err#9 EBADF 19795: getpid() = 19795 [1] 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: putmsg(14, 0xFFFFFD7FFFDFF010, 0xFFFFFD7FFFDFF020, 0) = 0 19795: open("/var/run/syslog_door", O_RDONLY) = 7 19795: door_info(7, 0xFFFFFD7FFFDFE3E0) = 0 19795: getpid() = 19795 [1] 19797: close(977642) Err#9 EBADF 19795: door_call(7, 0xFFFFFD7FFFDFE410) = 0 19795: close(7) = 0 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(977643) Err#9 EBADF 19795: read(12, 0x0050E570, 1023) = 30 19795: C l o s e d f d s : 3 4 5 6 9 1 0 1 2 1 3 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: getpid() = 19795 [1] 19797: close(977644) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19795: unlink("./vcl.ORk8t3RP.so") = 0 19797: close(977645) Err#9 EBADF ... 19797: close(977655) Err#9 EBADF 19795: _exit(2) 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 ... 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: close(1048575) Err#9 EBADF 19797: getrlimit(RLIMIT_NOFILE, 0xFFFFFD7FFFDFF140) = 0 19797: write(1, "\n", 1) Err#32 EPIPE 19797: Received signal #13, SIGPIPE [ignored] ... 19797/1: brk(0x00770FA0) = 0 19797/1: brk(0x00770FA0) = 0 19797/1: brk(0x00774FA0) = 0 19797/1: write(1, " R e a d y\n", 6) Err#32 EPIPE 19797/1: Received signal #13, SIGPIPE [ignored] 19797/1: pollsys(0xFFFFFD7FFFDFF110, 1, 0x00000000, 0x00000000) = 1 19797/1: write(2, 0x0044CC28, 31) Err#32 EPIPE 19797/1: E O F o n C L I c o n n e c t i o n , e x i t i n g\n 19797/1: Received signal #13, SIGPIPE [ignored] 19797/1: getpid() = 19797 [1] 19797/1: _exit(0) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 19:38:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 19:38:13 -0000 Subject: [Varnish] #670: need to support new solaris privilege net_access Message-ID: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> #670: need to support new solaris privilege net_access ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- This OpenSolaris commit... {{{ changeset: 11537:8eca52188202 user: Casper H.S. Dik date: Mon Jan 18 11:49:54 2010 +0100 description: }}} contains the introduction of a new net_access privilege: http://arc.opensolaris.org/caselog/PSARC/2009/685/20091222_casper.dik varnish needs to have that privilege, otherwise it will simply fail. The change is included in all Openslaris releases from onnv_132 / snv_132 onwards. I'll send a fix soon. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 19:47:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 19:47:19 -0000 Subject: [Varnish] #670: need to support new solaris privilege net_access In-Reply-To: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> References: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> Message-ID: <051.242f5f86985e2d25c69e56fe4c605c95@varnish-cache.org> #670: need to support new solaris privilege net_access ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): fix attached... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 20:39:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 20:39:40 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> References: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> Message-ID: <051.7a742a14b962af065e17e7c234814cb5@varnish-cache.org> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by slink): With the latest patch, I have tried to keep all code specific to pcre in vre.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 25 13:50:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 25 Mar 2010 13:50:43 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> References: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> Message-ID: <051.284256c9bb9bd1694c5c60ac9df826d2@varnish-cache.org> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by lrowe): 'match' would seem a better name for 'pmatch'. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 25 14:52:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 25 Mar 2010 14:52:20 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> References: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> Message-ID: <051.1913b65bd3309023a0715a736498997a@varnish-cache.org> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by slink): Luckily, renaming all instances of pmatch to match in the patch file is sufficient to rename the object. :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 29 13:25:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Mar 2010 13:25:36 -0000 Subject: [Varnish] #671: Solaris least privilege support breaks core dumps (SNOCD set) Message-ID: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> #671: Solaris least privilege support breaks core dumps (SNOCD set) -------------------+-------------------------------------------------------- Reporter: slink | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- The particular order of privilege set commands introduced with #628 leads to the SNOCD flag being set in this piece of solaris code: http://cvs.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/syscall/ppriv.c#160 {{{ #!C /* * When we give up privileges not in the inheritable set, * set SNOCD if not already set; first we compute the * privileges removed from P using Diff = (~P') & P * and then we check whether the removed privileges are * a subset of I. If we retain uid 0, all privileges * are required anyway so don't set SNOCD. */ if (type == PRIV_PERMITTED && (p->p_flag & SNOCD) == 0 && cr->cr_uid != 0 && cr->cr_ruid != 0 && cr->cr_suid != 0) { priv_set_t diff = CR_OPPRIV(cr); priv_inverse(&diff); priv_intersect(&CR_OPPRIV(pcr), &diff); donocd = !priv_issubset(&diff, &CR_IPRIV(cr)); } }}} The net effect is that, with least privilege support, varnish worker children do not dump cores any more. We must change the order in which privileges are waived to avoid this behavior. The attached patch is incremental to the fix in #670 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 22 13:38:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Mar 2010 13:38:36 -0000 Subject: [Varnish] #664: Trac notifications should have To: header In-Reply-To: <042.b9348c728b93a9f3882a5dd183af3488@varnish-cache.org> References: <042.b9348c728b93a9f3882a5dd183af3488@varnish-cache.org> Message-ID: <051.bd46efefa5f898eceea87bfc379b7e23@varnish-cache.org> #664: Trac notifications should have To: header ---------------------+------------------------------------------------------ Reporter: slink | Type: defect Status: closed | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I believe I have fixed this now, so closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 22 23:14:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Mar 2010 23:14:52 -0000 Subject: [Varnish] #668: accept(2) not checked in varnishtest Message-ID: <042.421874121f85ced8547c215ac3f07f36@varnish-cache.org> #668: accept(2) not checked in varnishtest -------------------------+-------------------------------------------------- Reporter: fgsch | Owner: phk Type: defect | Status: new Priority: low | Milestone: Varnish 2.1 release Component: varnishtest | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- The descriptor returned by accept(2) is not checked in vtc_server.c and vtc_http.c. For the former, if accept fails, -1 might be passed to poll, which is valid but will make poll(2) return 0, in turn calling vtc_log and eventually assert. This is confusing and will lead to an erroneous error in vtc_log. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 23 11:55:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Mar 2010 11:55:24 -0000 Subject: [Varnish] #664: Trac notifications should have To: header In-Reply-To: <042.b9348c728b93a9f3882a5dd183af3488@varnish-cache.org> References: <042.b9348c728b93a9f3882a5dd183af3488@varnish-cache.org> Message-ID: <051.e3dc25abb1b412985eace54e96d800c4@varnish-cache.org> #664: Trac notifications should have To: header ---------------------+------------------------------------------------------ Reporter: slink | Type: defect Status: closed | Priority: normal Milestone: | Component: website Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by slink): This looks much better now, thank you! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:20:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:20:34 -0000 Subject: [Varnish] #570: [2.0.4] Strange behaviour when using If-Modified-Since In-Reply-To: <047.d35a199376b61c61823509f10be0854c@varnish-cache.org> References: <047.d35a199376b61c61823509f10be0854c@varnish-cache.org> Message-ID: <056.fb39db912f72ac1ef7e4fb9c9025e773@varnish-cache.org> #570: [2.0.4] Strange behaviour when using If-Modified-Since ------------------------+--------------------------------------------------- Reporter: gdelacroix | 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: apologies for this ticket not being acted on sooner. I think this is a case of getting confused by "hit for pass", but given the incomplete and slightly self-contradictory information in the ticket, I cannot verify that hypothesis. I will close this ticket for now, if you can still reproduce this with -trunk, feel free to reopen, but please include complete vcl and varnishlog output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:23:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:23:39 -0000 Subject: [Varnish] #668: accept(2) not checked in varnishtest In-Reply-To: <042.421874121f85ced8547c215ac3f07f36@varnish-cache.org> References: <042.421874121f85ced8547c215ac3f07f36@varnish-cache.org> Message-ID: <051.c172822222f9b2a8012bd5ed4e9a2ba7@varnish-cache.org> #668: accept(2) not checked in varnishtest -------------------------+-------------------------------------------------- Reporter: fgsch | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Varnish 2.1 release Component: varnishtest | Version: trunk Severity: minor | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r4635, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:27:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:27:30 -0000 Subject: [Varnish] #542: varnishlog dies with segfault In-Reply-To: <044.42c20dedadb584d5806d176142e4a17f@varnish-cache.org> References: <044.42c20dedadb584d5806d176142e4a17f@varnish-cache.org> Message-ID: <053.ecd3a2b77c945e9f20448e212b4ee566@varnish-cache.org> #542: varnishlog dies with segfault ------------------------+--------------------------------------------------- Reporter: wfelipe | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I'm timing out this ticket, I belive this issue has been fixed. If not, feel free to reopen ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 24 09:35:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Mar 2010 09:35:04 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <043.ae215ce19c574a81763c730a84fc174d@varnish-cache.org> References: <043.ae215ce19c574a81763c730a84fc174d@varnish-cache.org> Message-ID: <052.34855a9cbeba4a45ba346963d1a3fc73@varnish-cache.org> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+-------------------------------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => worksforme Comment: As far as regression test r00412, this works in trun. If this is not the case, please provide details of how it is broken when you reopen this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator