From varnish-bugs at varnish-cache.org Tue Mar 1 16:08:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Mar 2011 16:08:11 -0000 Subject: [Varnish] #865: CNT_Session - TCP_blocking failing with ECONNREFUSED Message-ID: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> #865: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- I have three core dumps of varnish-2.1.4 SVN 5447M on Solaris (snv_111b) with identical stack traces: {{{ (gdb) bt #0 0xfec71997 in _lwp_kill () from /lib/libc.so.1 #1 0xfec6aa0c in thr_kill () from /lib/libc.so.1 #2 0xfec1ab7a in raise () from /lib/libc.so.1 #3 0xfebf200a in abort () from /lib/libc.so.1 #4 0x08079d4e in pan_ic (func=0xfef711e8 "TCP_blocking", file=0xfef711db "tcp.c", line=168, cond=0xfef711f5 "TCP_Check(j)", err=146, xxx=0) at cache_panic.c:365 #5 0xfef67ea1 in TCP_blocking (sock=31) at tcp.c:168 #6 0x08068854 in CNT_Session (sp=0xf985d14) at cache_center.c:1235 #7 0x0807b4a2 in wrk_do_cnt_sess (w=0xf85dfdf4, priv=0xf985d14) at cache_pool.c:294 #8 0x0807ada6 in wrk_thread_real (qp=0x80d9348, shm_workspace=8192, sess_workspace=32768, nhttp=64, http_space=620, siov=16) at cache_pool.c:183 #9 0x0807b14f in wrk_thread (priv=0x80d9348) at cache_pool.c:224 #10 0xfec6cd56 in _thrp_setup () from /lib/libc.so.1 #11 0xfec6cfe0 in __csigsetjmp () from /lib/libc.so.1 #12 0x00000000 in ?? () }}} I am trying to understand why Solaris would return ECONNREFUSED at this point. Could be here: http://cvs.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/fs/sockfs/sockcommon_subr.c#221 this is called from so_connect() So maybe we just need to relax the assertion, but before suggesting to do so, I would like to understand this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 1 17:56:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Mar 2011 17:56:20 -0000 Subject: [Varnish] #865: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.998f29e36f24e45fab3a564707675d36@varnish-cache.org> #865: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by slink): * owner: => slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 1 18:07:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Mar 2011 18:07:47 -0000 Subject: [Varnish] #865: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.0d72b4e6530dd258d03e925b5897490b@varnish-cache.org> #865: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by slink): * status: new => assigned Comment: Progress update: The issue also surfaces in varnishtest for some fraction of the tests. I can reproduce it repeating any simple test until it fails, like: {{{ while ./varnishtest tests/b00010.vtc ; do : ; done ... *** top client ** c1 Starting client ** c1 Waiting for client *** c1 Connect to 127.0.0.1 38476 ---- c1 vtc_log2 Assert error in TCP_blocking(), tcp.c line 185: Condition(TCP_Check(j)) not true. errno=146 }}} Using Dtrace and speculative tracing, I got hold of the code path through the kernel: {{{ dtrace: script '/var/tmp/specioctl.d' matched 68002 probes CPU FUNCTION 1 => ioctl arg1: 2147772030 1 -> ioctl 1 -> getf 1 -> set_active_fd 1 <- set_active_fd 1 -> set_active_fd 1 <- set_active_fd 1 <- getf 1 -> get_udatamodel 1 <- get_udatamodel 1 -> fop_ioctl 1 -> crgetmapped 1 <- crgetmapped 1 -> socket_vop_ioctl 1 -> socket_ioctl 1 -> so_ioctl 1 -> sogeterr 1 <- sogeterr 1 <- so_ioctl 1 <- socket_ioctl 1 <- socket_vop_ioctl 1 <- fop_ioctl 1 -> releasef 1 -> clear_active_fd 1 <- clear_active_fd 1 -> cv_broadcast 1 <- cv_broadcast 1 <- releasef 1 -> set_errno 1 <- set_errno 1 <- ioctl 1 <= ioctl 146 ^C }}} I will continue later. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:20:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:20:35 -0000 Subject: [Varnish] #786: ESI includes don't follow 301 and 302 redirects In-Reply-To: <051.c431285741f2134d6828acd4e6fc55a2@varnish-cache.org> References: <051.c431285741f2134d6828acd4e6fc55a2@varnish-cache.org> Message-ID: <060.4cec2aac1f628260282030a76baca753@varnish-cache.org> #786: ESI includes don't follow 301 and 302 redirects -----------------------------------------------+---------------------------- Reporter: jorgen@? | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: invalid Keywords: varnishd, esi, redirect, 301, 302 | -----------------------------------------------+---------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Old description: > When using and > http://localhost/test responds with an HTTP 301 or 302 redirect, the > content of the 301 or 302 response is included, not the content of the > resource given in the Location header. This can give results like this: > > >

ESI test

> > > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > > The source in this case was > > >

ESI test

> > > > In my opinion, the redirects should be followed. If that causes > performance loss, it should be possible to configure varnish to turn on > or off redirect following in ESI includes. New description: When using and http://localhost/test responds with an HTTP 301 or 302 redirect, the content of the 301 or 302 response is included, not the content of the resource given in the Location header. This can give results like this:

ESI test

301 Moved Permanently

Moved Permanently

The document has moved here.

The source in this case was

ESI test

In my opinion, the redirects should be followed. If that causes performance loss, it should be possible to configure varnish to turn on or off redirect following in ESI includes. -- Comment: I have pondered this one and moved it to the PostTwoShoppingList, because it is more of a feature request than a bug report (hence the "invalid" close reason, that just means: "not a bug" in this case). The way to deal with this, is to do a restart in your VCL. Handling it behind the scenes will amount to the same thing, and I am not keen on moving policy decisions from VCL to C code if it can be avoided. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:23:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:23:26 -0000 Subject: [Varnish] #807: varnishlog should do input validation In-Reply-To: <043.8ccc2e377b952dd35985726ef7341ac8@varnish-cache.org> References: <043.8ccc2e377b952dd35985726ef7341ac8@varnish-cache.org> Message-ID: <052.47093233e9a879cab8a50bd5696cbb56@varnish-cache.org> #807: varnishlog should do input validation ------------------------+--------------------------------------------------- Reporter: tfheen | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ------------------------+--------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => duplicate Comment: #864 contains more info on this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:26:44 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:26:44 -0000 Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> Message-ID: <053.57bac4e03442b19451ca8833016f7c93@varnish-cache.org> #864: Varnishlog crashes when searching for 503 errors ------------------------+--------------------------------------------------- Reporter: kriller | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishlog | Version: 2.1.5 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Changes (by kristian): * status: new => assigned * component: build => varnishlog Comment: Ok, this is definitely a bug. It also ties in with #807, and is largely known. The essence of the problem is lack of input-validation in varnishlog. (And other tools) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:28:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:28:33 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <042.cab0982cea162abd35f084117925306c@varnish-cache.org> References: <042.cab0982cea162abd35f084117925306c@varnish-cache.org> Message-ID: <051.4a0ed10b2b642006ecaaf323b8526c11@varnish-cache.org> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: kristian Type: defect | Status: assigned Priority: high | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => assigned * version: 2.0 => trunk * milestone: => Later * owner: phk => kristian * severity: major => normal Old description: > (see also the discussion in > http://projects.linpro.no/pipermail/varnish-dev/2009-December/002348.html > ) > > When very many sessions are waiting for a busy object from a slow > backend, varnish may panic in HSH_prepare with a message similar to > the following > > {{{ > varnishd[7518]: [ID 733861 local0.error] Child (8742) Panic message: > Missing errorhandling code in HSH_Prepare(), cache_hash.c line 187: > Condition((p) != 0) not true. errno = 32 (Broken pipe) thread = > (cache-worker)sp = 10bc7038 { > fd = 2322, id = 2322, xid = 441755642, > client = X.X.X.X:61981, > step = STP_LOOKUP, > handling = hash, > ws = 10bc70a8 { overflow > id = "sess", > {s,f,r,e} = {10bc7938,,+16340,0,+16384}, > }, > worker = fffffd7e5d504e00 { > }, > vcl = { > srcname = { > "input", > "Default", > }, > }, > }, > }}} > > This panic message is, in many cases, a symptom of too small a > session workspace (see also #472, #551, #560). For the issue > documented here to apply, the session workspace should be inspected: > > {{{ > (gdb) x /52x sp->ws->e-1000 > 0x10bcb550: 0x00000000 0x00000000 0x10bc794f > 0x00000000 > 0x10bcb560: 0x10bc7950 0x00000000 0x10bc7bcb > 0x00000000 > 0x10bcb570: 0x10bc7bd6 0x00000000 0x00000000 > 0x00000000 > 0x10bcb580: 0x00000000 0x00000000 0x00000000 > 0x00000000 > 0x10bcb590: 0x10bc794f 0x00000000 0x10bc7950 > 0x00000000 > 0x10bcb5a0: 0x10bc7bcb 0x00000000 0x10bc7bd6 > 0x00000000 > 0x10bcb5b0: 0x00000000 0x00000000 0x00000000 > 0x00000000 > 0x10bcb5c0: 0x00000000 0x00000000 0x10bc794f > 0x00000000 > 0x10bcb5d0: 0x10bc7950 0x00000000 0x10bc7bcb > 0x00000000 > 0x10bcb5e0: 0x10bc7bd6 0x00000000 0x00000000 > 0x00000000 > 0x10bcb5f0: 0x00000000 0x00000000 0x00000000 > 0x00000000 > 0x10bcb600: 0x10bc794f 0x00000000 0x10bc7950 > 0x00000000 > 0x10bcb610: 0x10bc7bcb 0x00000000 0x10bc7bd6 > 0x00000000 > }}} > > If this issue applies, the workspace will be clobbered with a sequence > of hash pointers: > > {{{ > (gdb) print sp->nhashptr > $8 = 6 > > (gdb) print *sp->hashptr > $14 = 0x10bc794f "/" > (gdb) print *(sp->hashptr+1) > $15 = 0x10bc7950 "" > (gdb) print *(sp->hashptr+2) > $16 = 0x10bc7bcb "www.XXXX.de" > (gdb) print *(sp->hashptr+3) > $17 = 0x10bc7bd6 "" > (gdb) print *(sp->hashptr+4) > $18 = 0x0 > (gdb) print *(sp->hashptr+5) > $19 = 0x0 > (gdb) print *(sp->hashptr+6) > $20 = 0x0 > }}} > > In the case, the reason for the panic is that the session repeatedly > got rushed (scheduled onto a thread) while the object it was waiting > for was still busy. While this should, in principle, only add > additional computational overhead for checking if the object being > waited for has become available in the cache, a side effect of the > particular (efficient) memory management used for workspaces causes > session workspace exhaustion: > > When we determine in cnt_lookup that the requested object is busy, > we've already allocated memory from the session workspace, so if we > enter cnt_lookup very often, we will eventually clobber the session > workspace and panic: > > {{{ > #!c > if (sp->obj == NULL) { > HSH_Prepare(sp, sp->vcl->nhashcount); > VCL_hash_method(sp); > assert(sp->handling == VCL_RET_HASH); > } > > o = HSH_Lookup(sp); > > if (o == NULL) { > /* > * We lost the session to a busy object, disembark the > * worker thread. The hash code to restart the session, > * still in STP_LOOKUP, later when the busy object isn't. > * > * XXX When getting here, we have allocated space for > * sp->hashptr on sp->http->ws using HSH_Prepare, which > we never > * return until the whole session object is destroyed. We > would > * want to use WS_Release on the space allocated by > HSH_Prepare, > * but VCL_hash_method(sp) could have allocated space and > used > * (refenced) it anywhere in the session object - so > unless we > * changed memory management into something less > efficient, we > * can't safely return the space. > * > * This imposes a practical limit on the number of > restarts > * > */ > return (1); > } > }}} > > The comment explains why I think this cant be fixed easily. > > I will attach a suggested fix for varnish 2.0.5 which should reduce > rushes to those cases when they actually make sense. > > I haven't looked at the current trunk yet, but as far as I remember, > the relevant functions have been changed siginificantly. > > Thank you for this great product, > > Nils New description: (see also the discussion in http://projects.linpro.no/pipermail/varnish-dev/2009-December/002348.html ) When very many sessions are waiting for a busy object from a slow backend, varnish may panic in HSH_prepare with a message similar to the following {{{ varnishd[7518]: [ID 733861 local0.error] Child (8742) Panic message: Missing errorhandling code in HSH_Prepare(), cache_hash.c line 187: Condition((p) != 0) not true. errno = 32 (Broken pipe) thread = (cache-worker)sp = 10bc7038 { fd = 2322, id = 2322, xid = 441755642, client = X.X.X.X:61981, step = STP_LOOKUP, handling = hash, ws = 10bc70a8 { overflow id = "sess", {s,f,r,e} = {10bc7938,,+16340,0,+16384}, }, worker = fffffd7e5d504e00 { }, vcl = { srcname = { "input", "Default", }, }, }, }}} This panic message is, in many cases, a symptom of too small a session workspace (see also #472, #551, #560). For the issue documented here to apply, the session workspace should be inspected: {{{ (gdb) x /52x sp->ws->e-1000 0x10bcb550: 0x00000000 0x00000000 0x10bc794f 0x00000000 0x10bcb560: 0x10bc7950 0x00000000 0x10bc7bcb 0x00000000 0x10bcb570: 0x10bc7bd6 0x00000000 0x00000000 0x00000000 0x10bcb580: 0x00000000 0x00000000 0x00000000 0x00000000 0x10bcb590: 0x10bc794f 0x00000000 0x10bc7950 0x00000000 0x10bcb5a0: 0x10bc7bcb 0x00000000 0x10bc7bd6 0x00000000 0x10bcb5b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x10bcb5c0: 0x00000000 0x00000000 0x10bc794f 0x00000000 0x10bcb5d0: 0x10bc7950 0x00000000 0x10bc7bcb 0x00000000 0x10bcb5e0: 0x10bc7bd6 0x00000000 0x00000000 0x00000000 0x10bcb5f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x10bcb600: 0x10bc794f 0x00000000 0x10bc7950 0x00000000 0x10bcb610: 0x10bc7bcb 0x00000000 0x10bc7bd6 0x00000000 }}} If this issue applies, the workspace will be clobbered with a sequence of hash pointers: {{{ (gdb) print sp->nhashptr $8 = 6 (gdb) print *sp->hashptr $14 = 0x10bc794f "/" (gdb) print *(sp->hashptr+1) $15 = 0x10bc7950 "" (gdb) print *(sp->hashptr+2) $16 = 0x10bc7bcb "www.XXXX.de" (gdb) print *(sp->hashptr+3) $17 = 0x10bc7bd6 "" (gdb) print *(sp->hashptr+4) $18 = 0x0 (gdb) print *(sp->hashptr+5) $19 = 0x0 (gdb) print *(sp->hashptr+6) $20 = 0x0 }}} In the case, the reason for the panic is that the session repeatedly got rushed (scheduled onto a thread) while the object it was waiting for was still busy. While this should, in principle, only add additional computational overhead for checking if the object being waited for has become available in the cache, a side effect of the particular (efficient) memory management used for workspaces causes session workspace exhaustion: When we determine in cnt_lookup that the requested object is busy, we've already allocated memory from the session workspace, so if we enter cnt_lookup very often, we will eventually clobber the session workspace and panic: {{{ #!c if (sp->obj == NULL) { HSH_Prepare(sp, sp->vcl->nhashcount); VCL_hash_method(sp); assert(sp->handling == VCL_RET_HASH); } o = HSH_Lookup(sp); if (o == NULL) { /* * We lost the session to a busy object, disembark the * worker thread. The hash code to restart the session, * still in STP_LOOKUP, later when the busy object isn't. * * XXX When getting here, we have allocated space for * sp->hashptr on sp->http->ws using HSH_Prepare, which we never * return until the whole session object is destroyed. We would * want to use WS_Release on the space allocated by HSH_Prepare, * but VCL_hash_method(sp) could have allocated space and used * (refenced) it anywhere in the session object - so unless we * changed memory management into something less efficient, we * can't safely return the space. * * This imposes a practical limit on the number of restarts * */ return (1); } }}} The comment explains why I think this cant be fixed easily. I will attach a suggested fix for varnish 2.0.5 which should reduce rushes to those cases when they actually make sense. I haven't looked at the current trunk yet, but as far as I remember, the relevant functions have been changed siginificantly. Thank you for this great product, Nils -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:29:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:29:13 -0000 Subject: [Varnish] #610: rushing too often may overflow session workspace In-Reply-To: <042.cab0982cea162abd35f084117925306c@varnish-cache.org> References: <042.cab0982cea162abd35f084117925306c@varnish-cache.org> Message-ID: <051.ff4069bd71989d6ed19de826262c50b0@varnish-cache.org> #610: rushing too often may overflow session workspace ----------------------+----------------------------------------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: high | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * owner: kristian => * status: assigned => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:49:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:49:13 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.c1928e47cd5676cd7eed39b57f657d7c@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ---------------------------+------------------------------------------------ Reporter: censored | Owner: perbu Type: documentation | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: documentation | Version: trunk Severity: normal | Keywords: varnishd HSH_Lookup died ---------------------------+------------------------------------------------ Changes (by kristian): * type: defect => documentation * version: 2.1.3 => trunk * component: varnishd => documentation * milestone: => Varnish 3.0 dev Comment: Should probably get documented properly before 3.0, given scope. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:49:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:49:53 -0000 Subject: [Varnish] #477: Change defaults to respect Cache-Control: private In-Reply-To: <041.9226b1c4ffd27a15ef76220ae7e29120@varnish-cache.org> References: <041.9226b1c4ffd27a15ef76220ae7e29120@varnish-cache.org> Message-ID: <050.91d0cf577a10a75b6cca283dc9c9f8a4@varnish-cache.org> #477: Change defaults to respect Cache-Control: private ----------------------+----------------------------------------------------- Reporter: olau | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * component: build => varnishd * milestone: => Varnish 3.0 dev Old description: > In some cases you'd want to bypass the cache if the web app behind is > doing something based on the actual connection/request, e.g. inspecting > the IP address to guestimate the country and then redirecting based on > that. > > In this case, it makes sense to turn off any caches between the web app > and the browser, but still allow the browser to cache the reply. As I > read RFC2616, this is what Cache-Control: private is meant for. > > Thus I believe the default configuration of Varnish should take Cache- > Control: private as a hint that the object is not cacheable and let it > pass. As it is now, default Varnish will share the response between users > which breaks the web app (this is not just theory, it actually broke mine > :-). > > We talked about it on the mailing list here > > http://projects.linpro.no/pipermail/varnish- > misc/2009-February/002575.html > > The only ill effect I can see of it is if you have a really broken > backend that sends out Cache-Control: private even if it doesn't really > mean it. But still defaulting to no caching is the safe choice. You can > always configure Varnish to disregard the header if you know it's fine in > your case. New description: In some cases you'd want to bypass the cache if the web app behind is doing something based on the actual connection/request, e.g. inspecting the IP address to guestimate the country and then redirecting based on that. In this case, it makes sense to turn off any caches between the web app and the browser, but still allow the browser to cache the reply. As I read RFC2616, this is what Cache-Control: private is meant for. Thus I believe the default configuration of Varnish should take Cache- Control: private as a hint that the object is not cacheable and let it pass. As it is now, default Varnish will share the response between users which breaks the web app (this is not just theory, it actually broke mine :-). We talked about it on the mailing list here http://projects.linpro.no/pipermail/varnish-misc/2009-February/002575.html The only ill effect I can see of it is if you have a really broken backend that sends out Cache-Control: private even if it doesn't really mean it. But still defaulting to no caching is the safe choice. You can always configure Varnish to disregard the header if you know it's fine in your case. -- Comment: Some discussion ensued... regarding http-bis and others. No clear conclusion yet, but we should resolve this one way or an other before 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:57:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:57:36 -0000 Subject: [Varnish] #851: bad file descriptor In-Reply-To: <043.c18a6c81c330acd0839d3e63154e1559@varnish-cache.org> References: <043.c18a6c81c330acd0839d3e63154e1559@varnish-cache.org> Message-ID: <052.7d7bf986b7f62276715675c75c632ce1@varnish-cache.org> #851: bad file descriptor ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:58:24 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:58:24 -0000 Subject: [Varnish] #845: Health checks get duplicated when loading a new config In-Reply-To: <044.528c4d3e8335b9cb7d2ad6cb76204380@varnish-cache.org> References: <044.528c4d3e8335b9cb7d2ad6cb76204380@varnish-cache.org> Message-ID: <053.080d4f9a29355e34ef85fb9e767e089d@varnish-cache.org> #845: Health checks get duplicated when loading a new config ------------------------------------+--------------------------------------- Reporter: johnnyh | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: health check duplicate | ------------------------------------+--------------------------------------- Changes (by kristian): * status: new => closed * resolution: => worksforme Comment: As we've got no feedback and believe this is fixed, I'm closing the bug. Feel free to re-open it if this is still an issue in trunk/3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 11:59:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 11:59:25 -0000 Subject: [Varnish] #771: caching large objects In-Reply-To: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> References: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> Message-ID: <053.b88a4dceff6078c467dae1e627258dd7@varnish-cache.org> #771: caching large objects ----------------------+----------------------------------------------------- Reporter: bcakipp | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * owner: phk => kristian * milestone: => Varnish 3.0 dev Old description: > Hi, > > Working with Varnish 2.1.3 on CentOS5. I've noticed child threads dying > with an assertion error when trying to fetch large objets. From what I > can tell, objects with a Content-Length larger then 4GB will cause the > child thread to die. > > For example (file is ~ 6GB). > > {{{ > $ curl http://glint1/aries/75123740001/75123740001_601962598001_ALO- > IPA-083010.mov > -o /dev/null -v -s > * About to connect() to glint1 port 80 > * Trying 192.168.104.211... connected > * Connected to glint1 (192.168.104.211) port 80 > > GET /aries/75123740001/75123740001_601962598001_ALO-IPA-083010.mov > HTTP/1.1 > > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 > OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > > Host: glint1 > > Accept: */* > > > * Empty reply from server > * Connection #0 to host glint1 left intact > * Closing connection #0 > }}} > > Syslog shows: > > {{{ > Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) died signal=6 > Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) Panic message: > Assert error in fetch_straight(), cache_fetch.c line 64: > Condition((uintmax_t)cl == cll) not true. thread = (cache-worker) > ident = Linux,2.6.18-164.15.1.el5xen,x86_64,-sfile,-hcritbit,epoll > Backtrace: 0x422726: /usr/sbin/varnishd [0x422726] 0x41a8f8: > /usr/sbin/varnishd(FetchBody+0x4a8) [0x41a8f8] 0x412960: > /usr/sbin/varnishd [0x412960] 0x413ed5: > /usr/sbin/varnishd(CNT_Session+0x345) [0x413ed5] 0x424b78: > /usr/sbin/varnishd [0x424b78] 0x423e5d: /usr/sbin/varnishd > [0x423e5d] 0x3c9de06617: /lib64/libpthread.so.0 [0x3c9de06617] > 0x3c9d6d3c2d: /lib64/libc.so.6(clone+0x6d) [0x3c9d6d3c2d] sp = > 0x2abe71908008 { fd = 11, id = 11, xid = 674181670, client = > 192.168.103.71:48903, step = STP_FETCH, handling = deliver, > err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = > 0x2abe71908078 { id = "sess", {s,f,r,e} = > {0x2abe71908cd0,+240,(nil),+65536}, }, http[req] = { ws = > 0x2abe71908078[sess] " > }}} > > Looking at that line in cache_fetch.c: > > {{{ > uintmax_t cll; > unsigned cl, sl; > struct storage *st; > > cll = strtoumax(b, NULL, 0); > if (cll == 0) > return (0); > > cl = (unsigned)cll; > assert((uintmax_t)cl == cll); /* Protect against bogusly large > values */ > }}} > > My reading of that says that anything larger then an unsigned int (~4GB) > will cause the client thread to die. > > I understand that it would be possible to just pipe these large files, > but what I would really like to do is cache them in varnish. Is this > possible? New description: Hi, Working with Varnish 2.1.3 on CentOS5. I've noticed child threads dying with an assertion error when trying to fetch large objets. From what I can tell, objects with a Content-Length larger then 4GB will cause the child thread to die. For example (file is ~ 6GB). {{{ $ curl http://glint1/aries/75123740001/75123740001_601962598001_ALO- IPA-083010.mov -o /dev/null -v -s * About to connect() to glint1 port 80 * Trying 192.168.104.211... connected * Connected to glint1 (192.168.104.211) port 80 > GET /aries/75123740001/75123740001_601962598001_ALO-IPA-083010.mov HTTP/1.1 > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: glint1 > Accept: */* > * Empty reply from server * Connection #0 to host glint1 left intact * Closing connection #0 }}} Syslog shows: {{{ Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) died signal=6 Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) Panic message: Assert error in fetch_straight(), cache_fetch.c line 64: Condition((uintmax_t)cl == cll) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5xen,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422726: /usr/sbin/varnishd [0x422726] 0x41a8f8: /usr/sbin/varnishd(FetchBody+0x4a8) [0x41a8f8] 0x412960: /usr/sbin/varnishd [0x412960] 0x413ed5: /usr/sbin/varnishd(CNT_Session+0x345) [0x413ed5] 0x424b78: /usr/sbin/varnishd [0x424b78] 0x423e5d: /usr/sbin/varnishd [0x423e5d] 0x3c9de06617: /lib64/libpthread.so.0 [0x3c9de06617] 0x3c9d6d3c2d: /lib64/libc.so.6(clone+0x6d) [0x3c9d6d3c2d] sp = 0x2abe71908008 { fd = 11, id = 11, xid = 674181670, client = 192.168.103.71:48903, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2abe71908078 { id = "sess", {s,f,r,e} = {0x2abe71908cd0,+240,(nil),+65536}, }, http[req] = { ws = 0x2abe71908078[sess] " }}} Looking at that line in cache_fetch.c: {{{ uintmax_t cll; unsigned cl, sl; struct storage *st; cll = strtoumax(b, NULL, 0); if (cll == 0) return (0); cl = (unsigned)cll; assert((uintmax_t)cl == cll); /* Protect against bogusly large values */ }}} My reading of that says that anything larger then an unsigned int (~4GB) will cause the client thread to die. I understand that it would be possible to just pipe these large files, but what I would really like to do is cache them in varnish. Is this possible? -- Comment: Should be fixed, but I'm confirming this this week. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:07:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:07:05 -0000 Subject: [Varnish] #755: Incorrect escaping of purges In-Reply-To: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> References: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> Message-ID: <054.f192457786a2bb8b52ab80501217a9a5@varnish-cache.org> #755: Incorrect escaping of purges ----------------------+----------------------------------------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * owner: phk => kristian * milestone: => Varnish 3.0 dev Old description: > There's double-escaping going on (I'll track it down when this course is > over) when it comes to purges. Example: > > {{{ > purge req.url ~ "\.css" > 100 85 > Unknown request. > Type 'help' for more info. > Syntax Error: Invalid backslash sequence > > purge req.url ~ "\\.css" > 200 0 > > purge.list > 200 152 > 0x7fa2bd20d9a0 1282146548.428008 0 req.url ~ \.css > 0x7fa2bd20db20 1282145619.939903 1 req.url ~ /two > 0x7fa2bd20d580 1282145596.146903 2G > }}} > > PCRE can take care of \.foo, but Varnish can't. (I already did track this > down, but forgot to report/fix/write it down, so I'm being pre-emptive). New description: There's double-escaping going on (I'll track it down when this course is over) when it comes to purges. Example: {{{ purge req.url ~ "\.css" 100 85 Unknown request. Type 'help' for more info. Syntax Error: Invalid backslash sequence purge req.url ~ "\\.css" 200 0 purge.list 200 152 0x7fa2bd20d9a0 1282146548.428008 0 req.url ~ \.css 0x7fa2bd20db20 1282145619.939903 1 req.url ~ /two 0x7fa2bd20d580 1282145596.146903 2G }}} PCRE can take care of \.foo, but Varnish can't. (I already did track this down, but forgot to report/fix/write it down, so I'm being pre-emptive). -- Comment: Dear Diary, I forgot to update an other bug-report I wrote ages ago. I'm going to verify this, though I do believe it's fixed. (Stealing it). - Kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:08:39 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:08:39 -0000 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request In-Reply-To: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> References: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> Message-ID: <058.07994fd41102abe9ebf0240bef584c20@varnish-cache.org> #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request --------------------------+------------------------------------------------- Reporter: jim.robinson | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: http_range_support byte range set --------------------------+------------------------------------------------- Changes (by kristian): * owner: phk => kristian * component: build => varnishd Comment: I'm checking the fall-back for this mode to assess priority. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:15:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:15:08 -0000 Subject: [Varnish] #829: Varnishstat does not return fields in specified order In-Reply-To: <041.56b7b056ffab1a37386ebe8f2d76baa3@varnish-cache.org> References: <041.56b7b056ffab1a37386ebe8f2d76baa3@varnish-cache.org> Message-ID: <050.433ec41ac64f385afef48aa9ec9db4d8@varnish-cache.org> #829: Varnishstat does not return fields in specified order -------------------------+-------------------------------------------------- Reporter: wido | Owner: martin Type: enhancement | Status: new Priority: low | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by kristian): * priority: normal => low * version: 2.1.4 => trunk Comment: Martin, what's the state of your patche(s) here? Are they worth waiting for? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:16:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:16:43 -0000 Subject: [Varnish] #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing In-Reply-To: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> References: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> Message-ID: <051.7e1c521950698416af061f387692ae52@varnish-cache.org> #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by kristian): * milestone: => Later Old description: > The algorithm implemented in WRK_Queue basically was so far: > > * Choose a worker pool round robin > * Dispatch the request on that pool > * find an idle thread OR > * put the request on a queue OR > * fail of the queue is full (reached ovfl_max) > > This algorithm is probably good enough for many cases, but I noticed that > it can have a negative impact in particular during startup. Threads for > the pools are created sequentially (in wrk_herder_thread), so shortly > after startup, some pools may get hit by requests when they don't have > any threads yet. I noticed this because overflowing pools would trigger > the issue documented in #598. > > Here's a snapshot of this situation in Solaris mdb: > > {{{ > > 0x0000000000464ee0/D > varnishd`nwq: > varnishd`nwq: 4 > > > wq/p > varnishd`wq: > varnishd`wq: 0x483f50 > > ## w'queues > > 0x483f50,4/p > 0x483f50: 0x507160 0x506ed0 0x506f30 0x506f90 > > struct wq { > 82 unsigned magic; > 83 #define WQ_MAGIC 0x606658fa > 84 struct lock mtx; > 85 struct workerhead idle; > 86 VTAILQ_HEAD(, workreq) overflow; > 87 unsigned nthr; > 88 unsigned nqueue; > 89 unsigned lqueue; > 90 uintmax_t ndrop; > 91 uintmax_t noverflow; > 92 }; > > > 0x507160,60::dump -e > 507160: 606658fa 00000000 005359a0 00000000 > 507170: c3c3fe00 fffffd7f f03d0e30 fffffd7f > 507180: 00000000 00000000 00507180 00000000 > 507190: 00000177 00000000 00000000 00000000 177 thr > 5071a0: 00000000 00000000 00000051 00000000 51 overflow > 5071b0: 00507150 00000000 00000000 00000000 > > 0x506ed0,60::dump -e > 506ed0: 606658fa 00000000 005359f0 00000000 > 506ee0: b9d6ee00 fffffd7f c1a38e30 fffffd7f > 506ef0: 00000000 00000000 00506ef0 00000000 > 506f00: 00000050 00000000 00000000 00000000 50 thr > 506f10: 00000000 00000000 000001cf 00000000 1cf noverflow > 506f20: 00000051 00000000 00000000 00000000 > > 0x506f30,60::dump -e > 506f30: 606658fa 00000000 00535a40 00000000 > 506f40: 00000000 00000000 00506f40 00000000 > 506f50: 007b65e8 00000000 0292e778 00000000 > 506f60: 00000000 00000201 00000000 00000000 0 thr 201 > nqueue > 506f70: 00000001 00000000 00000201 00000000 1 drop 201 > noverflow > 506f80: 00000061 00000000 00000000 00000000 > > 0x506f90,60::dump -e > 506f90: 606658fa 00000000 00535a90 00000000 > 506fa0: 00000000 00000000 00506fa0 00000000 > 506fb0: 007baf08 00000000 0285e218 00000000 > 506fc0: 00000000 00000201 00000000 00000000 0 thr 201 > nqueue > 506fd0: 00000000 00000000 00000201 00000000 201 > noverflow > 506fe0: 00506f80 00000000 00000000 00000000 > }}} > > Notice that {{{wq[2]}}} and {{{wq[3]}}} have their nqueues saturated and > no idle threads while {{{wq[0]}}} and {{{wq[1]}}} probably have idle > threads by now. > > I am suggesting the following changes to WRK_Queue: > > * Improve the round-robin selection on MP systems by using a volatile > static (still avoiding additional locking overhead for the round robin > state) > * First check all pools for idle threads (starting with the pool > selected by round-robin to remain in O(1) for the normal case) > * Only queue a request if there exists no pool with idle threads, and > queue where the queue is shortest > * Fail only if all queues are full > > I'll attach a diff with my suggested solution. New description: The algorithm implemented in WRK_Queue basically was so far: * Choose a worker pool round robin * Dispatch the request on that pool * find an idle thread OR * put the request on a queue OR * fail of the queue is full (reached ovfl_max) This algorithm is probably good enough for many cases, but I noticed that it can have a negative impact in particular during startup. Threads for the pools are created sequentially (in wrk_herder_thread), so shortly after startup, some pools may get hit by requests when they don't have any threads yet. I noticed this because overflowing pools would trigger the issue documented in #598. Here's a snapshot of this situation in Solaris mdb: {{{ > 0x0000000000464ee0/D varnishd`nwq: varnishd`nwq: 4 > wq/p varnishd`wq: varnishd`wq: 0x483f50 ## w'queues > 0x483f50,4/p 0x483f50: 0x507160 0x506ed0 0x506f30 0x506f90 struct wq { 82 unsigned magic; 83 #define WQ_MAGIC 0x606658fa 84 struct lock mtx; 85 struct workerhead idle; 86 VTAILQ_HEAD(, workreq) overflow; 87 unsigned nthr; 88 unsigned nqueue; 89 unsigned lqueue; 90 uintmax_t ndrop; 91 uintmax_t noverflow; 92 }; > 0x507160,60::dump -e 507160: 606658fa 00000000 005359a0 00000000 507170: c3c3fe00 fffffd7f f03d0e30 fffffd7f 507180: 00000000 00000000 00507180 00000000 507190: 00000177 00000000 00000000 00000000 177 thr 5071a0: 00000000 00000000 00000051 00000000 51 overflow 5071b0: 00507150 00000000 00000000 00000000 > 0x506ed0,60::dump -e 506ed0: 606658fa 00000000 005359f0 00000000 506ee0: b9d6ee00 fffffd7f c1a38e30 fffffd7f 506ef0: 00000000 00000000 00506ef0 00000000 506f00: 00000050 00000000 00000000 00000000 50 thr 506f10: 00000000 00000000 000001cf 00000000 1cf noverflow 506f20: 00000051 00000000 00000000 00000000 > 0x506f30,60::dump -e 506f30: 606658fa 00000000 00535a40 00000000 506f40: 00000000 00000000 00506f40 00000000 506f50: 007b65e8 00000000 0292e778 00000000 506f60: 00000000 00000201 00000000 00000000 0 thr 201 nqueue 506f70: 00000001 00000000 00000201 00000000 1 drop 201 noverflow 506f80: 00000061 00000000 00000000 00000000 > 0x506f90,60::dump -e 506f90: 606658fa 00000000 00535a90 00000000 506fa0: 00000000 00000000 00506fa0 00000000 506fb0: 007baf08 00000000 0285e218 00000000 506fc0: 00000000 00000201 00000000 00000000 0 thr 201 nqueue 506fd0: 00000000 00000000 00000201 00000000 201 noverflow 506fe0: 00506f80 00000000 00000000 00000000 }}} Notice that {{{wq[2]}}} and {{{wq[3]}}} have their nqueues saturated and no idle threads while {{{wq[0]}}} and {{{wq[1]}}} probably have idle threads by now. I am suggesting the following changes to WRK_Queue: * Improve the round-robin selection on MP systems by using a volatile static (still avoiding additional locking overhead for the round robin state) * First check all pools for idle threads (starting with the pool selected by round-robin to remain in O(1) for the normal case) * Only queue a request if there exists no pool with idle threads, and queue where the queue is shortest * Fail only if all queues are full I'll attach a diff with my suggested solution. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:21:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:21:48 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <044.0ab34fea791f1245ab0db53b04425d49@varnish-cache.org> References: <044.0ab34fea791f1245ab0db53b04425d49@varnish-cache.org> Message-ID: <053.f38ab3e16448b428d49f5e70056e9912@varnish-cache.org> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------+-------------------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: busy threads monitoring -------------------------+-------------------------------------------------- Changes (by kristian): * version: 2.0 => trunk * milestone: => Varnish 3.0 dev Old description: > Hi! > > I made this patch for implementing a new varnishstat variable, called > 'n_wrk_busy'. > > With this new variable we can now know for sure how many of our active > threads are actually doing something, so the system can be better > dimensioned in order to know if we are getting near the max threads > utilization: if we are, we can increase the number of max threads in > order to instatiate more, if the system can handle more threads, if not, > go for more hardware. > > This is good in the cases when we configure thread_pool_min == > thread_pool_max and do not have to know how many of the threads are > actually used for something. > I believe the same applies when we have thread_pool_min == 1 and > thread_pool_max == MAX_WISHED. In this case we can know how many threads > are idle (waiting for thread_pool_timeout to expire) and how many are > actually working. > > This is good for monitoring and I hope this can help someone else to know > what is happening under the hood a little better. > > Best regards, > > Rog?rio Schneider New description: Hi! I made this patch for implementing a new varnishstat variable, called 'n_wrk_busy'. With this new variable we can now know for sure how many of our active threads are actually doing something, so the system can be better dimensioned in order to know if we are getting near the max threads utilization: if we are, we can increase the number of max threads in order to instatiate more, if the system can handle more threads, if not, go for more hardware. This is good in the cases when we configure thread_pool_min == thread_pool_max and do not have to know how many of the threads are actually used for something. I believe the same applies when we have thread_pool_min == 1 and thread_pool_max == MAX_WISHED. In this case we can know how many threads are idle (waiting for thread_pool_timeout to expire) and how many are actually working. This is good for monitoring and I hope this can help someone else to know what is happening under the hood a little better. Best regards, Rog?rio Schneider -- Comment: This ties in with proposed scoreboard-functionality, but is not going to make it for 3.0. Sorry for the horrendous response-time.... Ugh. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:21:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:21:56 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <044.0ab34fea791f1245ab0db53b04425d49@varnish-cache.org> References: <044.0ab34fea791f1245ab0db53b04425d49@varnish-cache.org> Message-ID: <053.526c43b6bd4a02853f3c9d3602684ba7@varnish-cache.org> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------+-------------------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: busy threads monitoring -------------------------+-------------------------------------------------- Changes (by kristian): * milestone: Varnish 3.0 dev => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:24:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:24:07 -0000 Subject: [Varnish] #792: Bandwidth management / rate-limiting In-Reply-To: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> References: <045.471ad86ca05d5fe7c0d0b3b55d3daa42@varnish-cache.org> Message-ID: <054.30da2d3c89bd0c3f33f5d3403cd9ace4@varnish-cache.org> #792: Bandwidth management / rate-limiting -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: bandwidth rate-limit -------------------------+-------------------------------------------------- Changes (by kristian): * milestone: => Later Old description: > Hi, > > Here is a patch to allow for rate-limiting on specific objects / url / > etc. It uses vmod and looks like this in the VCL : > > {{{ > sub vcl_recv { > if ( req.url ~ "^/bigone.ts$" ) { > std.set_bandwidth(20000); > } > } > }}} > > This will limit the delivery at 20000 bytes/sec. > > The idea behind this (eh, who would like to slow down delivery with a > web-accelerator ?) is the following : mobile users watching a video > usually watch the first N seconds and stop. But as they start watching, > the device downloads at full speed in order to fill up its cache. The > result is that a lot of downloaded data are never used, so why wouldn't > we limit the download rate to the rate at which the video is encoded ? > This allows to decrease the overall data transfer, which is not a bad > idea on mobile networks. > > Note that this is just a "testcase" patch : the "sleep(1)" would better > be something more precise but that's the main idea. > > All remarks welcome. > > Thanks, > > Thierry New description: Hi, Here is a patch to allow for rate-limiting on specific objects / url / etc. It uses vmod and looks like this in the VCL : {{{ sub vcl_recv { if ( req.url ~ "^/bigone.ts$" ) { std.set_bandwidth(20000); } } }}} This will limit the delivery at 20000 bytes/sec. The idea behind this (eh, who would like to slow down delivery with a web- accelerator ?) is the following : mobile users watching a video usually watch the first N seconds and stop. But as they start watching, the device downloads at full speed in order to fill up its cache. The result is that a lot of downloaded data are never used, so why wouldn't we limit the download rate to the rate at which the video is encoded ? This allows to decrease the overall data transfer, which is not a bad idea on mobile networks. Note that this is just a "testcase" patch : the "sleep(1)" would better be something more precise but that's the main idea. All remarks welcome. Thanks, Thierry -- Comment: Sorry for the response-time. We've discussed this back and forth several times, but apparently never got back to you, please accept our apologies. It doesn't look like we'll add this for Varnish 3.0, and given the nature of vmods, it might be a more suitable place in the future, but for now, I'm just moving this to 'later'. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:25:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:25:54 -0000 Subject: [Varnish] #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog In-Reply-To: <041.0ef4db3d1a46a6fc440b20be57e03e2b@varnish-cache.org> References: <041.0ef4db3d1a46a6fc440b20be57e03e2b@varnish-cache.org> Message-ID: <050.e9a7df7daad060c1542801008952ff17@varnish-cache.org> #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog -------------------------+-------------------------------------------------- Reporter: wido | Owner: martin Type: enhancement | Status: new Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Keywords: init,ubuntu,debian -------------------------+-------------------------------------------------- Changes (by kristian): * component: varnishlog => packaging * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:26:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:26:06 -0000 Subject: [Varnish] #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa In-Reply-To: <041.7843c50b5ad30c900a44261949fc2998@varnish-cache.org> References: <041.7843c50b5ad30c900a44261949fc2998@varnish-cache.org> Message-ID: <050.5726146a189f3a4609b5103ead5a7998@varnish-cache.org> #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa -------------------------+-------------------------------------------------- Reporter: wido | Owner: martin Type: enhancement | Status: new Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by kristian): * component: varnishncsa => packaging * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:26:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:26:35 -0000 Subject: [Varnish] #838: file backend storage file should be removed at package upgrade In-Reply-To: <043.0a5310132f8efd5e6fb2a78ef728781f@varnish-cache.org> References: <043.0a5310132f8efd5e6fb2a78ef728781f@varnish-cache.org> Message-ID: <052.390360fac808cf885cd33a6214a7b55b@varnish-cache.org> #838: file backend storage file should be removed at package upgrade -----------------------+---------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Later Component: packaging | Version: trunk Severity: normal | Keywords: -----------------------+---------------------------------------------------- Changes (by kristian): * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:27:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:27:29 -0000 Subject: [Varnish] #814: yum installation error "[Errno -1] Header is not complete." In-Reply-To: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> References: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> Message-ID: <060.13ca13e2b00a9f58986cc29c15f574bb@varnish-cache.org> #814: yum installation error "[Errno -1] Header is not complete." -----------------------------+---------------------------------------------- Reporter: patrick.kaiser | Type: defect Status: closed | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: normal Resolution: worksforme | Keywords: -----------------------------+---------------------------------------------- Changes (by kristian): * status: reopened => closed * resolution: => worksforme Comment: No feedback, so closing, but feel free to re-open if the error persists. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:28:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:28:20 -0000 Subject: [Varnish] #854: patch: extra features for the varnish initrc script In-Reply-To: <046.bcb4bdb8297b12f012b4621c408f2685@varnish-cache.org> References: <046.bcb4bdb8297b12f012b4621c408f2685@varnish-cache.org> Message-ID: <055.41196dd85caa7f0bdaf31522766e1e30@varnish-cache.org> #854: patch: extra features for the varnish initrc script ----------------------------------------+----------------------------------- Reporter: jhalfmoon | Type: enhancement Status: new | Priority: low Milestone: Later | Component: packaging Version: trunk | Severity: trivial Keywords: initrc patch extra feature | ----------------------------------------+----------------------------------- Changes (by kristian): * component: build => packaging * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:28:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:28:53 -0000 Subject: [Varnish] #837: varnishadm purge.list fails frequently In-Reply-To: <043.a2d15772321998574922abae75b7be94@varnish-cache.org> References: <043.a2d15772321998574922abae75b7be94@varnish-cache.org> Message-ID: <052.355e63370801f1bd48a2511c214cbd85@varnish-cache.org> #837: varnishadm purge.list fails frequently ----------------------+----------------------------------------------------- Reporter: jelder | Owner: Type: defect | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Keywords: purge.list ----------------------+----------------------------------------------------- Changes (by kristian): * milestone: After Varnish 2.1 => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:36:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:36:52 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.5eae54e76392fc29203dd5b2a0d22aaf@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 -----------------------------+---------------------------------------------- Reporter: miohtama | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: 2.1.4 | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Changes (by kristian): * severity: minor => normal * milestone: => Varnish 3.0 dev Comment: Marking for 3.0. We should assess the implications of this issue before 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:38:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:38:47 -0000 Subject: [Varnish] #839: Varnish fails to start on boot for some FreeBSD machines In-Reply-To: <054.631b323b9c05fe09e2b12eed8c556e4e@varnish-cache.org> References: <054.631b323b9c05fe09e2b12eed8c556e4e@varnish-cache.org> Message-ID: <063.7a46c6c1f4e7ff7a6dbbbc147406dd09@varnish-cache.org> #839: Varnish fails to start on boot for some FreeBSD machines -------------------------------+-------------------------------------------- Reporter: james.m.henderson | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Later Component: packaging | Version: trunk Severity: normal | Keywords: -------------------------------+-------------------------------------------- Changes (by kristian): * component: varnishd => packaging * milestone: => Later Comment: No feedback, but regardless, this seems like a packaging/init-issue, and as such, not really a blocker for 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:43:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:43:01 -0000 Subject: [Varnish] #805: Negative ReqEnd accept time (ESI enabled) and hanging request In-Reply-To: <043.a1d082f96df5a220dbf6111b921708bb@varnish-cache.org> References: <043.a1d082f96df5a220dbf6111b921708bb@varnish-cache.org> Message-ID: <052.105fb6f345d1c951d8a2709e9bd57a13@varnish-cache.org> #805: Negative ReqEnd accept time (ESI enabled) and hanging request ----------------------+----------------------------------------------------- Reporter: tesdal | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * version: 2.1.3 => trunk * milestone: => Varnish 3.0 dev Comment: Quote: 13:37:27 < phk> Mithrandir, I just need to test and if still buggy, fix. So, might work, might not. Should be addressed before 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:44:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:44:08 -0000 Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> Message-ID: <053.3303b7c55466bfc070a3e5bf281fa0bd@varnish-cache.org> #864: Varnishlog crashes when searching for 503 errors ------------------------+--------------------------------------------------- Reporter: kriller | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishlog | Version: 2.1.5 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Changes (by kristian): * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:45:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:45:12 -0000 Subject: [Varnish] #849: Session timeout while receiving POST data from client causes multiple broken backend requests In-Reply-To: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org> References: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org> Message-ID: <049.1662ec3aacc9ab3230dff0ddd3220e39@varnish-cache.org> #849: Session timeout while receiving POST data from client causes multiple broken backend requests ----------------------+----------------------------------------------------- Reporter: lew | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: 503, post, backend write error: 11 (Resource temporarily unavailable) ----------------------+----------------------------------------------------- Changes (by kristian): * owner: => kristian * milestone: => Varnish 3.0 dev Comment: I'm testing and assessing impact for 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:46:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:46:05 -0000 Subject: [Varnish] #853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test in configure.ac In-Reply-To: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org> References: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org> Message-ID: <051.90771d6039ceefa8cb2e5e2296d7ac07@varnish-cache.org> #853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test in configure.ac -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: enhancement | Status: new Priority: low | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- Changes (by kristian): * milestone: => Varnish 3.0 dev -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:47:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:47:18 -0000 Subject: [Varnish] #825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES In-Reply-To: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org> References: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org> Message-ID: <049.d7f7f8bb92e3d1a5891fdc1f79eea160@varnish-cache.org> #825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES --------------------------------+------------------------------------------- Reporter: pom | Type: defect Status: new | Priority: normal Milestone: Later | Component: packaging Version: trunk | Severity: minor Keywords: rpmbuild SUSE SLES | --------------------------------+------------------------------------------- Changes (by kristian): * version: 2.1.3 => trunk * component: build => packaging * milestone: After Varnish 2.1 => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:49:03 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:49:03 -0000 Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org> Message-ID: <053.2157f55706bac8c1e2205bc941cb4630@varnish-cache.org> #864: Varnishlog crashes when searching for 503 errors ------------------------+--------------------------------------------------- Reporter: kriller | Owner: Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishlog | Version: 2.1.5 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Changes (by kristian): * owner: kristian => * status: assigned => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:50:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:50:10 -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.76593860b3ae55656d9a087e42c78988@varnish-cache.org> #666: pmatch: regular expression subexpression references ----------------------------------------------------------+----------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: pmatch, match, subexpression, back reference | ----------------------------------------------------------+----------------- Changes (by kristian): * status: new => closed * resolution: => invalid Old description: > == 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). New description: == 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). -- Comment: I'm phk of the day! I get to close it. Yai! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:55:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:55:37 -0000 Subject: [Varnish] #827: varnish child died in object_cmp In-Reply-To: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> References: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> Message-ID: <052.1fdd27f45618b346ea759c2c52385567@varnish-cache.org> #827: varnish child died in object_cmp ----------------------+----------------------------------------------------- Reporter: dmyaho | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: Assert error ----------------------+----------------------------------------------------- Changes (by kristian): * owner: phk => kristian * priority: high => normal * severity: major => normal * milestone: Varnish 2.1 release => Varnish 3.0 dev Comment: Can you try either 2.1.5 or git master? And what params are you using? (And why are you on 32-bit....) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 12:56:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:56:38 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux In-Reply-To: <043.d5f8ad4b2261de27db3676c54dc9fe24@varnish-cache.org> References: <043.d5f8ad4b2261de27db3676c54dc9fe24@varnish-cache.org> Message-ID: <052.f39247a00cf2b7d34958d86ec11478af@varnish-cache.org> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: martin Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => wontfix Old description: > This patch enables block devices to be opened withe the file storage > option on Linux. It is not 100% tested, so no guarantees. To use a block > device as storage, use the option -s file,/dev/somedevice,100% > > You must add "100%", otherwise only 50% will be used, and emember to > ABSOLUTELY sure you have selected the right device, otherwise you WILL > loose data. > > This patch is for r3197 of storage_file.c New description: This patch enables block devices to be opened withe the file storage option on Linux. It is not 100% tested, so no guarantees. To use a block device as storage, use the option -s file,/dev/somedevice,100% You must add "100%", otherwise only 50% will be used, and emember to ABSOLUTELY sure you have selected the right device, otherwise you WILL loose data. This patch is for r3197 of storage_file.c -- Comment: This has been invalidated by time. If time turns back, re-opening makes sense. Apologies for the somewhat dismissive treatment of this patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From MAILER-DAEMON at linpro.no Mon Mar 7 12:56:40 2011 From: MAILER-DAEMON at linpro.no (Mail Delivery System) Date: Mon, 7 Mar 2011 13:56:40 +0100 (CET) Subject: Undelivered Mail Returned to Sender Message-ID: <20110307125640.538FAC3AFA@mailhub.linpro.no> This is the mail system at host mailhub.linpro.no. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system (expanded from ): host zimbra.redpill-linpro.com[87.238.49.234] said: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command) -------------- next part -------------- An embedded message was scrubbed... From: "Varnish" Subject: Re: [Varnish] #322: PATCH: Enable mmap of devices if running Linux Date: Mon, 07 Mar 2011 12:56:38 -0000 Size: 4199 URL: From varnish-bugs at varnish-cache.org Mon Mar 7 12:58:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 12:58:57 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <040.75b83f2a5390779c25adf146cd0b53d5@varnish-cache.org> References: <040.75b83f2a5390779c25adf146cd0b53d5@varnish-cache.org> Message-ID: <049.41ae7ce180c75b23d4de0955ca85883c@varnish-cache.org> #310: WS_Reserve panic + error ----------------------+----------------------------------------------------- Reporter: sky | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * status: assigned => closed * resolution: => fixed Comment: Aaaand closing again. The bug is long since fixed, and we are now working mainly on 3.0, where it's been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 13:01:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 13:01:43 -0000 Subject: [Varnish] #848: varnishlog -r seems broken In-Reply-To: <042.f4d125bf7db6e317d56c6e53ae887681@varnish-cache.org> References: <042.f4d125bf7db6e317d56c6e53ae887681@varnish-cache.org> Message-ID: <051.2e8ced51c0cfd43055970e7f07320d34@varnish-cache.org> #848: varnishlog -r seems broken ------------------------+--------------------------------------------------- Reporter: perbu | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishlog | Version: trunk Severity: normal | Keywords: varnishlog ------------------------+--------------------------------------------------- Changes (by kristian): * owner: => kristian * component: build => varnishlog Comment: Can you mail it to me if you still have it (the log)? See also #864 which ties in to this... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 13:03:40 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 13:03:40 -0000 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request In-Reply-To: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> References: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> Message-ID: <058.135b9394c90069d3fe16e5802be13527@varnish-cache.org> #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request --------------------------+------------------------------------------------- Reporter: jim.robinson | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: http_range_support byte range set --------------------------+------------------------------------------------- Changes (by kristian): * milestone: => Varnish 3.0 dev Comment: Need to assess this before 3.0. Sorry for the spam. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 13:07:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 13:07:26 -0000 Subject: [Varnish] #829: Varnishstat does not return fields in specified order In-Reply-To: <041.56b7b056ffab1a37386ebe8f2d76baa3@varnish-cache.org> References: <041.56b7b056ffab1a37386ebe8f2d76baa3@varnish-cache.org> Message-ID: <050.8be568bbc560bef9940c53eb85a0adc4@varnish-cache.org> #829: Varnishstat does not return fields in specified order -------------------------+-------------------------------------------------- Reporter: wido | Owner: martin Type: enhancement | Status: new Priority: low | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by martin): The patches are done - but the ideas from PHKs feedback has not been incorporated. I think this should still be done - I'll get around to it eventually. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 13:14:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 13:14:29 -0000 Subject: [Varnish] #823: Ability to determine number of healthy backends from varnishstat In-Reply-To: <042.95f938109ab74caae44fa84d51715c76@varnish-cache.org> References: <042.95f938109ab74caae44fa84d51715c76@varnish-cache.org> Message-ID: <051.d829a5fc478acfe74ba382eab7b23bb7@varnish-cache.org> #823: Ability to determine number of healthy backends from varnishstat -------------------------+-------------------------------------------------- Reporter: glenk | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Later Component: varnishstat | Version: trunk Severity: normal | Keywords: varnishstat healthy backends -------------------------+-------------------------------------------------- Changes (by kristian): * milestone: Varnish 2.1 release => Later Comment: This is the sort of question that dynamic counters are supposed to answer, but it probably wont hit before 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 15:42:39 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 15:42:39 -0000 Subject: [Varnish] #827: varnish child died in object_cmp In-Reply-To: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> References: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> Message-ID: <052.4810ebc828b0d198812c15d271efbcc9@varnish-cache.org> #827: varnish child died in object_cmp ----------------------+----------------------------------------------------- Reporter: dmyaho | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: Assert error ----------------------+----------------------------------------------------- Comment(by dmyaho): Can you try either 2.1.5 or git master? Unfortunatelly we are not able to switch to different Varnish version until later this year. And what params are you using? [dal-lightweb-1 ~]$ ps -ef | grep varnish root 3032 1 0 Feb22 ? 00:00:00 /usr/local/sbin/varnishd -P /d/varnish/varnish.pid -a 198.31.208.121:80 -T localhost:2000 -f /d/varnish/default.vcl -n /d/varnish -u root -g root -t 120 -s malloc,1G root 19056 3032 0 Feb25 ? 00:14:16 /usr/local/sbin/varnishd -P /d/varnish/varnish.pid -a 198.31.208.121:80 -T localhost:2000 -f /d/varnish/default.vcl -n /d/varnish -u root -g root -t 120 -s malloc,1G And why are you on 32-bit.... tight budget! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 7 22:35:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Mar 2011 22:35:55 -0000 Subject: [Varnish] #866: Multiple headers with the same name on different lines are ignored Message-ID: <043.0782868cc9b22614fe1a45478fa6bb30@varnish-cache.org> #866: Multiple headers with the same name on different lines are ignored -----------------------------------------------------------------+---------- Reporter: soheil | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: trunk | Severity: major Keywords: multiple headers, same headers, VRT_GetHdr, headers | -----------------------------------------------------------------+---------- If incoming request contains duplicate headers with different content only the first one is accessible to varnish req.http.X-Forwarded-For and similarly in C: char *xForwarded = VRT_GetHdr(sp, HDR_REQ, "\020X- Forwarded-For:"); returns only the first occurrence of the specified header. A concatenated list of values would seem to be most logical. For example if geo-targeting needed to be done in varnish based on client's IP address. This would be useful when a load balancer sends multiple X-Forwarded-For headers for a request to varnish and only one of those values is the IP address of the client. An over-generalization in RFC2616, is that headers which contain comma- separated lists, can be spread over multiple header lines. This is related to but not the same as: http://varnish- cache.org/trac/ticket/686 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 8 06:02:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Mar 2011 06:02:26 -0000 Subject: [Varnish] #867: typo in vcl tutorial Message-ID: <045.0b41cbb5a8ce2f91bbdba2c062406f35@varnish-cache.org> #867: typo in vcl tutorial ----------------------+----------------------------------------------------- Reporter: askalski | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: 2.1.5 | Severity: trivial Keywords: | ----------------------+----------------------------------------------------- Example 2 in the VCL tutorial gives a syntax error on "set beresp.ttl = 3600;" (It's looking for "... 3600s;") {{{ diff --git a/doc/sphinx/tutorial/vcl.rst b/doc/sphinx/tutorial/vcl.rst index 7e5d4aa..ccf43d2 100644 --- a/doc/sphinx/tutorial/vcl.rst +++ b/doc/sphinx/tutorial/vcl.rst @@ -154,7 +154,7 @@ matches certain criteria::: sub vcl_fetch { if (req.url ~ "\.(png|gif|jpg)$") { unset beresp.http.set-cookie; - set beresp.ttl = 3600; + set beresp.ttl = 1h; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 8 09:53:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Mar 2011 09:53:06 -0000 Subject: [Varnish] #853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test in configure.ac In-Reply-To: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org> References: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org> Message-ID: <051.6aa622bfc50a81bcf02520e03b77abb0@varnish-cache.org> #853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test in configure.ac -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: enhancement | Status: closed Priority: low | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: minor | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [ab70df53d69d3f89653321f66218e6c8283e7212]) Fix typo I forgot to rename the tv_get variable to tv in configure.ac Fixes #853 (again) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 8 11:56:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Mar 2011 11:56:52 -0000 Subject: [Varnish] #867: typo in vcl tutorial In-Reply-To: <045.0b41cbb5a8ce2f91bbdba2c062406f35@varnish-cache.org> References: <045.0b41cbb5a8ce2f91bbdba2c062406f35@varnish-cache.org> Message-ID: <054.df71d9687cb98e1190038ae3f49f9038@varnish-cache.org> #867: typo in vcl tutorial -----------------------+---------------------------------------------------- Reporter: askalski | Type: documentation Status: closed | Priority: normal Milestone: | Component: documentation Version: 2.1.5 | Severity: trivial Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by Kristian Lyngstol ): * status: new => closed * resolution: => fixed Comment: (In [cb86f7eff6a85d61b7efb8d5767345004d2fc582]) doc: Change 3600 to 1h Thanks to askalski. closes #867 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 8 21:20:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Mar 2011 21:20:05 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.fdfdb73c7c74fbeaac393cca17a98600@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 -----------------------------+---------------------------------------------- Reporter: miohtama | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: 2.1.4 | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Comment(by kb): FWIW, we've been running Varnish in production on 8.04 LTS since 2009 without issue. Have you tried building/running Varnish on a fresh install of 8.04? Also, you might try using Google's tcmalloc via a simple LD_PRELOAD. I did this during initial testing and it was essentially a wash between it and jemalloc (so we stuck with jemalloc). kb -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 9 14:25:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Mar 2011 14:25:45 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.d9baa071c216b9852f7a35683efaa7d8@varnish-cache.org> #784: Varnish crash at HSH_Lookup() --------------------------------------+------------------------------------- Reporter: censored | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishd HSH_Lookup died | --------------------------------------+------------------------------------- Changes (by perbu): * status: new => closed * resolution: => fixed Comment: Ok. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 10 09:42:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Mar 2011 09:42:25 -0000 Subject: [Varnish] #727: Tiny Patch: Human readable nagios output In-Reply-To: <043.c3df909e2981935706b069f554e595ef@varnish-cache.org> References: <043.c3df909e2981935706b069f554e595ef@varnish-cache.org> Message-ID: <052.d9d427ce6b0f96a5bb3f81f5d7df078b@varnish-cache.org> #727: Tiny Patch: Human readable nagios output -------------------------+-------------------------------------------------- Reporter: sascha | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen Old description: > as mentioned in #710, I suggest a little change to make big number easier > readable: > > {{{ > ~/varnish-svn-trunk/varnish-tools/nagios# svn diff > Index: check_varnish.c > =================================================================== > --- check_varnish.c (revision 4936) > +++ check_varnish.c (working copy) > @@ -31,6 +31,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -200,7 +201,8 @@ > printf("Unknown parameter '%s'\n", param); > > status = check_thresholds(value); > - printf("VARNISH %s: %s|%s=%jd\n", status_text[status], info, > param, value); > + setlocale(LC_ALL, ""); > + printf("VARNISH %s: %s (%'jd)|%s=%jd\n", status_text[status], > info, value, param, value); > exit(status); > } > > }}} > > Cheers > > Sascha New description: as mentioned in #710, I suggest a little change to make big number easier readable: {{{ ~/varnish-svn-trunk/varnish-tools/nagios# svn diff Index: check_varnish.c =================================================================== --- check_varnish.c (revision 4936) +++ check_varnish.c (working copy) @@ -31,6 +31,7 @@ */ #include +#include #include #include #include @@ -200,7 +201,8 @@ printf("Unknown parameter '%s'\n", param); status = check_thresholds(value); - printf("VARNISH %s: %s|%s=%jd\n", status_text[status], info, param, value); + setlocale(LC_ALL, ""); + printf("VARNISH %s: %s (%'jd)|%s=%jd\n", status_text[status], info, value, param, value); exit(status); } }}} Cheers Sascha -- Comment: This was fixed in https://github.com/varnish/varnish- nagios/commit/cd477fe0384a162c2fc9e06ae441b3908ca1afaa -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 10 17:32:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Mar 2011 17:32:47 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty Message-ID: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: varnishncsa | -------------------------+-------------------------------------------------- varnishncsa generates wrong log formats when "Authorization" header is sent, but with empty value: * Authorization: Basic instead: * Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== The generated log lacks third field (user) when Authorization is empty. This line causes problems in Awstats and Webalizer programs that process NCSA format logs. The following request: {{{ Accept: */* Accept-Language: es,en;q=0.5 UA-CPU: x86 Accept-Encoding: gzip, deflate If-Modified-Since: Thu, 10 Mar 2011 15:43:02 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Proxy-Connection: Keep-Alive Host: localhost:7000 Pragma: no-cache Authorization: Basic }}} Generates: 1) varnishncsa generates following incorrect log, without user field: {{{ 10.0.0.1 - [10/Mar/2011:17:55:48 +0100] "GET / HTTP/1.1" 301 198 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" }}} 2) apache generates following valid log: {{{ 10.0.0.1 - - [10/Mar/2011:17:58:16 +0100] "GET / HTTP/1.1" 301 198 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" }}} The lack of one "-" makes Awstats to stop processing and start complaining about this line. The problem is at [http://www.varnish- cache.org/trac/browser/bin/varnishncsa/varnishncsa.c varnishncsa.c] at lines 618-637. A previous check of string length must be done: {{{ if (lp->df_u != NULL) { char *rubuf; size_t rulen; base64_init(); rulen = ((strlen(lp->df_u) + 3) * 4) / 3; rubuf = malloc(rulen); assert(rubuf != NULL); base64_decode(rubuf, rulen, lp->df_u); q = strchr(rubuf, ':'); if (q != NULL) *q = '\0'; /* START - FIX */ if(strlen(rubuf)>0) { fprintf(fo, "%s", rubuf); } else { fprintf(fo, "-"); } /* END - FIX */ free(rubuf); } else { fprintf(fo, "-"); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 10 23:27:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Mar 2011 23:27:14 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.6aa85194010c738580d89c31006fa520@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Changes (by jbarbuto): * status: closed => reopened * resolution: worksforme => Comment: Please consider the documentation update suggested above, to make clear the purpose of the send_timeout option. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Mar 12 19:35:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Mar 2011 19:35:13 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() Message-ID: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Google-bot came along and tried to fetch cache_esi_deliver, through Varnish with ESI processing. Oh, the irony. We might want to warn people about ESI-processing the Varnish Source code. :) Per. Mar 12 17:17:36 odd varnishd[10810]: Child (10811) said INFLATE=-3 (invalid stored block lengths) Mar 12 17:17:36 odd varnishd[10810]: Child (10811) died signal=6 Mar 12 17:17:36 odd varnishd[10810]: Child (10811) Panic message: Assert error in ESI_Deliver(), cache_esi_deliver.c line 354: #012 Condition(i == Z_OK || i == Z_STREAM_END) not true. #012thread = (cache-worker)#012ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll #012Backtrace: #012 0x42c938: pan_ic+b8#012 0x41f558: ESI_Deliver+438 #012 0x42f588: RES_WriteObj+248 #012 0x4169b0: cnt_deliver+230#012 0x41783d: CNT_Session+31d #012 0x42e0f8: wrk_do_cnt_sess+b8#012 0x42e579: wrk_thread_real+409 #012 0x7ff04d4759ca: _end+7ff04cdfe7f2 #012 0x7ff04d1d270d: _end+7ff04cb5b535 #012sp = 0x7feffcc8a008 { #012 fd = 15, id = 15, xid = 266236633, #012 client = XX.249.66.180 36079, #012 step = STP_DELIVER, #012 handling = deliver, #012 restarts = 0, esi_level = 0 #012 ws = 0x7feffcc8a080 { #012 id = "sess", #012 {s,f,r,e} = {0x7feffcc8acf0,+472,(nil),+65536}, #012 }, #012 http[req] = { #012 ws = 0x7feffcc8a080[sess] #012 "GET", #012 "/trac/browser/bin/varnishd/cache_esi.c?annotate=blame&rev=3026e9ad36cc519bb8b19ad7e905f69f1eb66954", #012 "HTTP/1.1", #012 "Host: www.varnish-cache.org", #012 "Connection: Keep-alive", #012 "Accept: */*", #012 "From: googlebot(at)googlebot.com", #012 "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", #012 "X-Forwarded-For: 66.249.66.180, 66.249.66.180", #012 }, #012 worker = 0x7fefff1eeb80 { #012 ws = 0x7fefff1eed10 { #012 id = "wrk", #012 {s,f,r,e} = {0x7fefff1dcb10,+144,(nil),+65536}, #012 }, #012 http[resp] = { #012 ws = 0x7fefff1eed10[wrk]#012 "HTTP/1.1", #012 "200",#012 "Ok", #012 "Server: Apache/2.2.14 (Ubuntu)", #012 "Cache-Control: must-revalidate", #012 "Vary: Accept-Encoding", #012 "Content-Type: text/html;charset=utf-8", #012 "Transfer-Encoding: chunked", #012 "Date: Sat, 12 Mar 2011 16:17:36 GMT", #012 "X-Varnish: 266236633 266236629", #012 "Age: 0", #012 "Via: 1.1 varnish", #012 "Connectio Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete Mar 12 17:17:36 odd varnishd[10810]: child (21915) Started Mar 12 17:17:36 odd varnishd[10810]: Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object file: No such file or directory Mar 12 17:17:36 odd varnishd[10810]: Stopping Child Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child starts Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child dies Mar 12 17:17:36 odd varnishd[10810]: Child (21915) died Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 16:03:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 16:03:52 -0000 Subject: [Varnish] #870: Assert error in VEP_Finish(), Message-ID: <042.0e194f03b53aafb561dc260e5abc6da6@varnish-cache.org> #870: Assert error in VEP_Finish(), --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Mar 13 06:27:24 odd varnishd[22232]: Child (31305) died signal=6 Mar 13 06:27:24 odd varnishd[22232]: Child (31305) Panic message: Assert error in VEP_Finish(), cache_esi_parse.c line 1038: Condition((vep) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42c938: pan_ic+b8 0x41cca5: VEP_Finish+155 0x41b35b: vfp_esi_end+4b 0x4219e1: FetchBody+2d1 0x416172: cnt_fetch+702 0x417865: CNT_Session+345 0x42e0f8: wrk_do_cnt_sess+b8 0x42e579: wrk_thread_real+409 0x7fa3d03509ca: _end+7fa3cfcd97f2 0x7fa3d00ad70d: _end+7fa3cfa36535 sp = 0x7fa38003d008 { fd = 16, id = 16, xid = 914667113, client = XX.90.89.5 1261, step = STP_FETCH, handling = hit_for_pass, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fa38003d080 { id = "sess", {s,f,r,e} = {0x7fa38003dcf0,+200,(nil),+65536}, }, http[req] = { ws = 0x7fa38003d080[sess] "HEAD", "/redhat/el5/i386/", "HTTP/1.1", "Host: repo.varnish-cache.org", "User-Agent: lftp/3.7.14", "Accept: */*", "Connection: keep-alive", "X-Forwarded-For: XX.90.89.5", }, worker = 0x7fa3843fdb80 { ws = 0x7fa3843fdd10 { id = "wrk", {s,f,r,e} = {0x7fa3843ebb10,+192,(nil),+65536}, }, http[bereq] = { ws = 0x7fa3843fdd10[wrk] "HEAD", "/redhat/el5/i386/", "HTTP/1.1", "Host: repo.varnish-cache.org", "User-Agent: lftp/3.7.14", "Accept: */*", "X-Forwarded-For: XX.90.89.5", "X-Varnish: 914667113", }, http[beresp] = { ws = 0x7fa3843fdd10[wrk] "HTTP/1.1", "200", "OK", "Date: Sun, 13 Mar 2011 05:27:24 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Vary: Accept-Encoding", "Content-Type: text/html;charset=UTF-8", "X-ESI: on", }, Mar 13 06:27:24 odd varnishd[22232]: Child cleanup complete Mar 13 06:27:24 odd varnishd[22232]: child (397) Started Mar 13 06:27:24 odd varnishd[22232]: Child (397) said Child starts -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 16:09:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 16:09:21 -0000 Subject: [Varnish] #870: Assert error in VEP_Finish(), In-Reply-To: <042.0e194f03b53aafb561dc260e5abc6da6@varnish-cache.org> References: <042.0e194f03b53aafb561dc260e5abc6da6@varnish-cache.org> Message-ID: <051.d830944bb6920154982830a5a53f7336@varnish-cache.org> #870: Assert error in VEP_Finish(), --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): It crashes like this approx 140 times per day. Mostly with the RHEL repo handling files, but also other places. Since the RHEL repos are getting the most traffic I would guess it's more or less random. Per. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 17:36:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 17:36:16 -0000 Subject: [Varnish] #865: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.be0a51473930cb8022195b8a86705ba4@varnish-cache.org> #865: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): According to http://cvs.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/fs/sockfs/sockcommon_sops.c#864 we're seeing a previously error from the socket (so_error) fcntl ends up in calling socket_vop_setlf http://cvs.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/fs/sockfs/sockcommon_vnops.c#221 which calls ioctl only {{{if ((oflags ^ nflags) & FASYNC && so->so_version != SOV_STREAM)}}} and does not care about so_error. If I replace the ioctls with fcntls, the error gets postponed even further: {{{ 25152/4: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) = 9 25152/4: fcntl(9, F_GETFL) = 2 25152/4: fcntl(9, F_SETFL, FWRITE|FNONBLOCK) = 0 25152/4: connect(9, 0x080B5218, 16, SOV_DEFAULT) Err#150 EINPROGRESS 25152/4: pollsys(0xFDA6DF28, 1, 0xFDA6DED8, 0x00000000) = 1 25152/4: fcntl(9, F_GETFL) = 130 25152/4: fcntl(9, F_SETFL, FWRITE) = 0 25152/4: getsockname(9, 0xFDA6DE30, 0xFDA6DE2C, SOV_DEFAULT) = 0 25152/4: write(9, " G E T / H T T P / 1".., 18) Err#32 EPIPE 25152/4: Received signal #13, SIGPIPE [default] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 19:17:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 19:17:34 -0000 Subject: [Varnish] #871: Child (4979) Panic message: Assert error in vfp_esi_end(), cache_esi_fetch.c line 368: Message-ID: <042.fe250ed8a8712069885be83225b98346@varnish-cache.org> #871: Child (4979) Panic message: Assert error in vfp_esi_end(), cache_esi_fetch.c line 368: --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Mar 13 20:12:54 odd varnishd[4484]: Child (4979) Panic message: Assert error in vfp_esi_end(), cache_esi_fetch.c line 368: Condition((sp->wrk->vep) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42caa8: pan_ic+b8 0x41b5a5: vfp_esi_end+245 0x421b51: FetchBody+2d1 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e268: wrk_do_cnt_sess+b8 0x42e6e9: wrk_thread_real+409 0x7fd78a7059ca: _end+7fd78a08e7b2 0x7fd78a46270d: _end+7fd789deb4f5 sp = 0x7fd73eb14008 { fd = 12, id = 12, xid = 2137431153, client = XX.100.131.242 47096, step = STP_FETCH, handling = hit_for_pass, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fd73eb14080 { id = "sess", {s,f,r,e} = {0x7fd73eb14cf0,+200,(nil),+65536}, }, http[req] = { ws = 0x7fd73eb14080[sess] "HEAD", "/redhat/el5/i386/", "HTTP/1.1", "Host: repo.varnish-cache.org", "User-Agent: lftp/3.7.11", "Accept: */*", "Connection: keep-alive", "X-Forwarded-For: XX.100.131.242", }, worker = 0x7fd73c2f9b80 { ws = 0x7fd73c2f9d10 { id = "wrk", {s,f,r,e} = {0x7fd73c2e7b10,+192,(nil),+65536}, }, http[bereq] = { ws = 0x7fd73c2f9d10[wrk] "HEAD", "/redhat/el5/i386/", "HTTP/1.1", "Host: repo.varnish-cache.org", "User-Agent: lftp/3.7.11", "Accept: */*", "X-Forwarded-For: XX.100.131.242", "X-Varnish: 2137431153", }, http[beresp] = { ws = 0x7fd73c2f9d10[wrk] "HTTP/1.1", "200", "OK", "Date: Sun, 13 Mar 2011 19:12:54 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Vary: Accept-Encoding", "Content-Type: text/html;charset=UTF-8", "X-ESI: on", }, }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 19:40:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 19:40:29 -0000 Subject: [Varnish] #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED (was: CNT_Session - TCP_blocking failing with ECONNREFUSED) In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.a29db6e7277e367e844fad5abc810aa5@varnish-cache.org> #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): Status update: The issue also happens with tcp_random_anon_port set to 0 (see http://opensolaris.org/jive/thread.jspa?messageID=476738). If we're seeing a delayed error, then it does not seem to make sense to me: For the (reproducible) case in varnishtest, it would be an error from connect(), but the remote socket is on the local machine is definitely open. For the core dumps with the stack trace given in the initial description, ECONNREFUSED makes even less sense to me, because we have successfully accept()ed a connection. For completeness, here's the trace of the last system calls before the assertion error, but with the original ioctl code in place: {{{ 13584/4: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) = 9 13584/4: ioctl(9, FIONBIO, 0xFDA6DEBC) = 0 13584/4: connect(9, 0x080B5218, 16, SOV_DEFAULT) Err#150 EINPROGRESS 13584/4: pollsys(0xFDA6DF28, 1, 0xFDA6DED8, 0x00000000) = 1 13584/4: ioctl(9, FIONBIO, 0xFDA6DF3C) Err#146 ECONNREFUSED 13584/4: lwp_sigmask(SIG_SETMASK, 0xFFBFFEFF, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF] 13584/4: open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_SGS.mo", O_RDONLY) Err#2 ENOENT 13584/4: lwp_exit() }}} I must say I really don't understand this and I am tempted to close this bug as INVALID, because this does so much look like an OpenSolaris issue. Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Mar 13 20:04:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 13 Mar 2011 20:04:08 -0000 Subject: [Varnish] #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> References: <042.f36bf3636d5e283d743abc7a78a04111@varnish-cache.org> Message-ID: <051.02bdf2ea8934e6d4062936bc52820b6e@varnish-cache.org> #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED ----------------------+----------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): have asked for help here: http://opensolaris.org/jive/thread.jspa?threadID=137844&tstart=0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 08:19:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 08:19:14 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.2857b45bec3c81b3a879ac8a375c907d@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by phk: Old description: > Google-bot came along and tried to fetch cache_esi_deliver, through > Varnish with ESI processing. Oh, the irony. > > We might want to warn people about ESI-processing the Varnish Source > code. :) > > Per. > > Mar 12 17:17:36 odd varnishd[10810]: Child (10811) said INFLATE=-3 > (invalid stored block lengths) > Mar 12 17:17:36 odd varnishd[10810]: Child (10811) died signal=6 > Mar 12 17:17:36 odd varnishd[10810]: Child (10811) > Panic message: Assert error in ESI_Deliver(), cache_esi_deliver.c line > 354: > #012 Condition(i == Z_OK || i == Z_STREAM_END) not true. > #012thread = (cache-worker)#012ident = > Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll > #012Backtrace: > #012 0x42c938: pan_ic+b8#012 0x41f558: ESI_Deliver+438 > #012 0x42f588: RES_WriteObj+248 > #012 0x4169b0: cnt_deliver+230#012 0x41783d: CNT_Session+31d > #012 0x42e0f8: wrk_do_cnt_sess+b8#012 0x42e579: wrk_thread_real+409 > #012 0x7ff04d4759ca: _end+7ff04cdfe7f2 > #012 0x7ff04d1d270d: _end+7ff04cb5b535 > #012sp = 0x7feffcc8a008 { > #012 fd = 15, id = 15, xid = 266236633, > #012 client = XX.249.66.180 36079, > #012 step = STP_DELIVER, > #012 handling = deliver, > #012 restarts = 0, esi_level = 0 > #012 ws = 0x7feffcc8a080 { > #012 id = "sess", > #012 {s,f,r,e} = {0x7feffcc8acf0,+472,(nil),+65536}, > #012 }, > #012 http[req] = { > #012 ws = 0x7feffcc8a080[sess] > #012 "GET", > #012 > "/trac/browser/bin/varnishd/cache_esi.c?annotate=blame&rev=3026e9ad36cc519bb8b19ad7e905f69f1eb66954", > #012 "HTTP/1.1", > #012 "Host: www.varnish-cache.org", > #012 "Connection: Keep-alive", > #012 "Accept: */*", > #012 "From: googlebot(at)googlebot.com", > #012 "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)", > #012 "X-Forwarded-For: 66.249.66.180, 66.249.66.180", > #012 }, > #012 worker = 0x7fefff1eeb80 { > #012 ws = 0x7fefff1eed10 { > #012 id = "wrk", > #012 {s,f,r,e} = {0x7fefff1dcb10,+144,(nil),+65536}, > #012 }, > #012 http[resp] = { > #012 ws = 0x7fefff1eed10[wrk]#012 "HTTP/1.1", > #012 "200",#012 "Ok", > #012 "Server: Apache/2.2.14 (Ubuntu)", > #012 "Cache-Control: must-revalidate", > #012 "Vary: Accept-Encoding", > #012 "Content-Type: text/html;charset=utf-8", > #012 "Transfer-Encoding: chunked", > #012 "Date: Sat, 12 Mar 2011 16:17:36 GMT", > #012 "X-Varnish: 266236633 266236629", > #012 "Age: 0", > #012 "Via: 1.1 varnish", > #012 "Connectio > Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete > Mar 12 17:17:36 odd varnishd[10810]: child (21915) Started > Mar 12 17:17:36 odd varnishd[10810]: Pushing vcls failed: > dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object > file: No such file or directory > Mar 12 17:17:36 odd varnishd[10810]: Stopping Child > Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child starts > Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child dies > Mar 12 17:17:36 odd varnishd[10810]: Child (21915) died > Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete New description: Google-bot came along and tried to fetch cache_esi_deliver, through Varnish with ESI processing. Oh, the irony. We might want to warn people about ESI-processing the Varnish Source code. :) Per. {{{ Mar 12 17:17:36 odd varnishd[10810]: Child (10811) said INFLATE=-3 (invalid stored block lengths) Mar 12 17:17:36 odd varnishd[10810]: Child (10811) died signal=6 Mar 12 17:17:36 odd varnishd[10810]: Child (10811) Panic message: Assert error in ESI_Deliver(), cache_esi_deliver.c line 354: #012 Condition(i == Z_OK || i == Z_STREAM_END) not true. #012thread = (cache-worker)#012ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll #012Backtrace: #012 0x42c938: pan_ic+b8#012 0x41f558: ESI_Deliver+438 #012 0x42f588: RES_WriteObj+248 #012 0x4169b0: cnt_deliver+230#012 0x41783d: CNT_Session+31d #012 0x42e0f8: wrk_do_cnt_sess+b8#012 0x42e579: wrk_thread_real+409 #012 0x7ff04d4759ca: _end+7ff04cdfe7f2 #012 0x7ff04d1d270d: _end+7ff04cb5b535 #012sp = 0x7feffcc8a008 { #012 fd = 15, id = 15, xid = 266236633, #012 client = XX.249.66.180 36079, #012 step = STP_DELIVER, #012 handling = deliver, #012 restarts = 0, esi_level = 0 #012 ws = 0x7feffcc8a080 { #012 id = "sess", #012 {s,f,r,e} = {0x7feffcc8acf0,+472,(nil),+65536}, #012 }, #012 http[req] = { #012 ws = 0x7feffcc8a080[sess] #012 "GET", #012 "/trac/browser/bin/varnishd/cache_esi.c?annotate=blame&rev=3026e9ad36cc519bb8b19ad7e905f69f1eb66954", #012 "HTTP/1.1", #012 "Host: www.varnish-cache.org", #012 "Connection: Keep-alive", #012 "Accept: */*", #012 "From: googlebot(at)googlebot.com", #012 "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", #012 "X-Forwarded-For: 66.249.66.180, 66.249.66.180", #012 }, #012 worker = 0x7fefff1eeb80 { #012 ws = 0x7fefff1eed10 { #012 id = "wrk", #012 {s,f,r,e} = {0x7fefff1dcb10,+144,(nil),+65536}, #012 }, #012 http[resp] = { #012 ws = 0x7fefff1eed10[wrk]#012 "HTTP/1.1", #012 "200",#012 "Ok", #012 "Server: Apache/2.2.14 (Ubuntu)", #012 "Cache-Control: must-revalidate", #012 "Vary: Accept-Encoding", #012 "Content-Type: text/html;charset=utf-8", #012 "Transfer-Encoding: chunked", #012 "Date: Sat, 12 Mar 2011 16:17:36 GMT", #012 "X-Varnish: 266236633 266236629", #012 "Age: 0", #012 "Via: 1.1 varnish", #012 "Connectio Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete Mar 12 17:17:36 odd varnishd[10810]: child (21915) Started Mar 12 17:17:36 odd varnishd[10810]: Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object file: No such file or directory Mar 12 17:17:36 odd varnishd[10810]: Stopping Child Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child starts Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 12 17:17:36 odd varnishd[10810]: Child (21915) said Child dies Mar 12 17:17:36 odd varnishd[10810]: Child (21915) died Mar 12 17:17:36 odd varnishd[10810]: Child cleanup complete }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 08:41:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 08:41:02 -0000 Subject: [Varnish] #870: Assert error in VEP_Finish(), In-Reply-To: <042.0e194f03b53aafb561dc260e5abc6da6@varnish-cache.org> References: <042.0e194f03b53aafb561dc260e5abc6da6@varnish-cache.org> Message-ID: <051.f8eb84f0bb5e93320af37c3bba5d4ca8@varnish-cache.org> #870: Assert error in VEP_Finish(), --------------------+------------------------------------------------------- Reporter: perbu | 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: Fixed in 6cd23c2a5a9028e42161389fac750f95d5bb77ec -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 08:41:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 08:41:23 -0000 Subject: [Varnish] #871: Child (4979) Panic message: Assert error in vfp_esi_end(), cache_esi_fetch.c line 368: In-Reply-To: <042.fe250ed8a8712069885be83225b98346@varnish-cache.org> References: <042.fe250ed8a8712069885be83225b98346@varnish-cache.org> Message-ID: <051.42c0fc64734f3935314d7788fda026b5@varnish-cache.org> #871: Child (4979) Panic message: Assert error in vfp_esi_end(), cache_esi_fetch.c line 368: --------------------+------------------------------------------------------- Reporter: perbu | 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: same as #870, fixed in 6cd23c2a5a9028e42161389fac750f95d5bb77ec -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 09:50:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 09:50:18 -0000 Subject: [Varnish] #866: Multiple headers with the same name on different lines are ignored In-Reply-To: <043.0782868cc9b22614fe1a45478fa6bb30@varnish-cache.org> References: <043.0782868cc9b22614fe1a45478fa6bb30@varnish-cache.org> Message-ID: <052.d8a1e3cd1efbdd21d8e06172fa002fad@varnish-cache.org> #866: Multiple headers with the same name on different lines are ignored ---------------------+------------------------------------------------------ Reporter: soheil | Type: defect Status: closed | Priority: high Milestone: | Component: varnishd Version: trunk | Severity: major Resolution: fixed | Keywords: multiple headers, same headers, VRT_GetHdr, headers ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: Thanks for reminding me: I have now added std.collect() for this purpose to VMOD std. See commit 395a5c8deee8cd9410964ccbfd9cce9843cbb3a2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 10:16:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 10:16:15 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() Message-ID: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- On fresh trunk code: www.varnish-cache.org/login is crashing varnish. I don't think this happended earlier. Might be because we're now ESI-processing everything that is "text/*". Anyway, here is an assert. Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 ESI 1.0 illegal end-tag Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 ESI 1.0 lacks final '/' Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 ESI 1.0 illegal end-tag Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 ESI 1.0 lacks final '/' Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 ESI 1.0 illegal end-tag Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quitr Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 Unknown request. Type 'help' for more info. Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quit Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 Closing CLI connection Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x423085: VGZ_Destroy+135 0x41b4ce: vfp_esi_end+16e 0x421b11: FetchBody+291 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e2d8: wrk_do_cnt_sess+b8 0x42e759: wrk_thread_real+409 0x7f0fa09239ca: _end+7f0fa02ac7b2 0x7f0fa068070d: _end+7f0fa00094f5 sp = 0x7f0f55303008 { fd = 16, id = 16, xid = 583115844, client = XX.238.35.17 44993, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0f55303080 { id = "sess", {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, }, http[req] = { ws = 0x7f0f55303080[sess] "GET", "/trac/login", "HTTP/1.1", "Host: www.varnish-cache.org", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Encoding: gzip,deflate", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Referer: http://www.varnish- cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", "DNT: 1", "Connection: keep-alive", "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", "X-Forwarded-For: XX.238.35.17", "Cookie: trac_form_token=a37857f8a86982568d228037; trac_session=dff0c9e82d61c90bf66255a1", }, worker = 0x7f0f54afdb80 { ws = 0x7f0f54afdd10 { id = "wrk", {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, }, http[bereq] = { ws = 0x7f0f54afdd10[wrk] "GET", "/trac/login", Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 ESI 1.0 lacks final '/' Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 ESI 1.0 illegal end-tag -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 10:17:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 10:17:04 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.ac99b3020ec61c80eceac37a1ae0b581@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > On fresh trunk code: > > www.varnish-cache.org/login is crashing varnish. I don't think this > happended earlier. Might be because we're now ESI-processing everything > that is "text/*". Anyway, here is an assert. > > Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 > ESI 1.0 illegal end-tag > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 > ESI 1.0 lacks final '/' > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 > ESI 1.0 illegal end-tag > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 > ESI 1.0 lacks final '/' > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 > ESI 1.0 illegal end-tag > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quitr > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 > Unknown request. > Type 'help' for more info. > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quit > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 > Closing CLI connection > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert > error in VGZ_Destroy(), cache_gzip.c line 387: > Condition((deflateEnd(&vg->vz)) == 0) not true. > thread = (cache-worker) > ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: > 0x42cb18: pan_ic+b8 > 0x423085: VGZ_Destroy+135 > 0x41b4ce: vfp_esi_end+16e > 0x421b11: FetchBody+291 > 0x4161c2: cnt_fetch+702 > 0x4178b5: CNT_Session+345 > 0x42e2d8: wrk_do_cnt_sess+b8 > 0x42e759: wrk_thread_real+409 > 0x7f0fa09239ca: _end+7f0fa02ac7b2 > 0x7f0fa068070d: _end+7f0fa00094f5 > sp = 0x7f0f55303008 { > fd = 16, id = 16, xid = 583115844, > client = XX.238.35.17 44993, > step = STP_FETCH, > handling = deliver, > err_code = 302, err_reason = (null), > restarts = 0, esi_level = 0 > ws = 0x7f0f55303080 { > id = "sess", > {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, > }, > http[req] = { > ws = 0x7f0f55303080[sess] > "GET", > "/trac/login", > "HTTP/1.1", > "Host: www.varnish-cache.org", > "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", > "Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > "Accept-Language: en-us,en;q=0.5", > "Accept-Encoding: gzip,deflate", > "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", > "Keep-Alive: 300", > "Referer: http://www.varnish- > cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", > "DNT: 1", > "Connection: keep-alive", > "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", > "X-Forwarded-For: XX.238.35.17", > "Cookie: trac_form_token=a37857f8a86982568d228037; > trac_session=dff0c9e82d61c90bf66255a1", > }, > worker = 0x7f0f54afdb80 { > ws = 0x7f0f54afdd10 { > id = "wrk", > {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, > }, > http[bereq] = { > ws = 0x7f0f54afdd10[wrk] > "GET", > "/trac/login", > > Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete > Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 > ESI 1.0 lacks final '/' > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 > ESI 1.0 illegal end-tag New description: On fresh trunk code (6cd23c2). www.varnish-cache.org/login is crashing varnish. I don't think this happended earlier. Might be because we're now ESI-processing everything that is "text/*". Anyway, here is an assert. Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 ESI 1.0 illegal end-tag Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 ESI 1.0 lacks final '/' Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 ESI 1.0 illegal end-tag Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 ESI 1.0 lacks final '/' Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 ESI 1.0 illegal end-tag Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quitr Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 Unknown request. Type 'help' for more info. Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quit Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 Closing CLI connection Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x423085: VGZ_Destroy+135 0x41b4ce: vfp_esi_end+16e 0x421b11: FetchBody+291 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e2d8: wrk_do_cnt_sess+b8 0x42e759: wrk_thread_real+409 0x7f0fa09239ca: _end+7f0fa02ac7b2 0x7f0fa068070d: _end+7f0fa00094f5 sp = 0x7f0f55303008 { fd = 16, id = 16, xid = 583115844, client = XX.238.35.17 44993, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0f55303080 { id = "sess", {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, }, http[req] = { ws = 0x7f0f55303080[sess] "GET", "/trac/login", "HTTP/1.1", "Host: www.varnish-cache.org", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Encoding: gzip,deflate", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Referer: http://www.varnish- cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", "DNT: 1", "Connection: keep-alive", "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", "X-Forwarded-For: XX.238.35.17", "Cookie: trac_form_token=a37857f8a86982568d228037; trac_session=dff0c9e82d61c90bf66255a1", }, worker = 0x7f0f54afdb80 { ws = 0x7f0f54afdd10 { id = "wrk", {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, }, http[bereq] = { ws = 0x7f0f54afdd10[wrk] "GET", "/trac/login", Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 ESI 1.0 lacks final '/' Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 ESI 1.0 illegal end-tag -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 10:18:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 10:18:34 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.54506e6c0d3366b5d465a3825a3078a2@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by phk: Old description: > On fresh trunk code (6cd23c2). > > www.varnish-cache.org/login is crashing varnish. I don't think this > happended earlier. Might be because we're now ESI-processing everything > that is "text/*". Anyway, here is an assert. > > Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 > ESI 1.0 illegal end-tag > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 > ESI 1.0 lacks final '/' > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 > ESI 1.0 illegal end-tag > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 > ESI 1.0 lacks final '/' > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 > ESI 1.0 illegal end-tag > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quitr > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 > Unknown request. > Type 'help' for more info. > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quit > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 > Closing CLI connection > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert > error in VGZ_Destroy(), cache_gzip.c line 387: > Condition((deflateEnd(&vg->vz)) == 0) not true. > thread = (cache-worker) > ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: > 0x42cb18: pan_ic+b8 > 0x423085: VGZ_Destroy+135 > 0x41b4ce: vfp_esi_end+16e > 0x421b11: FetchBody+291 > 0x4161c2: cnt_fetch+702 > 0x4178b5: CNT_Session+345 > 0x42e2d8: wrk_do_cnt_sess+b8 > 0x42e759: wrk_thread_real+409 > 0x7f0fa09239ca: _end+7f0fa02ac7b2 > 0x7f0fa068070d: _end+7f0fa00094f5 > sp = 0x7f0f55303008 { > fd = 16, id = 16, xid = 583115844, > client = XX.238.35.17 44993, > step = STP_FETCH, > handling = deliver, > err_code = 302, err_reason = (null), > restarts = 0, esi_level = 0 > ws = 0x7f0f55303080 { > id = "sess", > {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, > }, > http[req] = { > ws = 0x7f0f55303080[sess] > "GET", > "/trac/login", > "HTTP/1.1", > "Host: www.varnish-cache.org", > "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", > "Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > "Accept-Language: en-us,en;q=0.5", > "Accept-Encoding: gzip,deflate", > "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", > "Keep-Alive: 300", > "Referer: http://www.varnish- > cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", > "DNT: 1", > "Connection: keep-alive", > "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", > "X-Forwarded-For: XX.238.35.17", > "Cookie: trac_form_token=a37857f8a86982568d228037; > trac_session=dff0c9e82d61c90bf66255a1", > }, > worker = 0x7f0f54afdb80 { > ws = 0x7f0f54afdd10 { > id = "wrk", > {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, > }, > http[bereq] = { > ws = 0x7f0f54afdd10[wrk] > "GET", > "/trac/login", > > Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete > Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 > ESI 1.0 lacks final '/' > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 > ESI 1.0 illegal end-tag New description: On fresh trunk code (6cd23c2). www.varnish-cache.org/login is crashing varnish. I don't think this happended earlier. Might be because we're now ESI-processing everything that is "text/*". Anyway, here is an assert. {{{ Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 ESI 1.0 illegal end-tag Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 ESI 1.0 lacks final '/' Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 ESI 1.0 illegal end-tag Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 ESI 1.0 lacks final '/' Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 ESI 1.0 illegal end-tag Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quitr Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 Unknown request. Type 'help' for more info. Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd quit Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 Closing CLI connection Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x423085: VGZ_Destroy+135 0x41b4ce: vfp_esi_end+16e 0x421b11: FetchBody+291 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e2d8: wrk_do_cnt_sess+b8 0x42e759: wrk_thread_real+409 0x7f0fa09239ca: _end+7f0fa02ac7b2 0x7f0fa068070d: _end+7f0fa00094f5 sp = 0x7f0f55303008 { fd = 16, id = 16, xid = 583115844, client = XX.238.35.17 44993, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0f55303080 { id = "sess", {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, }, http[req] = { ws = 0x7f0f55303080[sess] "GET", "/trac/login", "HTTP/1.1", "Host: www.varnish-cache.org", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Encoding: gzip,deflate", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Referer: http://www.varnish- cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", "DNT: 1", "Connection: keep-alive", "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", "X-Forwarded-For: XX.238.35.17", "Cookie: trac_form_token=a37857f8a86982568d228037; trac_session=dff0c9e82d61c90bf66255a1", }, worker = 0x7f0f54afdb80 { ws = 0x7f0f54afdd10 { id = "wrk", {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, }, http[bereq] = { ws = 0x7f0f54afdd10[wrk] "GET", "/trac/login", Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 ESI 1.0 lacks final '/' Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 ESI 1.0 illegal end-tag }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 10:59:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 10:59:02 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.9ae37787a61f73adf24e97b2cac4010b@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > On fresh trunk code (6cd23c2). > > www.varnish-cache.org/login is crashing varnish. I don't think this > happended earlier. Might be because we're now ESI-processing everything > that is "text/*". Anyway, here is an assert. > {{{ > Mar 14 11:11:07 odd varnishd[17252]: Child (25776) said ERROR at 10664 > ESI 1.0 illegal end-tag > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said WARNING at 19600 > ESI 1.0 lacks final '/' > Mar 14 11:11:10 odd varnishd[17252]: Child (25776) said ERROR at 19606 > ESI 1.0 illegal end-tag > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said WARNING at 12986 > ESI 1.0 lacks final '/' > Mar 14 11:11:11 odd varnishd[17252]: Child (25776) said ERROR at 12992 > ESI 1.0 illegal end-tag > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quitr > Mar 14 11:11:12 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 101 > Unknown request. > Type 'help' for more info. > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Rd > quit > Mar 14 11:11:14 odd varnishd[17252]: CLI telnet ::1 56920 ::1 6082 Wr 500 > Closing CLI connection > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert > error in VGZ_Destroy(), cache_gzip.c line 387: > Condition((deflateEnd(&vg->vz)) == 0) not true. > thread = (cache-worker) > ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: > 0x42cb18: pan_ic+b8 > 0x423085: VGZ_Destroy+135 > 0x41b4ce: vfp_esi_end+16e > 0x421b11: FetchBody+291 > 0x4161c2: cnt_fetch+702 > 0x4178b5: CNT_Session+345 > 0x42e2d8: wrk_do_cnt_sess+b8 > 0x42e759: wrk_thread_real+409 > 0x7f0fa09239ca: _end+7f0fa02ac7b2 > 0x7f0fa068070d: _end+7f0fa00094f5 > sp = 0x7f0f55303008 { > fd = 16, id = 16, xid = 583115844, > client = XX.238.35.17 44993, > step = STP_FETCH, > handling = deliver, > err_code = 302, err_reason = (null), > restarts = 0, esi_level = 0 > ws = 0x7f0f55303080 { > id = "sess", > {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, > }, > http[req] = { > ws = 0x7f0f55303080[sess] > "GET", > "/trac/login", > "HTTP/1.1", > "Host: www.varnish-cache.org", > "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", > "Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > "Accept-Language: en-us,en;q=0.5", > "Accept-Encoding: gzip,deflate", > "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", > "Keep-Alive: 300", > "Referer: http://www.varnish- > cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", > "DNT: 1", > "Connection: keep-alive", > "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", > "X-Forwarded-For: XX.238.35.17", > "Cookie: trac_form_token=a37857f8a86982568d228037; > trac_session=dff0c9e82d61c90bf66255a1", > }, > worker = 0x7f0f54afdb80 { > ws = 0x7f0f54afdd10 { > id = "wrk", > {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, > }, > http[bereq] = { > ws = 0x7f0f54afdd10[wrk] > "GET", > "/trac/login", > > Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete > Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 > ESI 1.0 lacks final '/' > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 > ESI 1.0 illegal end-tag > }}} New description: On fresh trunk code (6cd23c2). www.varnish-cache.org/login is crashing varnish. I don't think this happended earlier. Might be because we're now ESI-processing everything that is "text/*". Anyway, here is an assert. {{{ Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x423085: VGZ_Destroy+135 0x41b4ce: vfp_esi_end+16e 0x421b11: FetchBody+291 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e2d8: wrk_do_cnt_sess+b8 0x42e759: wrk_thread_real+409 0x7f0fa09239ca: _end+7f0fa02ac7b2 0x7f0fa068070d: _end+7f0fa00094f5 sp = 0x7f0f55303008 { fd = 16, id = 16, xid = 583115844, client = XX.238.35.17 44993, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0f55303080 { id = "sess", {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, }, http[req] = { ws = 0x7f0f55303080[sess] "GET", "/trac/login", "HTTP/1.1", "Host: www.varnish-cache.org", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Encoding: gzip,deflate", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Referer: http://www.varnish- cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", "DNT: 1", "Connection: keep-alive", "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", "X-Forwarded-For: XX.238.35.17", "Cookie: trac_form_token=a37857f8a86982568d228037; trac_session=dff0c9e82d61c90bf66255a1", }, worker = 0x7f0f54afdb80 { ws = 0x7f0f54afdd10 { id = "wrk", {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, }, http[bereq] = { ws = 0x7f0f54afdd10[wrk] "GET", "/trac/login", Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 ESI 1.0 lacks final '/' Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 ESI 1.0 illegal end-tag }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:06:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:06:35 -0000 Subject: [Varnish] #727: Tiny Patch: Human readable nagios output In-Reply-To: <043.c3df909e2981935706b069f554e595ef@varnish-cache.org> References: <043.c3df909e2981935706b069f554e595ef@varnish-cache.org> Message-ID: <052.384472f1fbc61b0e54bff2ec91d10c4c@varnish-cache.org> #727: Tiny Patch: Human readable nagios output -------------------------+-------------------------------------------------- Reporter: sascha | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:09:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:09:04 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.0a597b93429270e8f1d619b425afbec8@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Changes (by phk): * component: varnishd => documentation Old description: > Active connections( that is, clients downloading and accepting data ) > will be closed by varnish if the download takes more than send_timeout > seconds. > > We run varnish on linux/debian etch 64bits. We have seen this problem in > both v1.0.4 and 2.0~tp2-0. > > There seems to be a discrepancy between how send_timeout is defined in > 'man varnishd' and what it actually does. New description: Active connections( that is, clients downloading and accepting data ) will be closed by varnish if the download takes more than send_timeout seconds. We run varnish on linux/debian etch 64bits. We have seen this problem in both v1.0.4 and 2.0~tp2-0. There seems to be a discrepancy between how send_timeout is defined in 'man varnishd' and what it actually does. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:09:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:09:32 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.02797280449105bfe9701f3fe8c16c86@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Changes (by phk): * status: reopened => new * owner: phk => perbu -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:12:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:12:25 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty In-Reply-To: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> References: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> Message-ID: <051.4fb3e659541abcfeeedea0c316b75039@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: varnishncsa -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:14:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:14:59 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.83abcb4a14d7e9240fe344b3268bbb2d@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 ----------------------+----------------------------------------------------- Reporter: miohtama | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * owner: => kristian Comment: I'll be testing this on a clean 8.04. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 11:19:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 11:19:01 -0000 Subject: [Varnish] #873: Assert error in vfp_esi_bytes_ug Message-ID: <045.6ad25ca83ba11a691076cbb9ada00984@varnish-cache.org> #873: Assert error in vfp_esi_bytes_ug ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- As of 12:15 today. ESI and gzip is enabled. Does NOT fail with gzip disabled. {{{ Child (3142) said Child starts Child (3142) died signal=6 Child (3142) Panic message: Assert error in vfp_esi_bytes_ug(), cache_esi_fetch.c line 235: Condition(w + vef->npend < sizeof vef->pending) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x429bc6: pan_ic+b6 0x4198db: vfp_esi_bytes_ug+16b 0x419dd8: vfp_esi_bytes+148 0x41f911: FetchBody+711 0x414942: cnt_fetch+6d2 0x415f56: CNT_Session+376 0x42c188: wrk_do_cnt_sess+b8 0x42b38a: wrk_thread_real+3ea 0x3aac40673d: _end+3aabd952e5 0x3aabcd3f6d: _end+3aab662b15 sp = 0x2aaaac900008 { fd = 3, id = 3, xid = 1388183079, client = 87.238.55.186 35259, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x2aaaac900080 { id = "sess", {s,f,r,e} = {0x2aaaac900cf0,+112,(nil),+2621440}, }, http[req] = { ws = 0x2aaaac900080[sess] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", }, worker = 0x549e6e00 { ws = 0x549e6f90 { id = "wrk", {s,f,r,e} = {0x549d4db0,+4752,(nil),+65536}, }, http[bereq] = { ws = 0x549e6f90[wrk] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", "X-Varnish: 1388183079", }, http[beresp] = { ws = 0x549e6f90[wrk] "HTTP/1.1", "200", "OK", "X-Trace-App: [seamstress ; fibba.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-fibba", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Content-Length: 67284", "Date: Mon, 14 Mar 2011 11:04:38 GMT", "X-Varnish: 1051344559 1051111584", "Age: 2284", "Via: 1.1 varnish", "Connection: keep-alive", "X-Src-Webcache: samtid varnish 3.0 fibba", "Content-Encoding: gzip", }, }, vcl = { srcname = { "input", "Default", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", }, }, obj = 0x2aaaacd07300 { xid = 1388183079, ws = 0x2aaaacd07318 { id = "obj", {s,f,r,e} = {0x2aaaacd075a0,+1000,(nil),+1056}, }, http[obj] = { ws = 0x2aaaacd07318[obj] "HTTP/1.1", "OK", "X-Trace-App: [seamstress ; fibba.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-fibba", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Date: Mon, 14 Mar 2011 11:04:38 GMT", "X-Varnish: 1051344559 1051111584", "Via: 1.1 varnish", "X-Src-Webcache: samtid varnish 3.0 fibba", "Content-Encoding: gzip", }, len = 31982, store = { 31982 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| 14 8c b1 0a c2 30 14 00 f7 7e c5 33 7b f3 94 76 |.....0...~.3{..v| 92 d8 a1 49 41 a1 6a 91 88 38 06 1a 6c 20 4d b4 |...IA.j..8..l M.| 7d 9a df 97 4c 07 07 77 62 a3 ae 52 3f 87 0e 26 |}...L..wb..R?..&| [31918 more] }, }, }, }, Child cleanup complete child (3175) Started Child (3175) said Child starts Child (3175) died signal=6 Child (3175) Panic message: Assert error in vfp_esi_bytes_ug(), cache_esi_fetch.c line 235: Condition(w + vef->npend < sizeof vef->pending) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x429bc6: pan_ic+b6 0x4198db: vfp_esi_bytes_ug+16b 0x419dd8: vfp_esi_bytes+148 0x41f911: FetchBody+711 0x414942: cnt_fetch+6d2 0x415f56: CNT_Session+376 0x42c188: wrk_do_cnt_sess+b8 0x42b38a: wrk_thread_real+3ea 0x3aac40673d: _end+3aabd952e5 0x3aabcd3f6d: _end+3aab662b15 sp = 0x2aaaad200008 { fd = 3, id = 3, xid = 2034524242, client = 87.238.55.186 35292, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x2aaaad200080 { id = "sess", {s,f,r,e} = {0x2aaaad200cf0,+112,(nil),+2621440}, }, http[req] = { ws = 0x2aaaad200080[sess] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", }, worker = 0x51885e00 { ws = 0x51885f90 { id = "wrk", {s,f,r,e} = {0x51873db0,+4752,(nil),+65536}, }, http[bereq] = { ws = 0x51885f90[wrk] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", "X-Varnish: 2034524242", }, http[beresp] = { ws = 0x51885f90[wrk] "HTTP/1.1", "200", "OK", "X-Trace-App: [seamstress ; fibba.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-fibba", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Content-Length: 67284", "Date: Mon, 14 Mar 2011 11:04:40 GMT", "X-Varnish: 1051344858 1051111584", "Age: 2286", "Via: 1.1 varnish", "Connection: keep-alive", "X-Src-Webcache: samtid varnish 3.0 fibba", "Content-Encoding: gzip", }, }, vcl = { srcname = { "input", "Default", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", }, }, obj = 0x2aaaace0c300 { xid = 2034524242, ws = 0x2aaaace0c318 { id = "obj", {s,f,r,e} = {0x2aaaace0c5a0,+1000,(nil),+1056}, }, http[obj] = { ws = 0x2aaaace0c318[obj] "HTTP/1.1", "OK", "X-Trace-App: [seamstress ; fibba.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-fibba", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Date: Mon, 14 Mar 2011 11:04:40 GMT", "X-Varnish: 1051344858 1051111584", "Via: 1.1 varnish", "X-Src-Webcache: samtid varnish 3.0 fibba", "Content-Encoding: gzip", }, len = 31982, store = { 31982 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| 14 8c b1 0a c2 30 14 00 f7 7e c5 33 7b f3 94 76 |.....0...~.3{..v| 92 d8 a1 49 41 a1 6a 91 88 38 06 1a 6c 20 4d b4 |...IA.j..8..l M.| 7d 9a df 97 4c 07 07 77 62 a3 ae 52 3f 87 0e 26 |}...L..wb..R?..&| [31918 more] }, }, }, }, Child cleanup complete child (3225) Started Child (3225) said Child starts Child (3225) died signal=6 Child (3225) Panic message: Assert error in vfp_esi_bytes_ug(), cache_esi_fetch.c line 235: Condition(w + vef->npend < sizeof vef->pending) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x429bc6: pan_ic+b6 0x4198db: vfp_esi_bytes_ug+16b 0x419dd8: vfp_esi_bytes+148 0x41f911: FetchBody+711 0x414942: cnt_fetch+6d2 0x415f56: CNT_Session+376 0x42c188: wrk_do_cnt_sess+b8 0x42b38a: wrk_thread_real+3ea 0x3aac40673d: _end+3aabd952e5 0x3aabcd3f6d: _end+3aab662b15 sp = 0x2aaaac900008 { fd = 3, id = 3, xid = 1339149085, client = 87.238.55.186 35326, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x2aaaac900080 { id = "sess", {s,f,r,e} = {0x2aaaac900cf0,+112,(nil),+2621440}, }, http[req] = { ws = 0x2aaaac900080[sess] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", }, worker = 0x54580e00 { ws = 0x54580f90 { id = "wrk", {s,f,r,e} = {0x5456edb0,+4744,(nil),+65536}, }, http[bereq] = { ws = 0x54580f90[wrk] "GET", "/", "HTTP/1.1", "Host: www.ba.no", "X-Forwarded-For: 87.238.55.186", "X-Varnish: 1339149085", }, http[beresp] = { ws = 0x54580f90[wrk] "HTTP/1.1", "200", "OK", "X-Trace-App: [seamstress ; akut.api.kunder.linpro.no ; Mon Mar 14 11:26:38 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-akut", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Content-Length: 67284", "Date: Mon, 14 Mar 2011 11:04:42 GMT", "X-Varnish: 1155699237 1155465531", "Age: 2283", "Via: 1.1 varnish", "Connection: keep-alive", "X-Src-Webcache: samtid varnish 3.0 akut", "Content-Encoding: gzip", }, }, vcl = { srcname = { "input", "Default", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", }, }, obj = 0x2aaaacd07300 { xid = 1339149085, ws = 0x2aaaacd07318 { id = "obj", {s,f,r,e} = {0x2aaaacd075a0,+992,(nil),+1048}, }, http[obj] = { ws = 0x2aaaacd07318[obj] "HTTP/1.1", "OK", "X-Trace-App: [seamstress ; akut.api.kunder.linpro.no ; Mon Mar 14 11:26:38 CET 2011]", "Surrogate-Control: content="ESI/1.0"", "Cache-Control: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/seamstress-akut", group="/relax-nominell", group="/pub41", group="/redirect", group="/redirect41", group="/jawrcounter", group ="/relax-verksam", group="/sec71", group="/sec8755", group="/sec29757", group="/art4715233", group="/art5427319", group="/art4715209", group="/art5513415"", "X-Trace-App: [relax ; nominell.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "X-Trace-App: [relax ; verksam.api.kunder.linpro.no ; Mon Mar 14 11:26:34 CET 2011]", "Content-Language: nb-NO-www.ba.no", "Content-Type: text/html; charset=utf-8", "Server: Jetty(6.1.24)", "Date: Mon, 14 Mar 2011 11:04:42 GMT", "X-Varnish: 1155699237 1155465531", "Via: 1.1 varnish", "X-Src-Webcache: samtid varnish 3.0 akut", "Content-Encoding: gzip", }, len = 31982, store = { 31982 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| 14 8c b1 0a c2 30 14 00 f7 7e c5 33 7b f3 94 76 |.....0...~.3{..v| 92 d8 a1 49 41 a1 6a 91 88 38 06 1a 6c 20 4d b4 |...IA.j..8..l M.| 7d 9a df 97 4c 07 07 77 62 a3 ae 52 3f 87 0e 26 |}...L..wb..R?..&| [31918 more] }, }, }, }, Child cleanup complete child (3258) Started Child (3258) said Child starts Manager got SIGINT Stopping Child }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 14:03:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 14:03:17 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.33417d36f3f281b7a3e179308a46207f@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Comment(by perbu): Is this better? diff --git a/bin/varnishd/mgt_param.c b/bin/varnishd/mgt_param.c index ed70fc7..a1f33d0 100644 --- a/bin/varnishd/mgt_param.c +++ b/bin/varnishd/mgt_param.c @@ -611,8 +611,8 @@ static const struct parspec input_parspec[] = { "60", "seconds" }, { "send_timeout", tweak_timeout, &master.send_timeout, 0, 0, "Send timeout for client connections. " - "If no data has been sent to the client in this many seconds, " - "the session is closed.\n" + "If the HTTP response hasn't been transmitted in this many\n" + "seconds the session is closed. \n" "See setsockopt(2) under SO_SNDTIMEO for more information.", DELAYED_EFFECT, "60", "seconds" }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 14 18:26:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Mar 2011 18:26:08 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.81b99dcc73d250971b9dffaddf73c6c2@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Comment(by jbarbuto): Looks good to me, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From stockrt at gmail.com Tue Mar 15 02:38:21 2011 From: stockrt at gmail.com (=?ISO-8859-1?Q?Rog=E9rio_Schneider?=) Date: Mon, 14 Mar 2011 23:38:21 -0300 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <053.81b99dcc73d250971b9dffaddf73c6c2@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> <053.81b99dcc73d250971b9dffaddf73c6c2@varnish-cache.org> Message-ID: Yep, looks good. On Mon, Mar 14, 2011 at 3:26 PM, Varnish wrote: > #402: send_timeout cause connections to be prematurely closed > > --------------------------------------+------------------------------------- > Reporter: havardf | Owner: perbu > Type: defect | Status: new > Priority: normal | Milestone: > Component: documentation | Version: 2.0 > Severity: normal | Resolution: > Keywords: send_timeout connections | > > --------------------------------------+------------------------------------- > > Comment(by jbarbuto): > > Looks good to me, thanks! > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > -- Rog?rio Schneider http://stockrt.github.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Tue Mar 15 02:41:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 02:41:59 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.bd844e3ab106f09adf2da7366f398664@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: perbu Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: send_timeout connections | --------------------------------------+------------------------------------- Comment(by stockrt): Yep, looks good. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 07:05:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 07:05:49 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty In-Reply-To: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> References: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> Message-ID: <051.4665f8c75a1be53626e601990b37c52c@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: varnishncsa -------------------------+-------------------------------------------------- Comment(by tfheen): I'm unable to reproduce this in trunk. Are you actually using trunk or some other version? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 07:08:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 07:08:02 -0000 Subject: [Varnish] #874: gzip failures on 32 bit big-endian Message-ID: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> #874: gzip failures on 32 bit big-endian ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- It seems like there's some endianness problem in the gzip code, see the end of http://buildbot.varnish-cache.org/builders/buildbot-debian- ppc/builds/1564/steps/test/logs/stdio for a test failure. Filing this here so it's not forgotten. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 07:08:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 07:08:10 -0000 Subject: [Varnish] #874: gzip failures on 32 bit big-endian In-Reply-To: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> References: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> Message-ID: <052.d4e925824fd98eb9be5bc47d9cc8cc4d@varnish-cache.org> #874: gzip failures on 32 bit big-endian ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 08:28:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 08:28:10 -0000 Subject: [Varnish] #874: gzip failures on 32 bit big-endian In-Reply-To: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> References: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> Message-ID: <052.17317a3dddcd23898cea1316824c5468@varnish-cache.org> #874: gzip failures on 32 bit big-endian ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This was not, as I had feared an endianess issue, but merely a question of proper casts. Fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 08:56:31 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 08:56:31 -0000 Subject: [Varnish] #874: gzip failures on 32 bit big-endian In-Reply-To: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> References: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> Message-ID: <052.e43082e205d72883b978ed72cbbb564a@varnish-cache.org> #874: gzip failures on 32 bit big-endian ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: closed => reopened * resolution: fixed => Comment: This still seems to be an issue, see http://buildbot.varnish- cache.org/builders/buildbot-debian-ppc/builds/1565/steps/test/logs/stdio for the new build log. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 09:12:41 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 09:12:41 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.ce0b5ddf9f4c1ddc03ea0963a8f4428b@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 ----------------------+----------------------------------------------------- Reporter: miohtama | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * milestone: Varnish 3.0 dev => Later Comment: I've been testing this on 8.04 LTS and I'm not able to reproduce it. Trunk seems to work just fine with a stock install + security upgrades. Is it possible for you to try a clean install, and install either 2.1.5 from source or trunk? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 09:22:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 09:22:16 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.fa31dd263be0fa4302d908b8ba100acd@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): New panic. Now running with http_gzip_support=off. {{{ Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cba8: pan_ic+b8 0x423115: VGZ_Destroy+135 0x41b53e: vfp_esi_end+16e 0x421ba1: FetchBody+291 0x416232: cnt_fetch+702 0x417925: CNT_Session+345 0x42e368: wrk_do_cnt_sess+b8 0x42e7e9: wrk_thread_real+409 0x7f07936a79ca: _end+7f0793030752 0x7f079340470d: _end+7f0792d8d495 sp = 0x7f0743235008 { fd = 17, id = 17, xid = 1794413182, client = 87.238.43.251 59569, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0743235080 { id = "sess", {s,f,r,e} = {0x7f0743235cf0,+1408,(nil),+65536}, }, http[req] = { ws = 0x7f0743235080[sess] "GET", "/trac/logout", "HTTP/1.1", "Host: www.varnish-cache.org", "Connection: keep-alive", "Referer: http://www.varnish-cache.org/trac", "Authorization: Basic cGVyYnU6ZGVsaWxsb3M=", "User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.127 Safari/534.16", "Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "Accept-Encoding: gzip,deflate,sdch", "Accept-Language: en-US,nb- NO;q=0.8,nb;q=0.6,no;q=0.4,nn;q=0.2,en;q=0.2", "Accept-Charset: UTF-8,*;q=0.5", "X-Forwarded-For: 87.238.43.251", "Cookie: trac_form_token=f36b61e2a53c878c1d0975d4; trac_auth=d0d063a13a4c32aa5b54c91c6fd0dae1; DrupalAdminToolbar=expanded%3D1%26activeTab%3Dadmin-menu", }, worker = 0x7f07445ebb80 { ws = 0x7f07445ebd10 { id = "wrk", {s,f,r,e} = {0x7f07445d9b10,+752,(nil),+65536}, }, http[bereq] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 09:23:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 09:23:59 -0000 Subject: [Varnish] #873: Assert error in vfp_esi_bytes_ug In-Reply-To: <045.6ad25ca83ba11a691076cbb9ada00984@varnish-cache.org> References: <045.6ad25ca83ba11a691076cbb9ada00984@varnish-cache.org> Message-ID: <054.84ee81b2a4b58d827ac6cab62a43dfb0@varnish-cache.org> #873: Assert error in vfp_esi_bytes_ug ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in 516e69e -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 09:25:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 09:25:59 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.4c9ecea40d8533db8de29b020884003b@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > On fresh trunk code (6cd23c2). > > www.varnish-cache.org/login is crashing varnish. I don't think this > happended earlier. Might be because we're now ESI-processing everything > that is "text/*". Anyway, here is an assert. > {{{ > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 > Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert > error in VGZ_Destroy(), cache_gzip.c line 387: > Condition((deflateEnd(&vg->vz)) == 0) not true. > thread = (cache-worker) > ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: > 0x42cb18: pan_ic+b8 > 0x423085: VGZ_Destroy+135 > 0x41b4ce: vfp_esi_end+16e > 0x421b11: FetchBody+291 > 0x4161c2: cnt_fetch+702 > 0x4178b5: CNT_Session+345 > 0x42e2d8: wrk_do_cnt_sess+b8 > 0x42e759: wrk_thread_real+409 > 0x7f0fa09239ca: _end+7f0fa02ac7b2 > 0x7f0fa068070d: _end+7f0fa00094f5 > sp = 0x7f0f55303008 { > fd = 16, id = 16, xid = 583115844, > client = XX.238.35.17 44993, > step = STP_FETCH, > handling = deliver, > err_code = 302, err_reason = (null), > restarts = 0, esi_level = 0 > ws = 0x7f0f55303080 { > id = "sess", > {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, > }, > http[req] = { > ws = 0x7f0f55303080[sess] > "GET", > "/trac/login", > "HTTP/1.1", > "Host: www.varnish-cache.org", > "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", > "Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > "Accept-Language: en-us,en;q=0.5", > "Accept-Encoding: gzip,deflate", > "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", > "Keep-Alive: 300", > "Referer: http://www.varnish- > cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", > "DNT: 1", > "Connection: keep-alive", > "Authorization: Basic a3d5OmVsaXRlcGlsb3Q=", > "X-Forwarded-For: XX.238.35.17", > "Cookie: trac_form_token=a37857f8a86982568d228037; > trac_session=dff0c9e82d61c90bf66255a1", > }, > worker = 0x7f0f54afdb80 { > ws = 0x7f0f54afdd10 { > id = "wrk", > {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, > }, > http[bereq] = { > ws = 0x7f0f54afdd10[wrk] > "GET", > "/trac/login", > > Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete > Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts > Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 > ESI 1.0 lacks final '/' > Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 > ESI 1.0 illegal end-tag > }}} New description: On fresh trunk code (6cd23c2). www.varnish-cache.org/login is crashing varnish. I don't think this happended earlier. Might be because we're now ESI-processing everything that is "text/*". Anyway, here is an assert. {{{ Mar 14 11:11:15 odd varnishd[17252]: Child (25776) died signal=6 Mar 14 11:11:15 odd varnishd[17252]: Child (25776) Panic message: Assert error in VGZ_Destroy(), cache_gzip.c line 387: Condition((deflateEnd(&vg->vz)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x423085: VGZ_Destroy+135 0x41b4ce: vfp_esi_end+16e 0x421b11: FetchBody+291 0x4161c2: cnt_fetch+702 0x4178b5: CNT_Session+345 0x42e2d8: wrk_do_cnt_sess+b8 0x42e759: wrk_thread_real+409 0x7f0fa09239ca: _end+7f0fa02ac7b2 0x7f0fa068070d: _end+7f0fa00094f5 sp = 0x7f0f55303008 { fd = 16, id = 16, xid = 583115844, client = XX.238.35.17 44993, step = STP_FETCH, handling = deliver, err_code = 302, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f0f55303080 { id = "sess", {s,f,r,e} = {0x7f0f55303cf0,+1048,(nil),+65536}, }, http[req] = { ws = 0x7f0f55303080[sess] "GET", "/trac/login", "HTTP/1.1", "Host: www.varnish-cache.org", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Encoding: gzip,deflate", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Referer: http://www.varnish- cache.org/trac/attachment/wiki/VCLExamples/varnish_vcl.pdf", "DNT: 1", "Connection: keep-alive", "X-Forwarded-For: XX.238.35.17", }, worker = 0x7f0f54afdb80 { ws = 0x7f0f54afdd10 { id = "wrk", {s,f,r,e} = {0x7f0f54aebb10,+896,(nil),+65536}, }, http[bereq] = { ws = 0x7f0f54afdd10[wrk] "GET", "/trac/login", Mar 14 11:11:15 odd varnishd[17252]: Child cleanup complete Mar 14 11:11:15 odd varnishd[17252]: child (26241) Started Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said Child starts Mar 14 11:11:15 odd varnishd[17252]: Child (26241) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said WARNING at 17397 ESI 1.0 lacks final '/' Mar 14 11:11:18 odd varnishd[17252]: Child (26241) said ERROR at 17403 ESI 1.0 illegal end-tag }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 10:01:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 10:01:46 -0000 Subject: [Varnish] #872: Assert error in VGZ_Destroy() In-Reply-To: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> References: <042.53dd981cdaf5c315b3175917490b73a0@varnish-cache.org> Message-ID: <051.524abd589f974309473306d0c306877c@varnish-cache.org> #872: Assert error in VGZ_Destroy() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [f6a5e7e0f8e23b3b19a296561d25818844226c6d]) Allways call with VGZ_FINISH for proper gzip termination. Fixes #872 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 11:48:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 11:48:11 -0000 Subject: [Varnish] #402: send_timeout cause connections to be prematurely closed In-Reply-To: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> References: <044.bf2bc76e5907dbe9bb2d89ac0241bc0b@varnish-cache.org> Message-ID: <053.b2ce396a8ac67ec75d1a0b042b847943@varnish-cache.org> #402: send_timeout cause connections to be prematurely closed --------------------------------------+------------------------------------- Reporter: havardf | Owner: perbu Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: fixed Keywords: send_timeout connections | --------------------------------------+------------------------------------- Changes (by perbu): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 13:47:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 13:47:47 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.a922f7f84473f110932e516ae906d170@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): New sighting of this bug. This time caught with panic.show. :-) {{{ Last panic at: Tue, 15 Mar 2011 13:09:05 GMT Assert error in ESI_Deliver(), cache_esi_deliver.c line 354: Condition(i == Z_OK || i == Z_STREAM_END) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cbe8: pan_ic+b8 0x41f778: ESI_Deliver+438 0x42f838: RES_WriteObj+248 0x416a70: cnt_deliver+230 0x4178fd: CNT_Session+31d 0x42e3a8: wrk_do_cnt_sess+b8 0x42e829: wrk_thread_real+409 0x7fcee90a79ca: _end+7fcee8a30752 0x7fcee8e0470d: _end+7fcee878d495 sp = 0x7fcedf81a008 { fd = 16, id = 16, xid = 626502088, client = 127.0.0.1 33245, step = STP_DELIVER, handling = deliver, restarts = 0, esi_level = 0 ws = 0x7fcedf81a080 { id = "sess", {s,f,r,e} = {0x7fcedf81acf0,+544,(nil),+65536}, }, http[req] = { ws = 0x7fcedf81a080[sess] "GET", "/trac/browser/bin/varnishd/storage_file.c?annotate=blame&rev=7b1256c46773a018884da22849c24ab7628fd2e9", "HTTP/1.0", "Host: www.varnish-cache.org", "X-Real-IP: 66.249.66.21", "X-Forwarded-Proto: https", "Connection: close", "Accept: */*", "From: googlebot(at)googlebot.com", "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "X-Forwarded-For: 127.0.0.1, 127.0.0.1", }, worker = 0x7fce9a5ecb80 { ws = 0x7fce9a5ecd10 { id = "wrk", {s,f,r,e} = {0x7fce9a5dab10,+112,(nil),+65536}, }, http[resp] = { ws = 0x7fce9a5ecd10[wrk] "HTTP/1.1", "200", "Ok", "Server: Apache/2.2.14 (Ubuntu)", Last panic at: Tue, 15 Mar 2011 13:09:05 GMT Assert error in ESI_Deliver(), cache_esi_deliver.c line 354: Condition(i == Z_OK || i == Z_STREAM_END) not true. thread = (cache-worker) ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cbe8: pan_ic+b8 0x41f778: ESI_Deliver+438 0x42f838: RES_WriteObj+248 0x416a70: cnt_deliver+230 0x4178fd: CNT_Session+31d 0x42e3a8: wrk_do_cnt_sess+b8 0x42e829: wrk_thread_real+409 0x7fcee90a79ca: _end+7fcee8a30752 0x7fcee8e0470d: _end+7fcee878d495 sp = 0x7fcedf81a008 { fd = 16, id = 16, xid = 626502088, client = 127.0.0.1 33245, step = STP_DELIVER, handling = deliver, restarts = 0, esi_level = 0 ws = 0x7fcedf81a080 { id = "sess", {s,f,r,e} = {0x7fcedf81acf0,+544,(nil),+65536}, }, http[req] = { ws = 0x7fcedf81a080[sess] "GET", "/trac/browser/bin/varnishd/storage_file.c?annotate=blame&rev=7b1256c46773a018884da22849c24ab7628fd2e9", "HTTP/1.0", "Host: www.varnish-cache.org", "X-Real-IP: 66.249.66.21", "X-Forwarded-Proto: https", "Connection: close", "Accept: */*", "From: googlebot(at)googlebot.com", "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "X-Forwarded-For: 127.0.0.1, 127.0.0.1", }, worker = 0x7fce9a5ecb80 { ws = 0x7fce9a5ecd10 { id = "wrk", {s,f,r,e} = {0x7fce9a5dab10,+112,(nil),+65536}, }, http[resp] = { ws = 0x7fce9a5ecd10[wrk] "HTTP/1.1", "200", "Ok", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Date: Tue, 15 Mar 2011 13:09:05 GMT", "X-Varnish: 626502088 626502078", "Age: 1", "Via: 1.1 varnish", "Connection: close", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fcebf8bb000 { xid = 626502078, ws = 0x7fcebf8bb018 { id = "obj", {s,f,r,e} = {0x7fcebf8bb238,+288,(nil),+312}, }, http[obj] = { ws = 0x7fcebf8bb018[obj] "HTTP/1.1", "Ok", "Date: Tue, 15 Mar 2011 13:09:02 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Encoding: gzip", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Content-Length: 166154", }, len = 166154, store = { 131072 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| b2 51 74 f1 77 0e 89 0c 70 55 c8 28 c9 cd 51 08 |.Qt.w...pU.(..Q.| 08 75 f2 f1 74 56 50 d2 d5 d7 0f 37 76 d6 d7 77 |.u..tVP....7v..w| 09 71 51 88 f0 08 f1 f5 51 30 d4 33 50 08 2e 29 |.qQ.....Q0.3P..)| [131008 more] }, 35082 { 58 4b dc 7b 97 2c c4 cd 91 dd 13 f1 eb f5 04 7b |XK.{.,.........{| fb 81 99 39 ec bf 5f bf 89 8f 3a 71 e4 92 34 c3 |...9.._...:q..4.| e0 f1 5f 61 bc 89 c6 47 ea 2a 56 c6 68 de 7a ca |.._a...G.*V.h.z.| b8 4e 52 11 78 20 17 5f 63 ce 6d a9 bb 13 54 45 |.NR.x ._c.m...TE| [35018 more] }, }, }, }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 14:08:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 14:08:08 -0000 Subject: [Varnish] #875: varnishadm requires an argument Message-ID: <042.93f852a2971a18e178be2d37cb749180@varnish-cache.org> #875: varnishadm requires an argument ------------------------+--------------------------------------------------- Reporter: perbu | Owner: tfheen Type: defect | Status: new Priority: lowest | Milestone: Component: varnishadm | Version: trunk Severity: trivial | Keywords: ------------------------+--------------------------------------------------- varnishadm should work without arguments and work the same way as varnishadm -n "" does. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 17:49:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 17:49:08 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty In-Reply-To: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> References: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> Message-ID: <051.63f556f49d57b0a764cbe80e3ed9a9fe@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: varnishncsa -------------------------+-------------------------------------------------- Comment(by jdzst): I have reproduced this behaviour succesfully in varnish 2.1.2 and 2.1.4 versions in a production environment. In a test environment with varnish trunk seems to work ok. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 17:49:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 17:49:55 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty In-Reply-To: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> References: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> Message-ID: <051.6c86d39ce001db79b56d9baaf5bf1b30@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: varnishncsa -------------------------+-------------------------------------------------- Comment(by jdzst): I have reproduced this problem in varnish 2.1.2 and 2.1.4 versions in a production environment. In a test environment with varnish trunk seems to work ok. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 15 19:40:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Mar 2011 19:40:01 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.7e77b0f1ad0c87d0a2a14a5dfe238230@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): This happens regularly. Seems to be triggered by the Googlebot every time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 16 09:56:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Mar 2011 09:56:15 -0000 Subject: [Varnish] #875: varnishadm requires an argument In-Reply-To: <042.93f852a2971a18e178be2d37cb749180@varnish-cache.org> References: <042.93f852a2971a18e178be2d37cb749180@varnish-cache.org> Message-ID: <051.ab8e188a21eefb6f4f3d6e597973c065@varnish-cache.org> #875: varnishadm requires an argument ------------------------+--------------------------------------------------- Reporter: perbu | Owner: tfheen Type: defect | Status: closed Priority: lowest | Milestone: Component: varnishadm | Version: trunk Severity: trivial | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [6c957b4d8acf6e1bea0814e2ef6b500fef7407b9]) Make varnishadm able to find args automatically varnishadm already supported -n for getting the connection arguments. However, unlike the other tools, you needed to pass an -n argument, it did not default to anything. It now uses the compiled-in default. Fixes: #875 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 16 10:54:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Mar 2011 10:54:58 -0000 Subject: [Varnish] #876: Can't start varnish: "SHMFILE owned by running varnishd master" Message-ID: <042.b152ffb1624d0390243a17893e133b5d@varnish-cache.org> #876: Can't start varnish: "SHMFILE owned by running varnishd master" -------------------+-------------------------------------------------------- Reporter: wijet | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.3 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Sometimes I can't start varnish, I'm keep getting the following error: {{{ storage_file: filename: /var/cache/varnish/todo-list-test.bin size 256 MB. SHMFILE owned by running varnishd master (pid=1891) (Use unique -n arguments if you want multiple instances.) }}} with different PID. What is interesting the PID doesn't belong to a varnish process. For starting varnish I use standard init.d script, which basically does {{{ /usr/sbin/varnishd -a localhost:9169 -T localhost:9170 -f /etc/varnish /todo-list-test.vcl -n todo-list-test -u varnish -g varnish -s file,/var/cache/varnish/todo- list-test.bin,256M }}} I'm not sure if that's really a problem with varnish, because when do "ps", process with PID 1891 doesn't exist. However, a directory for that process in /proc exists. cat /proc/1891/cmdline returns {{{ /usr/lib/erlang/erts-5.8/bin/beam.smp-Ww-Ktrue-A30-P1048576---root/usr/lib /erlang-prognameerl--- home/var/lib/rabbitmq---pa/usr/lib/rabbitmq/lib/rabbitmq_server-1.8.1/sbin /../ebin-noshell-noinput-srabbit- snamerabbit at cc-bootstart_sasl- kernelinet_default_listen_options[{nodelay,true}]- kernelinet_default_connect_options[{nodelay,true}]-saslerrlog_typeerror- kernelerror_logger{file,"/var/log/rabbitmq/rabbit at cc.log"}-saslsasl_error_logger{file,"/var/log/rabbitmq/rabbit @cc-sasl.log"}- os_monstart_cpu_suptrue-os_monstart_disksupfalse-os_monstart_memsupfalse- mnesiadir"/var/lib/rabbitmq/mnesia/rabbit at cc"- noshell-noinput }}} In this example there is rabbitmq-server, but that can be any other process. Restarting the process which is inside that /proc/PID/cmdline, resolves the problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 17 10:53:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Mar 2011 10:53:34 -0000 Subject: [Varnish] #877: ESI Documentation Message-ID: <043.6c2e6a5eaa85bb6fc6e501d19413e562@varnish-cache.org> #877: ESI Documentation --------------------+------------------------------------------------------- Reporter: peroni | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: 2.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- I don't know if others did struggle on this as well, but it took me some time to realize that esi processing doesn't work if the backend sends gzipped content. At lease I hope this assumption is correct - if so, could you please extend the documentation for that matter (http://www.varnish- cache.org/trac/wiki/ESIfeatures). Also, if it is possible, could you please suggest how one could use esi AND gzipped content? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Mar 18 11:29:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 18 Mar 2011 11:29:23 -0000 Subject: [Varnish] #876: Can't start varnish: "SHMFILE owned by running varnishd master" In-Reply-To: <042.b152ffb1624d0390243a17893e133b5d@varnish-cache.org> References: <042.b152ffb1624d0390243a17893e133b5d@varnish-cache.org> Message-ID: <051.d0c2fbb0e5e7a80a161d3b8af6983384@varnish-cache.org> #876: Can't start varnish: "SHMFILE owned by running varnishd master" -------------------+-------------------------------------------------------- Reporter: wijet | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.3 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by dbu): same here, with version 2.1.3. the cheapest fix was removing the file _.vsl living in the same folder as the .bin file. i think it is because i removed varnish from my autostarted services and now it just gets killed on shutdown, instead of shutting down properly. but this is kind of stupid, if the process dies for some reason on a server, it should be able to restart as fast as possible... varnishd (varnish-2.1.3 SVN ) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Mar 18 11:38:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 18 Mar 2011 11:38:58 -0000 Subject: [Varnish] #878: Varnish child dies with segfault when loading a VCL importing std vmod Message-ID: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> #878: Varnish child dies with segfault when loading a VCL importing std vmod -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: std vmod segfault | -------------------------------+-------------------------------------------- Hi. With a fresh compilation of trunk, if I take the default VCL file and just add "import std;" statement, a vcl.load of that VCL file causes the varnish child to segfault. The segfault does not occur when starting varnish but only if I do an explicit vcl.load of the file through CLI. From my investigations, it seems that the segfault occurs in the VGC_Init function, at the time Vmod_Func_std._init(&vmod_priv_std, &VCL_conf) is called. I can provide strace or gdb backtrace, if needed, but this is easy to reproduce. When investigating, I found that the init function of a vmod is called when the VCL is loaded. I think it should be called only when the VCL is "used", not when it's "loaded". Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 11:16:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 11:16:26 -0000 Subject: [Varnish] #878: Varnish child dies with segfault when loading a VCL importing std vmod In-Reply-To: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> References: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> Message-ID: <054.ff15b8e490687e06ba6213f99901d4eb@varnish-cache.org> #878: Varnish child dies with segfault when loading a VCL importing std vmod ----------------------+----------------------------------------------------- Reporter: tmagnien | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: std vmod segfault ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 12:12:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 12:12:00 -0000 Subject: [Varnish] #879: Panic message: Assert error in cnt_fetch(). In varnish 5ec2bb09c50629eafaabc9f6d6f43ae145e4f254 Message-ID: <043.bf223017088313af356149366e1070a7@varnish-cache.org> #879: Panic message: Assert error in cnt_fetch(). In varnish 5ec2bb09c50629eafaabc9f6d6f43ae145e4f254 --------------------+------------------------------------------------------- Reporter: kdajka | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: trunk | Severity: critical Keywords: | --------------------+------------------------------------------------------- Hi, I'm seeing child restarts in newest trunk 5ec2bb09c50629eafaabc9f6d6f43ae145e4f254. I have 3 backtraces all were triggered by Assert error in cnt_fetch(). All crashes occured few moments after malloc fulled up. My system: Linux varnishic06 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/xxx_varnishd.pid -a XXX.IP2.XXX.IP2:8084 -i xxx_varnishic06 -n xxx_varnishic06 -f /exp/config/varnish//xxx/xxx.vcl -T XXX.IP2.XXX.IP2:2084 -h classic,16383 -p thread_pools=4 -w 200,4000,2 -t 0 -s malloc,384M -d }}} {{{ Child (32672) died signal=6 (core dumped) Child (32672) Panic message: Assert error in cnt_fetch(), cache_center.c line 643: Condition((sp->obj) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.26-2-amd64,x86_64,-smalloc,-smalloc,-classic,epoll Backtrace: 0x433de5: pan_backtrace+16 0x43404e: pan_ic+164 0x418d2f: cnt_fetch+aaa 0x41b555: CNT_Session+5bc 0x435c67: wrk_do_cnt_sess+12a 0x4354d2: wrk_thread_real+841 0x4358d3: wrk_thread+e5 0x7fa02b9b0fc7: _end+7fa02b323a2f 0x7fa02b72664d: _end+7fa02b0990b5 sp = 0x7f9ecd38a008 { fd = 46, id = 46, xid = 1808471137, client = XXX.IP.XXX.IP 50479, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f9ecd38a080 { id = "sess", {s,f,r,e} = {0x7f9ecd38acf0,+1104,(nil),+65536}, }, http[req] = { ws = 0x7f9ecd38a080[sess] "GET", "/resource/konno.jpg", "HTTP/1.1", "Accept: */*", "Accept-Language: pl", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322)", "Host: xxx.xxx", "Connection: Keep-Alive", "x-real-forwarded-for: XXX.IP.XXX.IP", "X-Forwarded-For: XXX.IP.XXX.IP", "Accept-Encoding: gzip", }, worker = 0x7f9ed6962e30 { ws = 0x7f9ed6962fc0 { id = "wrk", {s,f,r,e} = {0x7f9ed6950d40,+3032,(nil),+65536}, }, http[bereq] = { ws = 0x7f9ed6962fc0[wrk] "GET", "/resource/konno.jpg", "HTTP/1.1", "Accept: */*", "Accept-Language: pl", "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322)", "Host: xxx.xxx", "x-real-forwarded-for: XXX.IP.XXX.IP", "X-Forwarded-For: XXX.IP.XXX.IP", "X-Varnish: 1808471137", "Accept-Encoding: gzip", }, http[beresp] = { ws = 0x7f9ed6962fc0[wrk] "HTTP/1.1", "200", "OK", "Date: Mon, 21 Mar 2011 10:30:44 GMT", "Server: Apache", "Cache-Control: PUBLIC, max-age=0, must-revalidate", "Last-Modified: Wed, 19 Jan 2011 20:02:07 GMT", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Connection: close", "Transfer-Encoding: chunked", "Content-Type: image/jpeg", "x-url: /resource/konno.jpg", }, }, vcl = { srcname = { "input", "Default", "/exp/config/varnish/xxxxx/backends_xxxxx.vcl", }, }, }, }}} Backtrace: {{{ (gdb) bt #0 0x00007fa02b688ed5 in raise () from /lib/libc.so.6 #1 0x00007fa02b68a3f3 in abort () from /lib/libc.so.6 #2 0x00000000004340fb in pan_ic (func=0x46b710 "cnt_fetch", file=0x46b536 "cache_center.c", line=643, cond=0x46b5e1 "(sp->obj) != NULL", err=0, xxx=0) at cache_panic.c:361 #3 0x0000000000418d2f in cnt_fetch (sp=0x7f9ecd38a008) at cache_center.c:643 #4 0x000000000041b555 in CNT_Session (sp=0x7f9ecd38a008) at steps.h:42 #5 0x0000000000435c67 in wrk_do_cnt_sess (w=0x7f9ed6962e30, priv=0x7f9ecd38a008) at cache_pool.c:302 #6 0x00000000004354d2 in wrk_thread_real (qp=0x7fa02b10e2e0, shm_workspace=8192, sess_workspace=65536, nhttp=64, http_space=1160, siov=128) at cache_pool.c:186 #7 0x00000000004358d3 in wrk_thread (priv=0x7fa02b10e2e0) at cache_pool.c:232 #8 0x00007fa02b9b0fc7 in start_thread () from /lib/libpthread.so.0 #9 0x00007fa02b72664d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004340fb in pan_ic (func=0x46b710 "cnt_fetch", file=0x46b536 "cache_center.c", line=643, cond=0x46b5e1 "(sp->obj) != NULL", err=0, xxx=0) at cache_panic.c:361 361 cache_panic.c: No such file or directory. in cache_panic.c (gdb) print *sp $1 = {magic = 741317722, fd = 46, id = 46, xid = 1808471137, restarts = 0, esi_level = 0, disable_esi = 0, hash_ignore_busy = 0 '\0', hash_always_miss = 0 '\0', wrk = 0x7f9ed6962e30, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x7f9ecd38a2e0, mysockaddr = 0x7f9ecd38a360, mylsock = 0x7fa02b120b80, addr = 0x7f9ecd38acf0 "XXX.IP.XXX.IP", port = 0x7f9ecd38ad00 "50479", client_identity = 0x0, doclose = 0x0, http = 0x7f9ecd38a3e0, http0 = 0x7f9ecd38a868, ws = {{magic = 905626964, id = 0x470b2e "sess", s = 0x7f9ecd38acf0 "XXX.IP.XXX.IP", f = 0x7f9ecd38b140 ".181", r = 0x0, e = 0x7f9ecd39acf0 "", overflow = 0}}, ws_ses = 0x7f9ecd38ad08 "GET", ws_req = 0x7f9ecd38b0c0 "XXX.IP.XXX.IP", digest = "g?g\004W?{\212\230\235?\001n??jSM\202G?1S?vj?JM?\200?", htc = {{magic = 1041886673, fd = 46, maxbytes = 32768, maxhdr = 2048, ws = 0x7f9ecd38a080, rxbuf = {b = 0x7f9ecd38ad08 "GET", e = 0x7f9ecd38b0bf ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1300703444.0800157, t_req = 1300703444.0800416, t_resp = nan(0x8000000000000), t_end = 1300703444.0800157, exp = { ttl = -1, grace = 30, keep = -1}, step = STP_FETCH, cur_method = 0, handling = 0, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 200, err_reason = 0x0, list = {vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x7fa02b10e568, vbc = 0x7f9ec87fb060, obj = 0x0, objcore = 0x7f9ec703bb00, vcl = 0x7fa02b1056e8, hash_objhead = 0x0, mem = 0x7f9ecd38a000, workreq = {list = { vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x435b3d , priv = 0x7f9ecd38a008}, acct_tmp = {first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_ses = {first = 1300703444.0800157, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, ev = {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 12:41:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 12:41:54 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish Message-ID: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Made a file with a huge (5G) hole in it. Nginx serves it, tried to get varnish to cache it. "curl -o /dev/null" as a client. Running trunk as of now: {{{ ./varnishd -a 0.0.0.0:8080 -b localhost:80 -d -s malloc,7G -T localhost:2001 }}} Crashes like this: {{{ Assert error in stv_alloc(), stevedore.c line 145: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.35-25-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42b788: pan_ic+b8 0x4439f5: STV_alloc+f5 0x4215fd: FetchStorage+5d 0x4216f4: vfp_nop_bytes+64 0x420e1b: FetchBody+94b 0x414db2: cnt_fetch+702 0x4164a5: CNT_Session+345 0x42cf48: wrk_do_cnt_sess+b8 0x42d3c9: wrk_thread_real+409 0x7f110907b971: _end+7f1108a056d9 sp = 0x7f10ffc08008 { fd = 10, id = 10, xid = 1036246089, client = 127.0.0.1 53191, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f10ffc08080 { id = "sess", {s,f,r,e} = {0x7f10ffc08cf0,+240,(nil),+65536}, }, http[req] = { ws = 0x7f10ffc08080[sess] "GET", "/5G-file", "HTTP/1.1", "User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18", "Host: localhost:8080", "Accept: */*", "X-Forwarded-For: 127.0.0.1", }, worker = 0x7f10f9feeb80 { ws = 0x7f10f9feed10 { id = "wrk", {s,f,r,e} = {0x7f10f9fdcb10,+272,(nil),+65536}, }, http[bereq] = { ws = 0x7f10f9feed10[wrk] "GET", "/5G-file", "HTTP/1.1", "User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18", "Host: localhost:8080", "Accept: */*", "X-Forwarded-For: 127.0.0.1", "X-Varnish: 1036246089", "Accept-Encoding: gzip", }, http[beresp] = { ws = 0x7f10f9feed10[wrk] "HTTP/1.1", "200", "OK", "Server: nginx/0.7.67", "Date: Mon, 21 Mar 2011 12:39:41 GMT", "Content-Type: text/plain", "Content-Length: 5242880000", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", "Connection: keep-alive", "Accept-Ranges: bytes", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f10ffa18300 { xid = 1036246089, ws = 0x7f10ffa18318 { id = "obj", {s,f,r,e} = {0x7f10ffa18508,+168,(nil),+224}, }, http[obj] = { ws = 0x7f10ffa18318[obj] "HTTP/1.1", "OK", "Server: nginx/0.7.67", "Date: Mon, 21 Mar 2011 12:39:41 GMT", "Content-Type: text/plain", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", }, len = 3221094400, store = { 947912704 { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [947912640 more] }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 12:59:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 12:59:04 -0000 Subject: [Varnish] #881: failure while fetching delivering large files with gzip enabled Message-ID: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> #881: failure while fetching delivering large files with gzip enabled --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Running trunk as of 2010-03-21. nginx is serving a 3Gbyte big file to Varnish. Varnish fails to deliver the file. Varnishlog: {{{ 10 SessionOpen c 127.0.0.1 59506 0.0.0.0:8080 10 Hit c 127.0.0.1 59506 1917798506 10 RxRequest c GET 10 RxURL c /3G 10 RxProtocol c HTTP/1.1 10 RxHeader c User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 10 RxHeader c Host: localhost:8080 10 RxHeader c Accept: */* 10 VCL_trace c recv 10 VCL_error c lookup 10 VCL_trace c hash 10 Backend_health c /3G 10 Backend_health c localhost:8080 10 VCL_error c hash 10 VCL_trace c miss 10 VCL_error c fetch 12 BackendOpen b default 127.0.0.1 51343 127.0.0.1 80 10 Backend c 12 default default 12 TxRequest b GET 12 TxURL b /3G 12 TxProtocol b HTTP/1.1 12 TxHeader b User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 12 TxHeader b Host: localhost:8080 12 TxHeader b Accept: */* 12 TxHeader b X-Forwarded-For: 127.0.0.1 12 TxHeader b X-Varnish: 1917798506 12 TxHeader b Accept-Encoding: gzip 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1300711772 1.0 12 RxProtocol b HTTP/1.1 12 RxStatus b 200 12 RxResponse b OK 12 RxHeader b Server: nginx/0.7.67 12 RxHeader b Date: Mon, 21 Mar 2011 12:49:31 GMT 12 RxHeader b Content-Type: text/plain 12 RxHeader b Content-Length: 3145728000 12 RxHeader b Last-Modified: Mon, 21 Mar 2011 12:48:35 GMT 12 RxHeader b Connection: keep-alive 12 RxHeader b Accept-Ranges: bytes 10 TTL c 1917798506 RFC 120 1.30071e+09 0 0 0 0 10 VCL_trace c fetch 10 VCL_error c deliver 10 ObjProtocol c HTTP/1.1 10 ObjResponse c OK 10 ObjProtocol c HTTP/1.1 10 ObjResponse c OK 10 ObjHeader c Server: nginx/0.7.67 10 ObjHeader c Date: Mon, 21 Mar 2011 12:49:31 GMT 10 ObjHeader c Content-Type: text/plain 10 ObjHeader c Last-Modified: Mon, 21 Mar 2011 12:48:35 GMT 12 VCL_acl b 4 0 1 12 Length b 3145728000 12 BackendReuse b default 10 SessionClose c remote closed 10 VCL_trace c deliver 10 VCL_error c deliver 10 TxProtocol c HTTP/1.1 10 TxStatus c 200 10 TxResponse c OK 10 TxHeader c Server: nginx/0.7.67 10 TxHeader c Content-Type: text/plain 10 TxHeader c Last-Modified: Mon, 21 Mar 2011 12:48:35 GMT 10 TxHeader c Content-Length: 3145728000 10 TxHeader c Accept-Ranges: bytes 10 TxHeader c Date: Mon, 21 Mar 2011 12:49:35 GMT 10 TxHeader c X-Varnish: 1917798506 10 TxHeader c Age: 4 10 TxHeader c Via: 1.1 varnish 10 TxHeader c Connection: keep-alive 10 Debug c "Write error, retval = -1, len = -1149239023, errno = Invalid argument" 4294967295 Length - 3145728000 10 ReqEnd c 1917798506 1300711771.843401909 1300711775.619403601 0.000154972 3.775942564 0.000059128 10 StatSess c 127.0.0.1 59506 4 1 1 0 0 1 273 3145728000 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 12:59:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 12:59:30 -0000 Subject: [Varnish] #881: failure while fetching delivering large files with gzip enabled In-Reply-To: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> References: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> Message-ID: <051.a0f136858e16dc64202582e2f1a3a408@varnish-cache.org> #881: failure while fetching delivering large files with gzip enabled --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): The file consists only of zeroes, btw. It's just one big hole. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 21 14:13:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Mar 2011 14:13:56 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.4365444bbaa2c435e90970a1a47657fa@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): One more, this time with -sfile: {{{ Child (7455) Panic message: Assert error in stv_alloc(), stevedore.c line 145: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.35-25-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42b788: pan_ic+b8 0x4439f5: STV_alloc+f5 0x4215fd: FetchStorage+5d 0x420def: FetchBody+91f 0x414db2: cnt_fetch+702 0x4164a5: CNT_Session+345 0x42cf48: wrk_do_cnt_sess+b8 0x42d3c9: wrk_thread_real+409 0x7fbe5df20971: _end+7fbe5d8aa6d9 0x7fbe5dc7c92d: _end+7fbe5d606695 sp = 0x7fbe54714008 { fd = 11, id = 11, xid = 338933910, client = 127.0.0.1 51551, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fbe54714080 { id = "sess", {s,f,r,e} = {0x7fbe54714cf0,+232,(nil),+65536}, }, http[req] = { ws = 0x7fbe54714080[sess] "GET", "/5G", "HTTP/1.1", "User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18", "Host: localhost:8080", "Accept: */*", "X-Forwarded-For: 127.0.0.1", }, worker = 0x7fbbd91e9b80 { ws = 0x7fbbd91e9d10 { id = "wrk", {s,f,r,e} = {0x7fbbd91d7b10,+272,(nil),+65536}, }, http[bereq] = { ws = 0x7fbbd91e9d10[wrk] "GET", "/5G", "HTTP/1.1", "User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18", "Host: localhost:8080", "Accept: */*", "X-Forwarded-For: 127.0.0.1", "X-Varnish: 338933910", "Accept-Encoding: gzip", }, http[beresp] = { ws = 0x7fbbd91e9d10[wrk] "HTTP/1.1", "200", "OK", "Server: nginx/0.7.67", "Date: Mon, 21 Mar 2011 14:12:06 GMT", "Content-Type: text/plain", "Content-Length: 5242880000", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", "Connection: keep-alive", "Accept-Ranges: bytes", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fbe2d150000 { xid = 338933910, ws = 0x7fbe2d150018 { id = "obj", {s,f,r,e} = {0x7fbe2d150208,+168,(nil),+224}, }, http[obj] = { ws = 0x7fbe2d150018[obj] "HTTP/1.1", "OK", "Server: nginx/0.7.67", "Date: Mon, 21 Mar 2011 14:12:06 GMT", "Content-Type: text/plain", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", }, len = 0, store = { }, }, }, Child cleanup complete }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 22 16:48:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Mar 2011 16:48:38 -0000 Subject: [Varnish] #882: Modify multiple X-Forwarded-For headers Message-ID: <043.34076a3323f094f4e72767bec2155ec5@varnish-cache.org> #882: Modify multiple X-Forwarded-For headers --------------------+------------------------------------------------------- Reporter: mkania | Type: enhancement Status: new | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: minor Keywords: | --------------------+------------------------------------------------------- I ran into a situation where requests coming into varnish have two X -Forwarded-For headers. I notice that varnish will only perform operations on the first X-Forwarded-For header, leaving me without the ability to modify the second X-Forwarded-For header. Would it be possible to be get access to headers with multiple X -Forwarded-For messages? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 24 00:42:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Mar 2011 00:42:37 -0000 Subject: [Varnish] #882: Modify multiple X-Forwarded-For headers In-Reply-To: <043.34076a3323f094f4e72767bec2155ec5@varnish-cache.org> References: <043.34076a3323f094f4e72767bec2155ec5@varnish-cache.org> Message-ID: <052.54a6441ee9de7cc39ca65190b88975dd@varnish-cache.org> #882: Modify multiple X-Forwarded-For headers --------------------+------------------------------------------------------- Reporter: mkania | Type: enhancement Status: new | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: minor Keywords: | --------------------+------------------------------------------------------- Comment(by soheil): This is a duplicate of this bug: http://www.varnish- cache.org/trac/ticket/866 It has been fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Mar 25 13:04:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Mar 2011 13:04:55 -0000 Subject: [Varnish] #878: Varnish child dies with segfault when loading a VCL importing std vmod In-Reply-To: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> References: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> Message-ID: <054.d42e55f478154f89a1c5cfbe63a4fd5c@varnish-cache.org> #878: Varnish child dies with segfault when loading a VCL importing std vmod ----------------------+----------------------------------------------------- Reporter: tmagnien | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: std vmod segfault ----------------------+----------------------------------------------------- Comment(by tmagnien): I made further investigations and here is what I found. In the generated VCL code, we have this function : {{{ static void VGC_Init(struct cli *cli) { VRT_Vmod_Init(&VGC_vmod_std, &Vmod_Func_std, sizeof(Vmod_Func_std), "std", "/usr/local/unmodified/lib/varnish/vmods/libvmod_std.so"); Vmod_Func_std._init(&vmod_priv_std, &VCL_conf); VRT_init_dir(cli, VCL_conf.director, "simple", VGC_backend__default, &vgc_dir_priv__default); VCL_conf.director[0] = VCL_conf.director[1]; } }}} What happens is that the 1st time the VCL is loaded (at startup for example), the Vmod_Func_std is filled by the VRT_Vmod_Init function. The second time the VCL is loaded (by a vcl.load), the VRT_Vmod_Init function is called with a Vmod_Func_std pointer value which is different. BUT, the VRT_Vmod_Init starts with : {{{ VTAILQ_FOREACH(v, &vmods, list) if (!strcmp(v->nm, nm)) break; }}} And as the std vmod is already loaded, it breaks. So the Vmod_Func_std is not populated, so value of Vmod_Func_std._init is NULL, which causes the segfault. Now I'll try to find the right way to correct this, without loading std vmod twice... Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Mar 25 13:15:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Mar 2011 13:15:18 -0000 Subject: [Varnish] #878: Varnish child dies with segfault when loading a VCL importing std vmod In-Reply-To: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> References: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> Message-ID: <054.4ed9222703d4820a70b26b43da124478@varnish-cache.org> #878: Varnish child dies with segfault when loading a VCL importing std vmod ----------------------+----------------------------------------------------- Reporter: tmagnien | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: std vmod segfault ----------------------+----------------------------------------------------- Comment(by tmagnien): Here is the patch I would propose : {{{ diff --git a/bin/varnishd/cache_vrt_vmod.c b/bin/varnishd/cache_vrt_vmod.c index 0c74e02..d61b1f4 100644 --- a/bin/varnishd/cache_vrt_vmod.c +++ b/bin/varnishd/cache_vrt_vmod.c @@ -73,8 +73,12 @@ VRT_Vmod_Init(void **hdl, void *ptr, int len, const char *nm, const char *path) ASSERT_CLI(); VTAILQ_FOREACH(v, &vmods, list) - if (!strcmp(v->nm, nm)) + if (!strcmp(v->nm, nm)) { + AN(v->funcs); + AN(v->funclen); + memcpy(ptr, v->funcs, v->funclen); break; + } if (v == NULL) { ALLOC_OBJ(v, VMOD_MAGIC); AN(v); }}} Regards,[[BR]] Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Mar 26 11:55:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 26 Mar 2011 11:55:45 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.fe309392fef705184ad70e0bf83e0ffb@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 ----------------------+----------------------------------------------------- Reporter: miohtama | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by miohtama): I did a clean reimaging of the server and I cannot repeat it on a new server. But this is what I believe happens: * The server has some faulty .so file * Normally this doesn't cause anything bad, as the file is not loaded and the error message is silently DLL loader. Because we are using system malloc which is safe, the error message is correctly allocated. * But when jemalloc is in place, the DLL loader, when loading some libraries, tries to allocate the memory for the error message and thus trying to call jemalloc which is not yet initalized I think the correct approach would be somehow have a special allocator in jemalloc before it is properly initialized. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 08:13:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 08:13:05 -0000 Subject: [Varnish] #878: Varnish child dies with segfault when loading a VCL importing std vmod In-Reply-To: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> References: <045.5b9352c6770628990a580ada2bca43c0@varnish-cache.org> Message-ID: <054.f300f736cc96d5e1089cf25344c4a17f@varnish-cache.org> #878: Varnish child dies with segfault when loading a VCL importing std vmod -------------------------------+-------------------------------------------- Reporter: tmagnien | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: std vmod segfault | -------------------------------+-------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in 3a56dbd Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 08:13:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 08:13:55 -0000 Subject: [Varnish] #882: Modify multiple X-Forwarded-For headers In-Reply-To: <043.34076a3323f094f4e72767bec2155ec5@varnish-cache.org> References: <043.34076a3323f094f4e72767bec2155ec5@varnish-cache.org> Message-ID: <052.4b4392cbcfeeafe7b60ec483fc851734@varnish-cache.org> #882: Modify multiple X-Forwarded-For headers ------------------------+--------------------------------------------------- Reporter: mkania | Type: enhancement Status: closed | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: minor Resolution: duplicate | Keywords: ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 08:15:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 08:15:20 -0000 Subject: [Varnish] #883: Memory leaking Message-ID: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> #883: Memory leaking --------------------------+------------------------------------------------- Reporter: arety | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: memory usage | --------------------------+------------------------------------------------- After upgrading from version 2.1.4 to 2.1.5, we began having problems with memory usage. We introduced no change in the vcl, but tried to reduce the cache size from 10GB to 9GB to see if it had any effect, which it did not. We use 'classic' hash algorithm, a 10GB malloc on a 16GB server (a vmware node). When reverting to 2.1.4, the problems went away. I attach some munin graphs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 08:27:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 08:27:18 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.fd18fe444b7f6580ddf8cfb9625d2a16@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [f378c80aec1e2b958d8bc9d67cb9fa203b5702fb]) If we fail to allocate storage, it can be because the request is too large to serve in one bite, so chop it down until we reach fetch_chunksize before we start LRU flushing to make space for it. Fixes #880 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 09:29:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 09:29:10 -0000 Subject: [Varnish] #881: failure while fetching delivering large files with gzip enabled In-Reply-To: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> References: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> Message-ID: <051.716087cc4f5d9912a7ec694908bb401b@varnish-cache.org> #881: failure while fetching delivering large files with gzip enabled --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by phk): Are you sure this is not just you client giving up ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 09:30:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 09:30:12 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.06a36441155dcadeb6637095ae720ddd@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by phk): Is this still happening ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 10:20:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 10:20:45 -0000 Subject: [Varnish] #883: Memory leaking In-Reply-To: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> References: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> Message-ID: <051.adfba788e2e1514c495bfa6bb07ceafa@varnish-cache.org> #883: Memory leaking ----------------------+----------------------------------------------------- Reporter: arety | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Keywords: memory usage ----------------------+----------------------------------------------------- Changes (by kristian): * owner: => kristian Comment: Can you provide output of varnishstat -1 for 2.1.4 and 2.1.5? Preferably after both has been running for a comparable amount of time. Some snippets of varnishlog would be useful too, to get the general gist of the traffic. And a test with -h crtibit (which is default and better tested). If you have more munin graphs easily available, that could also be useful (feel free to pack it into a tar-ball, which I suspect is more convenient than uploading individual graphs). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 10:24:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 10:24:17 -0000 Subject: [Varnish] #884: Assert error in res_WriteDirObj(), cache_response.c line 334 - while fetching large obj Message-ID: <042.07355d78aaf1383e1f05430ab2d0d7af@varnish-cache.org> #884: Assert error in res_WriteDirObj(), cache_response.c line 334 - while fetching large obj --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Fetch one big 5G file with all zeroes (hole) from backend (nginx). Command line: ./varnishd -a 0.0.0.0:8080 -b localhost:80 -d -s malloc,20G -T localhost:2001 Fetching with curl -o /dev/null http://localhost:8080/5G {{{ Last panic at: Mon, 28 Mar 2011 10:20:39 GMT Assert error in res_WriteDirObj(), cache_response.c line 334: Condition(u == sp->obj->len) not true. thread = (cache-worker) ident = Linux,2.6.35-28-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42b6b8: pan_ic+b8 0x42e3ea: RES_WriteObj+3ba 0x4156c0: cnt_deliver+230 0x41654d: CNT_Session+2ed 0x42ce78: wrk_do_cnt_sess+b8 0x42d301: wrk_thread_real+411 0x7f3d44ef4971: _end+7f3d4487e6d9 0x7f3d44c5092d: _end+7f3d445da695 sp = 0x7f3d39a03008 { fd = 10, id = 10, xid = 741837878, client = 127.0.0.1 41701, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f3d39a03080 { id = "sess", {s,f,r,e} = {0x7f3d39a03cf0,+232,(nil),+65536}, }, http[req] = { ws = 0x7f3d39a03080[sess] "GET", "/5G", "HTTP/1.1", "User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18", "Host: localhost:8080", "Accept: */*", "X-Forwarded-For: 127.0.0.1", }, worker = 0x7f3d359f6b70 { ws = 0x7f3d359f6d10 { id = "wrk", {s,f,r,e} = {0x7f3d359e4b00,+376,(nil),+65536}, }, http[resp] = { ws = 0x7f3d359f6d10[wrk] "HTTP/1.1", "200", "OK", "Server: nginx/0.7.67", "Content-Type: text/plain", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", "Content-Length: 947912704", "Accept-Ranges: bytes", "Date: Mon, 28 Mar 2011 10:20:39 GMT", "X-Varnish: 741837878", "Age: 21", "Via: 1.1 varnish", "Connection: keep-alive", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f3d35007300 { xid = 741837878, ws = 0x7f3d35007318 { id = "obj", {s,f,r,e} = {0x7f3d35007508,+200,(nil),+224}, }, http[obj] = { ws = 0x7f3d35007318[obj] "HTTP/1.1", "OK", "Server: nginx/0.7.67", "Date: Mon, 28 Mar 2011 10:20:17 GMT", "Content-Type: text/plain", "Last-Modified: Mon, 21 Mar 2011 12:23:12 GMT", "Content-Length: 947912704", }, len = 947912704, store = { 947912704 { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }}} ... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 10:24:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 10:24:33 -0000 Subject: [Varnish] #850: jemalloc fails to init on Ubuntu 8.04 In-Reply-To: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> References: <045.ff30f3e5367faa879e2904892fb3b45f@varnish-cache.org> Message-ID: <054.376f76645a0b5bd0b56f7e6bdd89364d@varnish-cache.org> #850: jemalloc fails to init on Ubuntu 8.04 ----------------------+----------------------------------------------------- Reporter: miohtama | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: 2.1.4 Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => invalid Comment: I'm closing this, as it's not really a Varnish-bug at this point, and it's only relevant for an old-ish distribution and not easily reproduced. If further work on this is required, it should probably either go through the varnish-dev-list (with patches) and/or to jemalloc. On the up-side, this bug-report might serve as a record for others who potentially run into the same problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 11:22:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 11:22:49 -0000 Subject: [Varnish] #883: Memory leaking In-Reply-To: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> References: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> Message-ID: <051.c418d3915dfdbf7651bec0903c14e768@varnish-cache.org> #883: Memory leaking ----------------------+----------------------------------------------------- Reporter: arety | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Keywords: memory usage ----------------------+----------------------------------------------------- Comment(by arety): As the problem was seen in production only, I cannot go back to 2.1.5 to compare "varnishstat -1" output. As for varnishlog, I can send you a direct email with some output from the running (2.1.4) version, but I can't add it here because it contains customer sensitive data. I didn't save any log from 2.1.5, I'm afraid. I added the munin-graphs I saved, which was the ones that most clearly showed problems. We had no visible changes in request rates, hit rates, backend traffic, and similar. But the load and swap graphs did off course show the problems, but I did not save them. That said, I to have another 2.1.5-based frontend. We don't have the same problems here, but the symptoms of leakage are present. I will talk with the customer about testing critbit and collect compareable data. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Mar 28 12:12:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Mar 2011 12:12:33 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.49092273182c2bfbd8c85bdb1871d093@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): Yes. Updated with fresh trunk... {{{ Last panic at: Mon, 28 Mar 2011 11:57:26 GMT Assert error in ESI_Deliver(), cache_esi_deliver.c line 331: Condition(i == Z_OK || i == Z_STREAM_END) not true. thread = (cache-worker) ident = Linux,2.6.32-29-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cb18: pan_ic+b8 0x41f6c6: ESI_Deliver+3f6 0x42f6b8: RES_WriteObj+228 0x416b40: cnt_deliver+230 0x4179cd: CNT_Session+2ed 0x42e2d8: wrk_do_cnt_sess+b8 0x42e761: wrk_thread_real+411 0x7f2c20d169ca: _end+7f2c2069f752 0x7f2c20a7370d: _end+7f2c203fc495 sp = 0x7f2bcb768008 { fd = 15, id = 15, xid = 1827804139, client = 66.249.66.180 45736, step = STP_DELIVER, handling = deliver, restarts = 0, esi_level = 0 ws = 0x7f2bcb768080 { id = "sess", {s,f,r,e} = {0x7f2bcb768cf0,+496,(nil),+65536}, }, http[req] = { ws = 0x7f2bcb768080[sess] "GET", "/trac/changeset/84c940a80c7be1cf588dcb10bf739f0bc78e2112/bin?old=4a1a64aec1808fcdab4eb84372217ca3ea99cdd9&old_path=bin", "HTTP/1.1", "Host: www.varnish-cache.org", "Connection: Keep-alive", "Accept: */*", "From: googlebot(at)googlebot.com", "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "X-Forwarded-For: 66.249.66.180, 66.249.66.180", }, worker = 0x7f2c19afcb70 { ws = 0x7f2c19afcd10 { id = "wrk", {s,f,r,e} = {0x7f2c19aeab00,+152,(nil),+65536}, }, http[resp] = { ws = 0x7f2c19afcd10[wrk] "HTTP/1.1", "200", "Ok", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Transfer-Encoding: chunked", .. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 29 12:42:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Mar 2011 12:42:57 -0000 Subject: [Varnish] #877: ESI Documentation In-Reply-To: <043.6c2e6a5eaa85bb6fc6e501d19413e562@varnish-cache.org> References: <043.6c2e6a5eaa85bb6fc6e501d19413e562@varnish-cache.org> Message-ID: <052.229e08551201d1a11bedf62798ba5ad7@varnish-cache.org> #877: ESI Documentation ---------------------------+------------------------------------------------ Reporter: peroni | Owner: perbu Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: normal | Keywords: ---------------------------+------------------------------------------------ Changes (by perbu): * owner: => perbu -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Mar 29 12:45:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Mar 2011 12:45:19 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.545eecca16ed69402bd798a48d098e79@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): This still happends (8850b659c74a9a5b7738bd5e3b597e96283e4382 - Tue Mar 29 09:52:00 2011 +0200), I'm afraid. Today, it was triggered by the MSN-bot. {{{ Assert error in ESI_Deliver(), cache_esi_deliver.c line 327: Condition(i >= VGZ_OK) not true. thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cc18: pan_ic+b8 0x41fb6d: ESI_Deliver+89d 0x42f7a8: RES_WriteObj+228 0x416b40: cnt_deliver+230 0x4179cd: CNT_Session+2ed 0x42e3d8: wrk_do_cnt_sess+b8 0x42e861: wrk_thread_real+411 0x7f1d967519ca: _end+7f1d960d9752 0x7f1d964ae70d: _end+7f1d95e36495 sp = 0x7f1d46957008 { fd = 15, id = 15, xid = 1192355132, client = 65.55.3.173 36710, step = STP_DELIVER, handling = deliver, restarts = 0, esi_level = 0 ws = 0x7f1d46957080 { id = "sess", {s,f,r,e} = {0x7f1d46957cf0,+392,(nil),+65536}, }, http[req] = { ws = 0x7f1d46957080[sess] "GET", "/trac/timeline?from=2008-07-16T11%3A14%3A47%2B0200&precision=second", "HTTP/1.0", "Accept: */*", "From: msnbotf(at)microsoft.com", "Host: www.varnish-cache.org", "User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm)._", "X-Forwarded-For: 65.55.3.173, 65.55.3.173", }, worker = 0x7f1d49cf0b70 { ws = 0x7f1d49cf0d10 { id = "wrk", {s,f,r,e} = {0x7f1d49cdeb00,+120,(nil),+65536}, }, http[resp] = { ws = 0x7f1d49cf0d10[wrk] "HTTP/1.1", "200", "Ok", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Date: Tue, 29 Mar 2011 11:15:14 GMT", }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 09:24:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 09:24:47 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.9c0b8338e0f3f72adc53a6b1aeea986a@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): For what its worth; This seem always to happen with objects that are either 0 or 1 seconds old. Always hits. Grace is on per default. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 10:15:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 10:15:49 -0000 Subject: [Varnish] #885: startup crash Message-ID: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> #885: startup crash --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Just started varnishd with fresh source (2e3b5a5d3256f2f917019bd3b8c4253c0e0a0d1f) cmd line: {{{ ./varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default-3.0.vcl -S /etc/varnish/secret -p cli_timeout=60 -p http_gzip_support=on -p esi_syntax=0x00000001 -s file,/var/lib/varnish/odd/varnish_storage.bin,1G -p ban_lurker_sleep=1 }}} It crashed right away: {{{ Last panic at: Wed, 30 Mar 2011 10:13:05 GMT Assert error in VGZ_Gunzip(), cache_gzip.c line 292: Condition((vg->vz.avail_out) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cca8: pan_ic+b8 0x423895: VGZ_Gunzip+e5 0x423e80: VGZ_WrwGunzip+a0 0x42f4f7: res_WriteGunzipObj+167 0x42f723: RES_WriteObj+153 0x416b70: cnt_deliver+230 0x4179fd: CNT_Session+2ed 0x42e468: wrk_do_cnt_sess+b8 0x42e8f1: wrk_thread_real+411 0x7fde6dec79ca: _end+7fde6d84f752 sp = 0x7fde22303008 { fd = 12, id = 12, xid = 917869269, client = 89.150.191.204 39891, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fde22303080 { id = "sess", {s,f,r,e} = {0x7fde22303cf0,+392,(nil),+65536}, }, http[req] = { ws = 0x7fde22303080[sess] "GET", "/rss.xml", "HTTP/1.1", "User-Agent: Java/1.6.0_24", "Host: www.varnish-cache.org", "Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2", "Connection: keep-alive", "If-Modified-Since: Wed, 30 Mar 2011 07:12:43 GMT", "X-Forwarded-For: 89.150.191.204, 89.150.191.204", }, worker = 0x7fde1eaf7b70 { ws = 0x7fde1eaf7d10 { id = "wrk", {s,f,r,e} = {0x7fde1eae5b00,+2680,(nil),+65536}, }, http[resp] = { ws = 0x7fde1eaf7d10[wrk] "HTTP/1.1", "200", "OK", "Server: Apache/2.2.14 (Ubuntu)", "X-Powered-By: PHP/5.3.2-1ubuntu4.7", "Cache-Control: public, max-age=43200", "Last-Modified: Wed, 30 Mar 2011 10:13:05 +0000", "Expires: Sun, 11 Mar 1984 12:00:00 GMT", "Vary: Cookie,Accept-Encoding", "ETag: "1301479985"", "Content-Type: application/rss+xml; charset=utf-8", "X-ESI: off", "Transfer-Encoding: chunked", "Date: Wed, 30 Mar 2011 10:13:05 GMT", "X-Varnish: 917869269", "Age: 0", "Via: 1.1 varnish", "Connection: keep-alive", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fde44700000 { xid = 917869269, ws = 0x7fde44700018 { id = "obj", {s,f,r,e} = {0x7fde44700280,+472,(nil),+504}, }, http[obj] = { ws = 0x7fde44700018[obj] "HTTP/1.1", "OK", "Date: Wed, 30 Mar 2011 10:13:05 GMT", "Server: Apache/2.2.14 (Ubuntu)", "X-Powered-By: PHP/5.3.2-1ubuntu4.7", "Cache-Control: public, max-age=43200", "Last-Modified: Wed, 30 Mar 2011 10:13:05 +0000", "Expires: Sun, 11 Mar 1984 12:00:00 GMT", vcl = { srcname = { "input", "Default", }, }, obj = 0x7fde44700000 { xid = 917869269, ws = 0x7fde44700018 { id = "obj", {s,f,r,e} = {0x7fde44700280,+472,(nil),+504}, }, http[obj] = { ws = 0x7fde44700018[obj] "HTTP/1.1", "OK", "Date: Wed, 30 Mar 2011 10:13:05 GMT", "Server: Apache/2.2.14 (Ubuntu)", "X-Powered-By: PHP/5.3.2-1ubuntu4.7", "Cache-Control: public, max-age=43200", "Last-Modified: Wed, 30 Mar 2011 10:13:05 +0000", "Expires: Sun, 11 Mar 1984 12:00:00 GMT", "Vary: Cookie,Accept-Encoding", "ETag: "1301479985"", "Content-Encoding: gzip", "Content-Type: application/rss+xml; charset=utf-8", "X-ESI: off", "Content-Length: 2083", }, len = 2083, store = { 2083 { 1f 8b 08 00 00 00 00 00 00 03 e5 5a db 6e dc 46 |...........Z.n.F| 12 7d f6 00 f9 87 82 16 f0 cb 7a c8 b9 48 b1 3d |.}........z..H.=| 96 15 d8 56 02 7b 11 5f b0 72 2e 6f 41 93 2c 0e |...V.{._.r.oA.,.| db 22 bb e9 be 68 3c f9 fa 3d dd 24 75 89 35 e3 |."...h<..=.$u.5.| [2019 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 10:21:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 10:21:04 -0000 Subject: [Varnish] #885: startup crash In-Reply-To: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> References: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> Message-ID: <051.b7c4b2fbce7649ebb5eb010f6fad2632@varnish-cache.org> #885: startup crash --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): Last panic at: Wed, 30 Mar 2011 10:18:05 GMT Assert error in VGZ_Gunzip(), cache_gzip.c line 292: Condition((vg->vz.avail_out) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cca8: pan_ic+b8 0x423895: VGZ_Gunzip+e5 0x423e80: VGZ_WrwGunzip+a0 0x42f4f7: res_WriteGunzipObj+167 0x42f723: RES_WriteObj+153 0x416b70: cnt_deliver+230 0x4179fd: CNT_Session+2ed 0x42e468: wrk_do_cnt_sess+b8 0x42e8f1: wrk_thread_real+411 0x7fde6dec79ca: _end+7fde6d84f752 sp = 0x7fde67dc0008 { fd = 15, id = 15, xid = 1594564478, client = 114.127.246.101 64924, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fde67dc0080 { id = "sess", {s,f,r,e} = {0x7fde67dc0cf0,+328,(nil),+65536}, }, http[req] = { ws = 0x7fde67dc0080[sess] "GET", "/rss.xml", "HTTP/1.1", "Host: www.varnish-cache.org", "Cache-Control: max-stale=0", "Connection: Keep-Alive", "X-BlueCoat-Via: 1148684082717A35", "X-Forwarded-For: 114.127.246.101, 114.127.246.101", }, worker = 0x7fde212efb70 { ws = 0x7fde212efd10 { id = "wrk", {s,f,r,e} = {0x7fde212ddb00,+2680,(nil),+65536}, }, http[resp] = { ws = 0x7fde212efd10[wrk] "HTTP/1.1", "200", "OK", "Server: Apache/2.2.14 (Ubuntu)", "X-Powered-By: PHP/5.3.2-1ubuntu4.7", "Cache-Control: public, max-age=43200", "Last-Modified: Wed, 30 Mar 2011 10:18:05 +0000", "Expires: Sun, 11 Mar 1984 12:00:00 GMT", "Vary: Cookie,Accept-Encoding", "ETag: "1301480285"", "Content-Type: application/rss+xml; charset=utf-8", "X-ESI: off", "Transfer-Encoding: chunked", "Date: Wed, 30 Mar 2011 10:18:05 GMT", "X-Varnish: 1594564478", "Age: 0", "Via: 1.1 varnish", "Connection: keep-alive", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fde44502000 { xid = 1594564478, ws = 0x7fde44502018 { id = "obj", {s,f,r,e} = {0x7fde44502280,+472,(nil),+504}, }, http[obj] = { ws = 0x7fde44502018[obj] "HTTP/1.1", "OK", "Date: Wed, 30 Mar 2011 10:18:05 GMT", "Server: Apache/2.2.14 (Ubuntu)", "X-Powered-By: PHP/5.3.2-1ubuntu4.7", "Cache-Control: public, max-age=43200", "Last-Modified: Wed, 30 Mar 2011 10:18:05 +0000", "Expires: Sun, 11 Mar 1984 12:00:00 GMT", "Vary: Cookie,Accept-Encoding", "ETag: "1301480285"", "Content-Encoding: gzip", "Content-Type: application/rss+xml; charset=utf-8", "X-ESI: off", "Content-Length: 2083", }, len = 2083, store = { 2083 { 1f 8b 08 00 00 00 00 00 00 03 e5 5a db 6e dc 46 |...........Z.n.F| 12 7d f6 00 f9 87 82 16 f0 cb 7a c8 b9 48 b1 3d |.}........z..H.=| 96 15 d8 56 02 7b 11 5f b0 72 2e 6f 41 93 2c 0e |...V.{._.r.oA.,.| db 22 bb e9 be 68 3c f9 fa 3d dd 24 75 89 35 e3 |."...h<..=.$u.5.| [2019 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 10:22:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 10:22:18 -0000 Subject: [Varnish] #885: startup crash In-Reply-To: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> References: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> Message-ID: <051.78ac9a14b48d49c741fe408919ffb9a9@varnish-cache.org> #885: startup crash --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): {{{ Last panic at: Wed, 30 Mar 2011 10:18:26 GMT Assert error in VGZ_Gunzip(), cache_gzip.c line 292: Condition((vg->vz.avail_out) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42cca8: pan_ic+b8 0x423895: VGZ_Gunzip+e5 0x423e80: VGZ_WrwGunzip+a0 0x41f6c9: ESI_Deliver+3c9 0x42f7f8: RES_WriteObj+228 0x416b70: cnt_deliver+230 0x4179fd: CNT_Session+2ed 0x42e468: wrk_do_cnt_sess+b8 0x42e8f1: wrk_thread_real+411 0x7fde6dec79ca: _end+7fde6d84f752 sp = 0x7fde22025008 { fd = 16, id = 16, xid = 1332626185, client = 81.169.185.227 46241, step = STP_DELIVER, handling = deliver, err_code = 301, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7fde22025080 { id = "sess", {s,f,r,e} = {0x7fde22025cf0,+408,(nil),+65536}, }, http[req] = { ws = 0x7fde22025080[sess] "GET", "/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss", "HTTP/1.0", "Host: www.varnish-cache.org", "User-Agent: WordPress/2.9.2; http://cachingchronicles.com", "X-Forwarded-For: 81.169.185.227, 81.169.185.227", }, worker = 0x7fde20ffcb70 { ws = 0x7fde20ffcd10 { id = "wrk", {s,f,r,e} = {0x7fde20feab00,+1120,(nil),+65536}, }, http[resp] = { ws = 0x7fde20ffcd10[wrk] "HTTP/1.1", "301", "Moved Permanently", "Server: Apache/2.2.14 (Ubuntu)", "Location: http://www.varnish- cache.org/trac/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss", "Vary: Accept-Encoding", "Content-Type: text/html; charset=iso-8859-1", "X-ESI: on", "Date: Wed, 30 Mar 2011 10:18:26 GMT", "X-Varnish: 1332626185", "Server: Apache/2.2.14 (Ubuntu)", "Location: http://www.varnish- cache.org/trac/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss", "Vary: Accept-Encoding", "Content-Type: text/html; charset=iso-8859-1", "X-ESI: on", "Date: Wed, 30 Mar 2011 10:18:26 GMT", "X-Varnish: 1332626185", "Age: 0", "Via: 1.1 varnish", "Connection: close", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fde44407000 { xid = 1332626185, ws = 0x7fde44407018 { id = "obj", {s,f,r,e} = {0x7fde44407238,+400,(nil),+424}, }, http[obj] = { ws = 0x7fde44407018[obj] "HTTP/1.1", "Moved Permanently", "Date: Wed, 30 Mar 2011 10:18:26 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Location: http://www.varnish- cache.org/trac/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss", "Vary: Accept-Encoding", "Content-Encoding: gzip", "Content-Type: text/html; charset=iso-8859-1", "X-ESI: on", "Content-Length: 358", }, len = 358, store = { 358 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| 6c 8b b1 0e c2 20 14 45 77 be e2 d9 5d 5f ab eb |l.... .Ew...]_..| 0b 83 05 63 93 56 3b e0 e0 88 42 42 13 28 46 d1 |...c.V;...BB.(F.| a4 7f 2f b6 ab e3 3d e7 5c 5a 89 73 ad ae bd 84 |../...=.\Z.s....| [294 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 11:14:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 11:14:10 -0000 Subject: [Varnish] #886: Ban-related crashes Message-ID: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I'm getting crashes in both the ban lurker and through esi-parsing (that might be co-incidental). It all boils down to: {{{ Program terminated with signal 11, Segmentation fault. #0 ban_check_object (o=0x2aaab0861800, sp=0x2aaaab000008, has_req=0) at cache_ban.c:448 448 if (b->flags & BAN_F_GONE) (gdb) bt #0 ban_check_object (o=0x2aaab0861800, sp=0x2aaaab000008, has_req=0) at cache_ban.c:448 #1 0x0000000000413549 in ban_lurker (sp=0x2aaaab000008, priv=) at cache_ban.c:544 #2 0x000000000042c69c in wrk_bgthread (arg=0x2af972b043c0) at cache_pool.c:581 #3 0x0000003aac40673d in start_thread () from /lib64/libpthread.so.0 #4 0x0000003aabcd3f6d in clone () from /lib64/libc.so.6 }}} Or, in the case of "esi"/request-path: {{{ Program terminated with signal 11, Segmentation fault. #0 ban_check_object (o=0x2aaab0099900, sp=0x2aaab3d00008, has_req=1) at cache_ban.c:448 448 if (b->flags & BAN_F_GONE) (gdb) bt #0 ban_check_object (o=0x2aaab0099900, sp=0x2aaab3d00008, has_req=1) at cache_ban.c:448 #1 0x000000000042449c in HSH_Lookup (sp=0x2aaab3d00008, poh=0x527e5578) at cache_hash.c:359 #2 0x0000000000413d80 in cnt_lookup (sp=0x2aaab3d00008) at cache_center.c:891 #3 0x00000000004165f9 in CNT_Session (sp=0x2aaab3d00008) at steps.h:39 #4 0x000000000041dcc7 in ved_include (sp=0x2aaab3d00008) at cache_esi_deliver.c:104 #5 ESI_Deliver (sp=0x2aaab3d00008) at cache_esi_deliver.c:366 #6 0x000000000042cf38 in RES_WriteObj (sp=0x2aaab3d00008) at cache_response.c:380 #7 0x00000000004155e0 in cnt_deliver (sp=0x2aaab3d00008) at cache_center.c:241 #8 0x0000000000416489 in CNT_Session (sp=0x2aaab3d00008) at steps.h:44 #9 0x000000000042c8d8 in wrk_do_cnt_sess (w=0x52800de0, priv=) at cache_pool.c:303 #10 0x000000000042babf in wrk_thread_real (qp=0x2af972b0b100, shm_workspace=, sess_workspace=65536, nhttp=64, http_space=, siov=128) at cache_pool.c:187 #11 0x0000003aac40673d in start_thread () from /lib64/libpthread.so.0 #12 0x0000003aabcd3f6d in clone () from /lib64/libc.so.6 (gdb) frame 0 #0 ban_check_object (o=0x2aaab0099900, sp=0x2aaab3d00008, has_req=1) at cache_ban.c:448 448 if (b->flags & BAN_F_GONE) (gdb) display b (gdb) print b $1 = (struct ban *) 0x0 (gdb) display b0 (gdb) print b0 $2 = (struct ban * volatile) 0x2aaab06e78e0 (gdb) print *b0 $3 = {magic = 1879771370, list = {vtqe_next = 0x2aaaafbf8820, vtqe_prev = 0x66fdc0}, refcount = 3034, flags = 0, tests = { vtqh_first = 0x2aaaae150080, vtqh_last = 0x2aaaae150088}, objcore = {vtqh_first = 0x2aaab0a3b4a0, vtqh_last = 0x2aaab0068728}, t0 = 1301480974.880106, vsb = 0x0, test = 0x2aaaafbf70a0 "obj.http.cache-control ~ group=%22/sec25171%22"} (gdb) display *b0->list->vtqe_next (gdb) display *(b0->list->vtqe_next) (gdb) print *(b0->list->vtqe_next) $4 = {magic = 1879771370, list = {vtqe_next = 0x2aaab0a4f400, vtqe_prev = 0x2aaab06e78e8}, refcount = 0, flags = 0, tests = { vtqh_first = 0x2aaaae150040, vtqh_last = 0x2aaaae150048}, objcore = {vtqh_first = 0x0, vtqh_last = 0x2aaaafbf8850}, t0 = 1301480974.87623, vsb = 0x0, test = 0x2aaaafbf7070 "obj.http.cache- control ~ group=%22/sec171%22"} (gdb) print *(b0->list->vtqe_next->list->vtqe_next) $5 = {magic = 1879771370, list = {vtqe_next = 0x0, vtqe_prev = 0x2aaaafbf8828}, refcount = 610, flags = 1, tests = { vtqh_first = 0x2aaaabd8b080, vtqh_last = 0x2aaaabd8b088}, objcore = {vtqh_first = 0x2aaab0068820, vtqh_last = 0x2aaaafa95028}, t0 = 1301480969.8811419, vsb = 0x0, test = 0x2aaab0a33070 "obj.http.cache-control ~ group=%22/sec25171%22"} (gdb) print oc->ban $6 = (struct ban *) 0x2aaab06e78e0 (gdb) print *oc->ban $7 = {magic = 1879771370, list = {vtqe_next = 0x2aaaafbf8820, vtqe_prev = 0x66fdc0}, refcount = 3034, flags = 0, tests = { vtqh_first = 0x2aaaae150080, vtqh_last = 0x2aaaae150088}, objcore = {vtqh_first = 0x2aaab0a3b4a0, vtqh_last = 0x2aaab0068728}, t0 = 1301480974.880106, vsb = 0x0, test = 0x2aaaafbf70a0 "obj.http.cache-control ~ group=%22/sec25171%22"} (gdb) print *oc $8 = {magic = 1294996226, refcnt = 2, methods = 0x671400, priv = 0x2aaab0099900, priv2 = 0, objhead = 0x2aaab00687b0, timer_when = 1301595397.7503209, flags = 0, timer_idx = 2661, list = {vtqe_next = 0x0, vtqe_prev = 0x2aaab00687c8}, lru_list = {vtqe_next = 0x2aaab0068820, vtqe_prev = 0x2aaaafac7408}, ban_list = {vtqe_next = 0x0, vtqe_prev = 0x2aaab0068648}, ban = 0x2aaab06e78e0} (gdb) bt #0 ban_check_object (o=0x2aaab0099900, sp=0x2aaab3d00008, has_req=1) at cache_ban.c:448 #1 0x000000000042449c in HSH_Lookup (sp=0x2aaab3d00008, poh=0x527e5578) at cache_hash.c:359 #2 0x0000000000413d80 in cnt_lookup (sp=0x2aaab3d00008) at cache_center.c:891 #3 0x00000000004165f9 in CNT_Session (sp=0x2aaab3d00008) at steps.h:39 #4 0x000000000041dcc7 in ved_include (sp=0x2aaab3d00008) at cache_esi_deliver.c:104 #5 ESI_Deliver (sp=0x2aaab3d00008) at cache_esi_deliver.c:366 #6 0x000000000042cf38 in RES_WriteObj (sp=0x2aaab3d00008) at cache_response.c:380 #7 0x00000000004155e0 in cnt_deliver (sp=0x2aaab3d00008) at cache_center.c:241 #8 0x0000000000416489 in CNT_Session (sp=0x2aaab3d00008) at steps.h:44 #9 0x000000000042c8d8 in wrk_do_cnt_sess (w=0x52800de0, priv=) at cache_pool.c:303 #10 0x000000000042babf in wrk_thread_real (qp=0x2af972b0b100, shm_workspace=, sess_workspace=65536, nhttp=64, http_space=, siov=128) at cache_pool.c:187 #11 0x0000003aac40673d in start_thread () from /lib64/libpthread.so.0 #12 0x0000003aabcd3f6d in clone () from /lib64/libc.so.6 (gdb) quit }}} Note that this essentially boils down to oc->ban == b0, even after the test a few lines above. The server is running varnishd (varnish-trunk revision e01527c) and is seeing frequent bans. There's no live-traffic, but I trigger this fairly easily with a wget -p over a front page (In a manner of minutes). I'm about to test without the ban lurker to see if that's the only way to trigger it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 15:08:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 15:08:06 -0000 Subject: [Varnish] #885: startup crash In-Reply-To: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> References: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> Message-ID: <051.0804d2f234e86f30b494ffd9a71d1c60@varnish-cache.org> #885: startup crash --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): There seem two be two sitations where this assert gets triggered: 1) Trace looks like:{{{ 0x42cca8: pan_ic+b8 0x423895: VGZ_Gunzip+e5 0x423e80: VGZ_WrwGunzip+a0 0x42f4f7: res_WriteGunzipObj+167 0x42f723: RES_WriteObj+153 }}} 2) Trace looks like: {{{ 0x42cca8: pan_ic+b8 0x423895: VGZ_Gunzip+e5 0x423e80: VGZ_WrwGunzip+a0 0x41f6c9: ESI_Deliver+3c9 0x42f7f8: RES_WriteObj+228 }}} 2) seems still to be occurring. Let me know if you want a core. Full panic is available on ~perbu/panic on odd (www.varnish-cache.org). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Mar 30 15:36:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Mar 2011 15:36:52 -0000 Subject: [Varnish] #887: Varnish caches objects with negative max-age Message-ID: <041.78ea9a5973c5cd58283bf4236206a80a@varnish-cache.org> #887: Varnish caches objects with negative max-age -------------------------------------------+-------------------------------- Reporter: niko | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: negative max-age, past expire | -------------------------------------------+-------------------------------- Varnish caches objects with negative max-age and/or (?) past expire header. I'm using varnishd (varnish-trunk revision 5ec2bb0). To debug I set a X-TTL header: {{{ sub vcl_fetch { set beresp.http.X-TTL = beresp.ttl; } }}} Here is an example request: {{{ curl -i localhost:8080/station/eins-test/current_song HTTP/1.1 200 OK Status: 200 OK Content-Type: application/json; charset=utf-8 Cache-Control: public, must-revalidate, max-age=-1301498973 Expires: Thu, 01 Jan 1970 00:00:00 GMT X-TTL: 2993468323.000 Content-Length: 0 Accept-Ranges: bytes Date: Wed, 30 Mar 2011 15:29:33 GMT X-Varnish: 2019167673 Age: 0 Via: 1.1 varnish Connection: keep-alive X-Cache: MISS }}} Subsequent requests look as follows: {{{ curl -i localhost:8080/station/eins-test/current_song HTTP/1.1 200 OK Status: 200 OK Content-Type: application/json; charset=utf-8 Cache-Control: public, must-revalidate, max-age=-1301498973 Expires: Thu, 01 Jan 1970 00:00:00 GMT X-TTL: 2993468323.000 Content-Length: 0 Accept-Ranges: bytes Date: Wed, 30 Mar 2011 15:31:42 GMT X-Varnish: 2019167674 2019167673 Age: 129 Via: 1.1 varnish Connection: keep-alive X-Cache: HIT X-Cache-Hits: 1 }}} My workaround for now is this VCL rule: {{{ sub vcl_fetch { set beresp.http.X-TTL = beresp.ttl; if (beresp.http.Cache-Control ~ "max-age=-") { return(hit_for_pass); } } }}} I have attached my complete VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 11:14:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 11:14:10 -0000 Subject: [Varnish] #887: Varnish caches objects with negative max-age In-Reply-To: <041.78ea9a5973c5cd58283bf4236206a80a@varnish-cache.org> References: <041.78ea9a5973c5cd58283bf4236206a80a@varnish-cache.org> Message-ID: <050.260595f1ee5814c016b957cd8615a44a@varnish-cache.org> #887: Varnish caches objects with negative max-age ----------------------+----------------------------------------------------- Reporter: niko | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: negative max-age, past expire ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: strictly speaking, RFC2616 does not allow negative values for max-age. On page 108 it defines: {{{ cache-request-directive = "no-cache" ; Section 14.9.1 | "no-store" ; Section 14.9.2 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 [...] }}} And on page 21, delta-seconds is defined as: {{{ delta-seconds = 1*DIGIT }}} However, it would probably make sense to handle invalid values sanely. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 11:24:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 11:24:33 -0000 Subject: [Varnish] #887: Varnish caches objects with negative max-age In-Reply-To: <041.78ea9a5973c5cd58283bf4236206a80a@varnish-cache.org> References: <041.78ea9a5973c5cd58283bf4236206a80a@varnish-cache.org> Message-ID: <050.aee8cd3bf25b94322abe711dd579bb3c@varnish-cache.org> #887: Varnish caches objects with negative max-age -------------------------------------------+-------------------------------- Reporter: niko | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: negative max-age, past expire | -------------------------------------------+-------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [66c8c9c358bc85f0601f03eb175e01da79251733]) Treat RFC-illegal negative (s-)max-age values as zero. Fixes #887 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 13:09:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 13:09:12 -0000 Subject: [Varnish] #886: Ban-related crashes In-Reply-To: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> References: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> Message-ID: <054.5cd1b918d230c9c0179bd76394439943@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Small follow-up: This almost certainly ban-lurker-related. I was not able to re-produce the issue without the ban-lurker, but with the ban-lurker, it happened semi-frequently. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 14:20:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 14:20:18 -0000 Subject: [Varnish] #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 Message-ID: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Spanking new code. As usual, googlebot came along and ruined the uptime. panic.show: {{{ Last panic at: Thu, 31 Mar 2011 14:12:59 GMT Assert error in ESI_Deliver(), cache_esi_deliver.c line 326: Condition(i == VGZ_OK || i == VGZ_END) not true. thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42cd28: pan_ic+b8 0x41f6fa: ESI_Deliver+3fa 0x42f878: RES_WriteObj+228 0x416b70: cnt_deliver+230 0x4179fd: CNT_Session+2ed 0x42e4e8: wrk_do_cnt_sess+b8 0x42e971: wrk_thread_real+411 0x7f57899289ca: _end+7f57892b0752 0x7f578968570d: _end+7f578900d495 sp = 0x7f5779035008 { fd = 13, id = 13, xid = 1767439512, client = 66.249.71.11 34085, step = STP_DELIVER, handling = deliver, restarts = 0, esi_level = 0 ws = 0x7f5779035080 { id = "sess", {s,f,r,e} = {0x7f5779035cf0,+512,(nil),+65536}, }, http[req] = { ws = 0x7f5779035080[sess] "GET", "/trac/changeset?new=6af4255312dc5fa13fa62cdaef27c67af78e2b4c%40bin/varnishd&old=355d66cb3a37fcea513192f2597ddf68f8fabdaa %40bin/varnishd", "HTTP/1.1", "Host: www.varnish-cache.org", "Connection: Keep-alive", "Accept: */*", "From: googlebot(at)googlebot.com", "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "X-Forwarded-For: 66.249.71.11, 66.249.71.11", }, worker = 0x7f57828dbb70 { ws = 0x7f57828dbd10 { id = "wrk", {s,f,r,e} = {0x7f57828c9b00,+152,(nil),+65536}, }, http[resp] = { ws = 0x7f57828dbd10[wrk] "HTTP/1.1", "200", "Ok", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Transfer-Encoding: chunked", "Date: Thu, 31 Mar 2011 14:12:58 GMT", "X-Varnish: 1767439512 1767439483", "Age: 1", "Via: 1.1 varnish", "Connection: keep-alive", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f5778a0a400 { xid = 1767439483, ws = 0x7f5778a0a418 { id = "obj", {s,f,r,e} = {0x7f5778a0a638,+288,(nil),+312}, }, http[obj] = { ws = 0x7f5778a0a418[obj] "HTTP/1.1", "Ok", "Date: Thu, 31 Mar 2011 14:12:45 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Cache-Control: must-revalidate", "Vary: Accept-Encoding", "Content-Encoding: gzip", "Content-Type: text/html;charset=utf-8", "X-ESI: on", "Content-Length: 229494", }, len = 229494, store = { 131072 { 1f 8b 08 00 00 00 00 00 00 03 02 00 00 00 ff ff |................| b2 51 74 f1 77 0e 89 0c 70 55 c8 28 c9 cd 51 08 |.Qt.w...pU.(..Q.| 08 75 f2 f1 74 56 50 d2 d5 d7 0f 37 76 d6 d7 77 |.u..tVP....7v..w| 09 71 51 88 f0 08 f1 f5 51 30 d4 33 50 08 2e 29 |.qQ.....Q0.3P..)| [131008 more] }, 98422 { 0a 14 4b ca 4f a9 44 15 b6 01 8b 29 24 e7 24 16 |..K.O.D....)$.$.| 17 db 2a 95 e6 e5 e6 a7 28 61 b7 0c c3 3c 54 e9 |..*.....(a... Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 14:25:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 14:25:09 -0000 Subject: [Varnish] #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 In-Reply-To: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> References: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> Message-ID: <051.3247eaf3be340a1195e4e475b745ab62@varnish-cache.org> #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by perbu): NOticed the following in syslog: Mar 31 16:12:58 odd varnishd[24553]: Child (24555) said WARNING at 15117 ESI 1.0 lacks final '/' Mar 31 16:12:58 odd varnishd[24553]: Child (24555) said ERROR at 15123 ESI 1.0 illegal end-tag Mar 31 16:12:59 odd varnishd[24553]: Child (24555) said INFLATE=-3 (invalid stored block lengths) Mar 31 16:12:59 odd varnishd[24553]: Child (24555) died signal=6 The PID matches the asserting child. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 17:01:50 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 17:01:50 -0000 Subject: [Varnish] #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 In-Reply-To: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> References: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> Message-ID: <051.4ce6890f594684debd572b7627c22bfc@varnish-cache.org> #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by phk): Please pull 3c8e5203ebd7ad232c80406511d4288a41a6fc87 (or later) and try again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:15:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:15:07 -0000 Subject: [Varnish] #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 In-Reply-To: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> References: <042.cbca03f5cbf24bc93c717721d94d27f6@varnish-cache.org> Message-ID: <051.20ea8520e2e072af1ba3624b8d2c1fce@varnish-cache.org> #888: Assert error in ESI_Deliver(), cache_esi_deliver.c line 326 --------------------+------------------------------------------------------- Reporter: perbu | 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 one is confirmed fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:15:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:15:38 -0000 Subject: [Varnish] #885: startup crash In-Reply-To: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> References: <042.06aac7b14c3877befd5316e69ce170bc@varnish-cache.org> Message-ID: <051.35a0fd96f147d98320f6db5d5ae5be27@varnish-cache.org> #885: startup crash --------------------+------------------------------------------------------- Reporter: perbu | 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 one is fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:16:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:16:53 -0000 Subject: [Varnish] #869: Assert error in ESI_Deliver() In-Reply-To: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> References: <042.c5ea1bb1f5d9f15ab86f3a0df72fdff1@varnish-cache.org> Message-ID: <051.1624fcaeb7838c5dedcfecb14e9eae04@varnish-cache.org> #869: Assert error in ESI_Deliver() --------------------+------------------------------------------------------- Reporter: perbu | 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: fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:21:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:21:26 -0000 Subject: [Varnish] #881: failure while fetching delivering large files with gzip enabled In-Reply-To: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> References: <042.b67ea2ae98bc000216429d538d3411e0@varnish-cache.org> Message-ID: <051.4dc2bef0f088d79de94cd80a5524fcca@varnish-cache.org> #881: failure while fetching delivering large files with gzip enabled --------------------+------------------------------------------------------- Reporter: perbu | 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: Fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:22:44 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:22:44 -0000 Subject: [Varnish] #874: gzip failures on 32 bit big-endian In-Reply-To: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> References: <043.c68248fbdbd9f1de3d3c016fc082f6d1@varnish-cache.org> Message-ID: <052.99adf918813ee61453b1621f5bac535f@varnish-cache.org> #874: gzip failures on 32 bit big-endian ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: Fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:25:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:25:02 -0000 Subject: [Varnish] #889: opensolaris build issue Message-ID: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> #889: opensolaris build issue --------------------+------------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- The tinderbox is not happy about building opensolaris. The present problem has me stuck, the curses functions whats "char*" where "const char*" is needed, for instance printw() functions. I'm not going to bastardize the sources for this, so either we need to find some magic option/ifdef on solaris to use sane prototypes or we need to disable some warning flags on the tinderbox. I would far prefer the former if at all possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:53:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:53:13 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> References: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> Message-ID: <049.10c09b850cb7bc56b5146fa90adc65d0@varnish-cache.org> #889: opensolaris build issue --------------------+------------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by slink): could you add some more details, please? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 18:57:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 18:57:12 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> References: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> Message-ID: <049.87589449487ad9bc797d3d57ddb66bfd@varnish-cache.org> #889: opensolaris build issue --------------------+------------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by slink): I'm really just guessing, but could it be that you have a GNU curses installation in a place which the auto**** tools know about? Can you check if /usr/include/curses.h gets included? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 19:03:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 19:03:20 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> References: <040.8a1771e91d8351a83c002cbc106b3054@varnish-cache.org> Message-ID: <049.e604ce0cd71873fac2ffec6bb067563c@varnish-cache.org> #889: opensolaris build issue --------------------+------------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Comment(by phk): I don't really have any more details than the tinderbox provides in the log: http://buildbot.varnish-cache.org/waterfall When I looked up the printw() manpage for solaris, it clearly says: {{{ int printw(char *fmt, ?); }}} And that obviously will not work with {{{ printw("Hello World\n"); }}} I can't imagine why they are not prototyped "const char*" and I can't imagine that there isn't some kind of #ifdef SANE_CURSES that makes them prototyped such. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Mar 31 20:08:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Mar 2011 20:08:09 -0000 Subject: [Varnish] #855: trac internal error when browsing by revision In-Reply-To: <042.66de011872fdea2250b4e2792e2771f4@varnish-cache.org> References: <042.66de011872fdea2250b4e2792e2771f4@varnish-cache.org> Message-ID: <051.cbe52593106c903675a87eba38a6e33e@varnish-cache.org> #855: trac internal error when browsing by revision ---------------------+------------------------------------------------------ Reporter: slink | Owner: thfeen Type: defect | Status: closed Priority: lowest | Milestone: Component: website | Version: trunk Severity: trivial | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: This works now. -- Ticket URL: Varnish The Varnish HTTP Accelerator