From varnish-bugs at projects.linpro.no Tue Jul 1 14:35:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 01 Jul 2008 14:35:33 -0000 Subject: [Varnish] #265: Implement nuke option to invalidate all variants of an object Message-ID: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> #265: Implement nuke option to invalidate all variants of an object -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- This implements a new return value from vcl_hit called nuke. It will mangle the hash value of the object (per suggestion from phk), so future lookups won't find it, instead of locking all children and invalidating them {{{ -bash-3.1$ svn diff Index: include/vcl_returns.h =================================================================== --- include/vcl_returns.h (revision 2871) +++ include/vcl_returns.h (working copy) @@ -20,6 +20,7 @@ VCL_RET_MAC(discard, DISCARD, (1 << 8), 8) VCL_RET_MAC(keep, KEEP, (1 << 9), 9) VCL_RET_MAC(restart, RESTART, (1 << 10), 10) +VCL_RET_MAC(nuke, NUKE, (1 << 11), 11) #else #define VCL_RET_ERROR (1 << 0) #define VCL_RET_LOOKUP (1 << 1) @@ -32,7 +33,8 @@ #define VCL_RET_DISCARD (1 << 8) #define VCL_RET_KEEP (1 << 9) #define VCL_RET_RESTART (1 << 10) -#define VCL_RET_MAX 11 +#define VCL_RET_NUKE (1 << 11) +#define VCL_RET_MAX 12 #endif #ifdef VCL_MET_MAC @@ -41,7 +43,7 @@ VCL_MET_MAC(pass,PASS,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_PASS)) VCL_MET_MAC(hash,HASH,(VCL_RET_HASH)) VCL_MET_MAC(miss,MISS,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_PASS|VCL_RET_FETCH)) -VCL_MET_MAC(hit,HIT,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_PASS|VCL_RET_DELIVER)) +VCL_MET_MAC(hit,HIT,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_PASS|VCL_RET_DELIVER|VCL_RET_NUKE)) VCL_MET_MAC(fetch,FETCH,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_PASS|VCL_RET_INSERT)) VCL_MET_MAC(deliver,DELIVER,(VCL_RET_ERROR|VCL_RET_RESTART|VCL_RET_DELIVER)) VCL_MET_MAC(prefetch,PREFETCH,(VCL_RET_FETCH|VCL_RET_PASS)) Index: lib/libvcl/vcc_gen_fixed_token.tcl =================================================================== --- lib/libvcl/vcc_gen_fixed_token.tcl (revision 2871) +++ lib/libvcl/vcc_gen_fixed_token.tcl (working copy) @@ -39,7 +39,7 @@ {pass {error restart pass}} {hash {hash}} {miss {error restart pass fetch}} - {hit {error restart pass deliver}} + {hit {error restart pass deliver nuke}} {fetch {error restart pass insert}} {deliver {error restart deliver}} {prefetch {fetch pass}} @@ -61,6 +61,7 @@ discard keep restart + nuke } # Language keywords Index: lib/libvcl/vcc_fixed_token.c =================================================================== --- lib/libvcl/vcc_fixed_token.c (revision 2871) +++ lib/libvcl/vcc_fixed_token.c (working copy) @@ -303,6 +303,7 @@ vsb_cat(sb, "#define VCL_RET_DISCARD (1 << 8)\n"); vsb_cat(sb, "#define VCL_RET_KEEP (1 << 9)\n"); vsb_cat(sb, "#define VCL_RET_RESTART (1 << 10)\n"); + vsb_cat(sb, "#define VCL_RET_NUKE (1 << 11)\n"); vsb_cat(sb, "/*\n"); vsb_cat(sb, " * $Id$\n"); vsb_cat(sb, " *\n"); Index: bin/varnishd/cache_center.c =================================================================== --- bin/varnishd/cache_center.c (revision 2871) +++ bin/varnishd/cache_center.c (working copy) @@ -491,6 +491,18 @@ return (0); } + if (sp->handling == VCL_RET_NUKE) { + /* kill all versions of this object + then go on to pass + we do this by mangling the first part of the string + so we dont have to find and lock all objects */ + LOCK(&sp->obj->objhead->mtx); + sp->obj->objhead->hash[0] = "\n"; + UNLOCK(&sp->obj->objhead->mtx); + sp->handling = VCL_RET_PASS; + } + + /* Drop our object, we won't need it */ HSH_Deref(sp->obj); sp->obj = NULL; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 2 00:20:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 02 Jul 2008 00:20:21 -0000 Subject: [Varnish] #265: Implement nuke option to invalidate all variants of an object In-Reply-To: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> References: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> Message-ID: <058.a13a9d05040dbe1aa963698b0f1a1539@projects.linpro.no> #265: Implement nuke option to invalidate all variants of an object -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by sky): This patch is broken. If the object only exists in one vary-iant, but the purge comes through another, it isn't found. it needs to be nuke; which can call vcl_hash to create the hash, or just nuke("hash"); I can change it to either. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 2 12:21:27 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 02 Jul 2008 12:21:27 -0000 Subject: [Varnish] #265: Implement nuke option to invalidate all variants of an object In-Reply-To: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> References: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> Message-ID: <058.f825389287a7157a2bd3fcd4f7cacf27@projects.linpro.no> #265: Implement nuke option to invalidate all variants of an object -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by sky): Ok, new version of the patch. This supports a nuke("string") operation so it doesn't rely on vary-ants of an object existing. Logs and update stats. Should be completely harmless to people who don't use it :) Might want to add a return value so one can tell it was successful, also, wondering if there is a flag set, so when an object is about to expire, we know it has been nuked and thus we shouldn't bother to wake VCL up, since it is already gone. {{{ Index: bin/varnishd/cache_vrt.c =================================================================== --- bin/varnishd/cache_vrt.c (revision 2877) +++ bin/varnishd/cache_vrt.c (working copy) @@ -620,6 +620,78 @@ (void)BAN_Add(NULL, regexp, hash); } +/*--------------------------------------------------------------------*/ + +void +VRT_nuke(struct sess *sp, const char *hash) +{ + /* XXX Would be nice with a return value? */ + + + + /* Save state and restore later */ + unsigned tmp_lhashptr = sp->lhashptr; + unsigned tmp_ihashptr = sp->ihashptr; + const char **tmp_p = sp->hashptr; + + { + /* XXX Copy and paste from cache-hash */ + char *p; + uintptr_t u; + sp->lhashptr = 1; /* space for NUL */ + sp->ihashptr = 0; + sp->nhashptr = sp->vcl->nhashcount * 2; + p = WS_Alloc(sp->http->ws, + sizeof(const char *) * (sp->nhashptr + 1)); + XXXAN(p); + /* Align pointer properly (?) */ + u = (uintptr_t)p; + u &= sizeof(const char *) - 1; + if (u) + p += sizeof(const char *) - u; + sp->hashptr = (void*)p; + + } + + const char *curpos; + const char *startpos; + startpos = hash; + int partlen = 0; + + for(curpos = hash; *curpos; curpos++) { + if (*curpos == '\0') + break; + if (*curpos == '#') { + sp->hashptr[sp->ihashptr] = startpos; + sp->hashptr[sp->ihashptr+1] = startpos + partlen; + sp->ihashptr +=2; + sp->lhashptr += partlen + 1; + partlen = 0; + startpos = curpos + 1; + continue; + } + partlen++; + } + + struct objhead *oh = heritage.hash->lookup(sp, NULL); + if(oh) { + WSP(sp, SLT_Nuke_success, "%s", oh->hash); + VSL_stats->nuke_success++; + LOCK(&oh->mtx); + oh->hash[0] = '\n'; + UNLOCK(&oh->mtx); + heritage.hash->deref(oh); + } else { + VSL_stats->nuke_fail++; + WSP(sp, SLT_Nuke_fail, "%s", hash); + } + + sp->lhashptr = tmp_lhashptr; + sp->ihashptr = tmp_ihashptr; + sp->hashptr = tmp_p; +} + + /*-------------------------------------------------------------------- * Simple stuff */ Index: lib/libvcl/vcc_action.c =================================================================== --- lib/libvcl/vcc_action.c (revision 2877) +++ lib/libvcl/vcc_action.c (working copy) @@ -353,6 +353,29 @@ /*--------------------------------------------------------------------*/ +static void +parse_nuke(struct tokenlist *tl) +{ + vcc_NextToken(tl); + + Fb(tl, 1, "VRT_nuke(sp,"); + + Expect(tl, '('); + vcc_NextToken(tl); + + if (!vcc_StringVal(tl)) { + vcc_ExpectedStringval(tl); + return; + } + + Expect(tl, ')'); + vcc_NextToken(tl); + Fb(tl, 0, ");\n"); + +} + +/*--------------------------------------------------------------------*/ + typedef void action_f(struct tokenlist *tl); static struct action_table { @@ -372,6 +395,7 @@ { "purge_url", parse_purge_url }, { "purge_hash", parse_purge_hash }, { "esi", parse_esi }, + { "nuke", parse_nuke }, { NULL, NULL } }; Index: include/stat_field.h =================================================================== --- include/stat_field.h (revision 2877) +++ include/stat_field.h (working copy) @@ -105,3 +105,6 @@ MAC_STAT(sma_bfree, uint64_t, 'i', "SMA bytes free") MAC_STAT(backend_req, uint64_t, 'a', "Backend requests made") + +MAC_STAT(nuke_success, uint64_t, 'a', "Nukes succeeded") +MAC_STAT(nuke_fail, uint64_t, 'a', "Nukes failed") Index: include/shmlog_tags.h =================================================================== --- include/shmlog_tags.h (revision 2877) +++ include/shmlog_tags.h (working copy) @@ -99,3 +99,7 @@ SLTM(ESI_xmlerror) SLTM(Hash) + +SLTM(Nuke_success) +SLTM(Nuke_fail) + }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 2 15:32:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 02 Jul 2008 15:32:55 -0000 Subject: [Varnish] #266: Fix bug in ESI parser Message-ID: <049.5a702ebbeffb03c04eb383b85060649d@projects.linpro.no> #266: Fix bug in ESI parser ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Currently, if the ESI parser sees an open tag, it tries to find the end of it, leading to problems if you have open < for other reasons. Example is xxxafter which renders incorrectly without the patch xxxafter with the patch you get xxx 5 ? 5 : i)) { + /* If this is not an esi tag, then there is no point in + treating it like one, just continue + otherwise we are dependent on well formed HTML */ + p++; + continue; + } + /* Find end of this element */ for (q = p + 1; q < t.e && *q != '>'; q++) continue; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 2 23:09:45 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 02 Jul 2008 23:09:45 -0000 Subject: [Varnish] #267: Fix ESI If-Modified-Since bug Message-ID: <049.5a4dfd969e0d14cf94a446690e240ee2@projects.linpro.no> #267: Fix ESI If-Modified-Since bug ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- We need to unset the If-Modified-Since header, otherwise the underlying ESI object might not be rendered. {{{ Index: bin/varnishd/cache_vrt_esi.c =================================================================== --- bin/varnishd/cache_vrt_esi.c (revision 2877) +++ bin/varnishd/cache_vrt_esi.c (working copy) @@ -777,6 +785,7 @@ http_SetH(sp->http, HTTP_HDR_URL, eb->include.b); if (eb->host.b != NULL) { http_Unset(sp->http, H_Host); + http_Unset(sp->http, H_If_Modified_Since); http_SetHeader(sp->wrk, sp->fd, sp->http, eb->host.b); } sp->step = STP_RECV; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 2 23:39:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 02 Jul 2008 23:39:51 -0000 Subject: [Varnish] #268: Make 304 and Last-Modified work with ESI Message-ID: <049.562ba092d4a09f6f293514999f686752@projects.linpro.no> #268: Make 304 and Last-Modified work with ESI -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- This keeps track of a last_modified for a objheader which is set to the most recent last_modified, if that is set then we use that instead of our top-level. If we get an IMS and we don't have the cached value we return 200, otherwise we return according to normal rules. There is a race here if a fragment gets updated then IMS won't pick it up. However a normal GET will pick it up, update the cached value and any future IMS will be correct. It is assumed based on my requests that this is a sufficiently small window it is fine. Longer term solutions should be looked at. {{{ =================================================================== --- bin/varnishd/cache.h (revision 2877) +++ bin/varnishd/cache.h (working copy) @@ -296,6 +296,9 @@ char *hash; unsigned hashlen; VTAILQ_HEAD(, sess) waitinglist; + + /* cached value for ESI */ + double last_modified_cached; }; /* -------------------------------------------------------------------*/ @@ -371,6 +374,10 @@ unsigned ihashptr; unsigned lhashptr; const char **hashptr; + + /* used during ESI processing to figure out the real LM */ + double last_modified_cached; + }; /* ------------------------------------------------------------------- Index: bin/varnishd/cache_response.c =================================================================== --- bin/varnishd/cache_response.c (revision 2877) +++ bin/varnishd/cache_response.c (working copy) @@ -56,8 +56,17 @@ http_PrintfHeader(sp->wrk, sp->fd, sp->http, "Date: %s", lm); http_SetHeader(sp->wrk, sp->fd, sp->http, "Via: 1.1 varnish"); http_PrintfHeader(sp->wrk, sp->fd, sp->http, "X-Varnish: %u", sp->xid); - TIM_format(sp->obj->last_modified, lm); + + /* Check to do the right thing with regards to ESI */ + if(!VTAILQ_EMPTY(&sp->obj->esibits)) { + TIM_format(sp->obj->objhead->last_modified_cached, lm); + } else { + TIM_format(sp->obj->last_modified, lm); + } + http_PrintfHeader(sp->wrk, sp->fd, sp->http, "Last-Modified: %s", lm); + + http_PrintfHeader(sp->wrk, sp->fd, sp->http, "Connection: %s", sp->doclose ? "close" : "keep-alive"); sp->wantbody = 0; @@ -70,13 +79,24 @@ { char *p; double ims; + double last_modified = 0; - if (sp->obj->last_modified > 0 && + /* Check to do the right thing with regards to ESI */ + if(!VTAILQ_EMPTY(&sp->obj->esibits)) { + last_modified = sp->obj->objhead->last_modified_cached; + } else { + last_modified = sp->obj->last_modified; + } + + + if (last_modified > 0 && http_GetHdr(sp->http, H_If_Modified_Since, &p)) { + + ims = TIM_parse(p); if (ims > sp->t_req) /* [RFC2616 14.25] */ return (0); - if (sp->obj->last_modified > ims) { + if (last_modified > ims) { return (0); } res_do_304(sp); @@ -134,16 +154,54 @@ CHECK_OBJ_NOTNULL(sp, SESS_MAGIC); WRK_Reset(sp->wrk, &sp->fd); - if (sp->esis == 0) - sp->wrk->acct.hdrbytes += http_Write(sp->wrk, sp->http, 1); if (sp->wantbody && !VTAILQ_EMPTY(&sp->obj->esibits)) { + + /* slight duplicate code path to below + but we need to mangle headers a bit */ + + + if(sp->obj->last_modified < sp->obj->objhead->last_modified_cached) { + char lm[64]; + http_Unset(sp->http, H_Last_Modified); + TIM_format(sp->obj->objhead->last_modified_cached, lm); + http_PrintfHeader(sp->wrk, sp->fd, sp->http, "Last-Modified: %s", lm); + + } + + if (sp->esis == 0) + sp->wrk->acct.hdrbytes += http_Write(sp->wrk, sp->http, 1); + ESI_Deliver(sp); + + + + + /* do i really need this mutex? + we have a ref to the object + */ + if (sp->esis == 0) { + if (sp->obj->last_modified > sp->last_modified_cached) + sp->last_modified_cached = sp->obj->last_modified; + LOCK(&sp->obj->objhead->mtx); + if (sp->last_modified_cached > sp->obj->objhead->last_modified_cached) + sp->obj->objhead->last_modified_cached = sp->last_modified_cached; + UNLOCK(&sp->obj->objhead->mtx); + } } else if (sp->wantbody) { + + if (sp->esis == 0) + sp->wrk->acct.hdrbytes += http_Write(sp->wrk, sp->http, 1); + if (sp->esis > 0) { sprintf(lenbuf, "%x\r\n", sp->obj->len); sp->wrk->acct.hdrbytes += WRK_Write(sp->wrk, lenbuf, -1); + + /* Try and find the latest last-modified */ + if(sp->obj && sp->obj->last_modified > sp->last_modified_cached) + sp->last_modified_cached = sp->obj->last_modified; + } VTAILQ_FOREACH(st, &sp->obj->store, list) { @@ -172,7 +230,11 @@ spassert(u == sp->obj->len); if (sp->esis > 0) WRK_Write(sp->wrk, "\r\n", -1); + } else { + if (sp->esis == 0) + sp->wrk->acct.hdrbytes += http_Write(sp->wrk, sp->http, 1); } + if (WRK_Flush(sp->wrk)) vca_close_session(sp, "remote closed"); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 4 16:18:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 04 Jul 2008 16:18:30 -0000 Subject: [Varnish] #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: Message-ID: <049.02998deb9d12ad806d1c555b8ad5fc06@projects.linpro.no> #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When running under moderate load, 250-300 requests per second, after a 30-60 minutes or so I get {{{ [Switching to Thread 46945328531776 (LWP 26611)] 0x0000003482ec7913 in writev () from /lib64/libc.so.6 (gdb) bt #0 0x0000003482ec7913 in writev () from /lib64/libc.so.6 #1 0x000000000041b39a in WRK_Flush () #2 0x000000000041e5aa in RES_WriteObj () #3 0x000000000040d1a2 in cnt_deliver () #4 0x000000000040f9e5 in CNT_Session () #5 0x000000000041c476 in wrk_do_cnt_sess () #6 0x000000000041bc23 in wrk_thread () #7 0x0000003483e062f7 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003482ece85d in clone () from /lib64/libc.so.6 }}} Sadly, even though I compiled with debugging, it seems I did it wrong, will track more. Workspace and objectspace is 16384 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jul 5 16:15:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 05 Jul 2008 16:15:38 -0000 Subject: [Varnish] #270: Assert error in exp_timer(), cache_expire.c line 300 Message-ID: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> #270: Assert error in exp_timer(), cache_expire.c line 300 ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- {{{ Jul 5 14:12:14 can05 kernel: pid 14597 (varnishd), uid 101: exited on signal 6 Jul 5 14:12:14 can05 varnishd: Child (14597) said <> Jul 5 14:12:14 can05 varnishd: Child (14597) said << Condition(oe2->timer_when >= oe->timer_when) not true.>> Jul 5 14:12:14 can05 varnishd: Child (4314) said <> Jul 5 14:12:14 can05 varnishd: Child (4314) said <> Jul 5 14:12:14 can05 varnishd: Child (4314) said <> }}} We are setting the obj.ttl to 86400 in the vcl file. This condition started after raising the storage from 1G to 2G (FreeBSD 7 amd64 w/ 4G Ram). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 6 17:40:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 06 Jul 2008 17:40:31 -0000 Subject: [Varnish] #271: Assert error in vca_kqueue_main(), cache_acceptor_kqueue.c line 139 Message-ID: <056.8a608e3a0dbdc04185bb0d5e95bb0b79@projects.linpro.no> #271: Assert error in vca_kqueue_main(), cache_acceptor_kqueue.c line 139 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Keywords: ------------------------+--------------------------------------------------- This line: AZ(kevent(kq, ke, j, NULL, 0, NULL)); asserts that kevent should return 0. However, on OpenBSD -current that is not the case. Both OpenBSD and FreeBSD kqueue man pages say ~ kevent() returns the number of events placed in the eventlist, up to the value given by nevents. If an error occurs while processing an element of the changelist and there is enough room in the eventlist, then the event will be placed in the eventlist with EV_ERROR set in flags and the system error in data. Otherwise, -1 will be returned, and errno will be set to indicate the error condition. If the time limit expires, then kevent() returns 0. When I changed the assert to test against 2, I was able to get past it and run into a setsockopt error later on. Another ticket forthcoming. ;-) So it appears to me that asserting kevent returns 0 really only covers one case, that being time limit expiration. Perhaps dropping the assert and instead testing for -1 and the EV_ERROR flag may be more correct. BTW, I lost my password for my "bonetruck" account here and so created "bonetruck2". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 6 18:01:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 06 Jul 2008 18:01:59 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 Message-ID: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Keywords: ------------------------+--------------------------------------------------- The error I get upon giving the start command is: Child said (2, 23453): <sock, 0xffff, 0x1005, &tv_sndtimeo, sizeof tv_sndtimeo)) == 0) not true. errno = 33 (Numerical argument out of domain) Again, this is on OpenBSD -current on a i386 host. I'm guessing the bad argument is tv_sndtimeo. Haven't chased it any further though. BTW, both VTAILQ_FOREACH lines (170 and 180) have trailing whitespace too. FYI. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 7 09:53:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 07 Jul 2008 09:53:29 -0000 Subject: [Varnish] #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: In-Reply-To: <049.02998deb9d12ad806d1c555b8ad5fc06@projects.linpro.no> References: <049.02998deb9d12ad806d1c555b8ad5fc06@projects.linpro.no> Message-ID: <058.4dd12542382eca2edb078e44afba18e8@projects.linpro.no> #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by sky): That topic would be incorrect. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 7 16:29:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 07 Jul 2008 16:29:56 -0000 Subject: [Varnish] #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: In-Reply-To: <049.02998deb9d12ad806d1c555b8ad5fc06@projects.linpro.no> References: <049.02998deb9d12ad806d1c555b8ad5fc06@projects.linpro.no> Message-ID: <058.d3474683ead9ac35312b90660ebe0213@projects.linpro.no> #269: Segfault on Set Header in vcl_hit Assert error in WS_Reserve(), cache_ws.c line 103: ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: The backtrace does not correspond to a thread that has any kind of problem, that thread is stuck in the kernel sending a result back to the client. I gather from your followup that the title of this ticket is also in error, so I will close it entirely, and ask you to open a new one with better info when you have it. Remember to include any messages from the syslog, since these usually give the exact location where an assert was triggered. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 7 16:33:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 07 Jul 2008 16:33:34 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.af6e22337c27a17fcd3456bd28ea5754@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): Please try to print out the actual timeval to see if it is valid. Also, check openbsd docs to see what the valid range would be, and suggest an #ifdef'ed patch for the parameter based on any restrictions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 7 16:43:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 07 Jul 2008 16:43:54 -0000 Subject: [Varnish] #271: Assert error in vca_kqueue_main(), cache_acceptor_kqueue.c line 139 In-Reply-To: <056.8a608e3a0dbdc04185bb0d5e95bb0b79@projects.linpro.no> References: <056.8a608e3a0dbdc04185bb0d5e95bb0b79@projects.linpro.no> Message-ID: <065.8574370dbaf886de9cae596cac872542@projects.linpro.no> #271: Assert error in vca_kqueue_main(), cache_acceptor_kqueue.c line 139 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: The manual page you cite states that the return value is the number of events placed in the *eventlist* argument, (4th arument) which is NULL in this call. Earlier the manual page states: When nevents is zero, kevent() will return immediately even if there is a timeout specified unlike select(2). So if that call returns '2', the something is very, very bogus, and I would suggest you research what the semantics of OpenBSDs kqueue actually are. (Maybe a ktrace(8) can help you find out what goes on ?) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 7 16:47:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 07 Jul 2008 16:47:12 -0000 Subject: [Varnish] #270: Assert error in exp_timer(), cache_expire.c line 300 In-Reply-To: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> References: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> Message-ID: <063.ee486c5b85cf794813c944e5eee0b643@projects.linpro.no> #270: Assert error in exp_timer(), cache_expire.c line 300 ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): what is the exact revision number of the -trunk you are running ? I (thought I) fixed an issue (which looks a lot) like this about a week ago... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 8 05:00:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Jul 2008 05:00:55 -0000 Subject: [Varnish] #270: Assert error in exp_timer(), cache_expire.c line 300 In-Reply-To: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> References: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> Message-ID: <063.e4aa761b36bc46bde25eb75160c78478@projects.linpro.no> #270: Assert error in exp_timer(), cache_expire.c line 300 ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by maxclark): varnish-2.0-tp1. I actually didn't see the tp2 announcement on the list, should I upgrade to tp2 or is there a different revision that I should use? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 8 05:11:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Jul 2008 05:11:43 -0000 Subject: [Varnish] #256: Varnish Child Exits In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> Message-ID: <063.a74ea14d11844aa9441682023a1dbb3e@projects.linpro.no> #256: Varnish Child Exits ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by maxclark): FreeBSD 7.0 amd64 stock kernel with the substitution of the ULE scheduler. Dual CPU with Hyperthreading disabled. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 8 06:07:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Jul 2008 06:07:35 -0000 Subject: [Varnish] #270: Assert error in exp_timer(), cache_expire.c line 300 In-Reply-To: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> References: <054.e5d617daf86abb9880bc217942657a1c@projects.linpro.no> Message-ID: <063.b1c72953056e37a981dbb7813070f502@projects.linpro.no> #270: Assert error in exp_timer(), cache_expire.c line 300 ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Yes, this was the major bug in tp1, please upgrade to tp2 or -trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 8 06:26:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Jul 2008 06:26:07 -0000 Subject: [Varnish] #256: Varnish Child Exits In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> Message-ID: <063.50ab30818022a0a82423383fdf696a66@projects.linpro.no> #256: Varnish Child Exits ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Can you get us a snapshot of varnishstat as close a practically possible on a crash ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 8 17:12:52 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Jul 2008 17:12:52 -0000 Subject: [Varnish] #199: varnish bug?! In-Reply-To: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no> References: <051.07fad13d1ba0a317a4d53ab9fa5d543a@projects.linpro.no> Message-ID: <060.383f8d1f6621bcd201fc8b2c05468936@projects.linpro.no> #199: varnish bug?! ----------------------+----------------------------------------------------- Reporter: trall | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by trall): I compiled a svn snapshot from 7 days ago and the bug now seems to be fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 14 01:32:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 14 Jul 2008 01:32:25 -0000 Subject: [Varnish] #132: Varnish 1.1 dies with assert error in SES_Delete In-Reply-To: <052.fe8cf8964ac10aa02472af7aa5d37aad@projects.linpro.no> References: <052.fe8cf8964ac10aa02472af7aa5d37aad@projects.linpro.no> Message-ID: <061.004ef78ad8cd8924f7c6a83944b998be@projects.linpro.no> #132: Varnish 1.1 dies with assert error in SES_Delete ----------------------------------+----------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 1.1.2 Component: varnishd | Version: 1.1 Severity: major | Resolution: fixed Keywords: core dump SES_Delete | ----------------------------------+----------------------------------------- Comment (by add): http://www.cheap-wrought-iron.cn http://www.china-made-door.com.cn -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 14 22:52:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 14 Jul 2008 22:52:30 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server Message-ID: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Keywords: ------------------------+--------------------------------------------------- Well we are still seeing varnish run out of virtual memory. Here is a varnishdump of when it reaches about 3.5G. We wonder if we are falling foul of the policy of: Allocate enough memory for 99% of the cases up front Unused & untouched memory is free ? as in ?peanuts? All we can think of is that our server is so busy requests are coming in faster than they can be garbage collected. I guess its time to go 64bit, seems silly when the current servers are 90% idle! If anyone has any ideas it would be great to hear from you. Centos 5, 32 bit, Basic settings with 128M file 0+00:03:11 Hitrate ratio: 10 100 558 Hitrate avg: 0.8030 0.7862 0.7786 15732 85.01 82.37 Client connections accepted 29255 156.01 153.17 Client requests received 22413 126.01 117.35 Cache hits 248 0.00 1.30 Cache hits for pass 6508 29.00 34.07 Cache misses 6839 29.00 35.81 Backend connections success 0 0.00 0.00 Backend connections failures 6084 27.00 31.85 Backend connections reuses 6759 28.00 35.39 Backend connections recycles 1 -1.00 0.01 Backend connections unused 3954 . . N struct srcaddr 723 . . N active struct srcaddr 816 . . N struct sess_mem 782 . . N struct sess 2259 . . N struct object 2244 . . N struct objecthead 2024 . . N struct smf 19 . . N small free smf 1 . . N large free smf 27 . . N struct vbe_conn 270 . . N worker threads 270 0.00 1.41 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 270 0.00 1.41 N overflowed work requests 0 0.00 0.00 N dropped work requests 4501 . . N expired objects 1041 . . N objects on deathrow 0 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile 25350 125.01 132.72 Objects sent with write 15574 80.01 81.54 Total Sessions 29001 146.01 151.84 Total Requests 31 0.00 0.16 Total pipe 0 0.00 0.00 Total pass 6759 30.00 35.39 Total fetch 9348459 45370.50 48944.81 Total header bytes 125553523 560967.24 657348.29 Total body bytes 526 6.00 2.75 Session Closed 11 0.00 0.06 Session Pipeline 0 0.00 0.00 Session Read Ahead 28709 142.01 150.31 Session herd 1448734 7050.54 7584.99 SHM records -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 15 13:09:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 15 Jul 2008 13:09:03 -0000 Subject: [Varnish] #274: Is it possible to deliver custom error page ? Message-ID: <061.20d19d02bf47782e1dc0cbeb18276297@projects.linpro.no> #274: Is it possible to deliver custom error page ? -----------------------------+---------------------------------------------- Reporter: franck.leprette | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: -----------------------------+---------------------------------------------- Hello, My name is Franck LEPRETTE , I'm currently working with varnish with ezpublish and i have a problem. The version is : # varnishd -V varnishd (varnish-1.1.2) Copyright (c) 2006-2007 Linpro AS / Verdens Gang AS THe operating system is Debian Etch and our web servers are Apache2. We override the error page with our cms ezpublish , and now when someone tries to get an inexistant URL, he is redirected to the home page with a warning text (but we still send the 404 error code). The problem is that varnish doesn't deliver this page, and we still get a 404 error code with no custom page. Do you know how to configure varnish in order to get it work ? I tried this code but it doesn't seem to work : sub vcl_fetch { if (obj.status == 404) {pass;} } I also tried to find some documentation about this problem, but i didn't found any. Do you know if it's possible to perform this operation and how ? Thanks in advance. Kind regards -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:14:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:14:47 -0000 Subject: [Varnish] #274: Is it possible to deliver custom error page ? In-Reply-To: <061.20d19d02bf47782e1dc0cbeb18276297@projects.linpro.no> References: <061.20d19d02bf47782e1dc0cbeb18276297@projects.linpro.no> Message-ID: <070.423ee702d0ead2df914c3f5a7a5b9c3c@projects.linpro.no> #274: Is it possible to deliver custom error page ? -----------------------------+---------------------------------------------- Reporter: franck.leprette | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -----------------------------+---------------------------------------------- Changes (by des): * status: new => closed * resolution: => invalid Comment: This is a support question, please use the mailing lists. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:25:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:25:41 -0000 Subject: [Varnish] #256: Varnish Child Exits In-Reply-To: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> References: <054.fa0dedc6e6244f9fa3695bed20cbbb1f@projects.linpro.no> Message-ID: <063.a253ba4fdffacb11f0dcf7afd955b595@projects.linpro.no> #256: Varnish Child Exits ----------------------+----------------------------------------------------- Reporter: maxclark | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by des): You don't mention which version you're running, but if you're running 1.1, this is expected behaviour as 1.1 does not prematurely expire objects when the cache fills up. The simplest workaround is to increase cache size. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:29:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:29:13 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.3a6317a4626cd60d509a324ff9d5ab72@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Old description: > Well we are still seeing varnish run out of virtual memory. Here is a > varnishdump of when it reaches about 3.5G. > > We wonder if we are falling foul of the policy of: > Allocate enough memory for 99% of the cases up front > Unused & untouched memory is free ? as in ?peanuts? > > All we can think of is that our server is so busy requests are coming in > faster than they can be garbage collected. > > I guess its time to go 64bit, seems silly when the current servers are > 90% idle! > > If anyone has any ideas it would be great to hear from you. > > Centos 5, 32 bit, Basic settings with 128M file > > 0+00:03:11 > Hitrate ratio: 10 100 558 > Hitrate avg: 0.8030 0.7862 0.7786 > > 15732 85.01 82.37 Client connections accepted > 29255 156.01 153.17 Client requests received > 22413 126.01 117.35 Cache hits > 248 0.00 1.30 Cache hits for pass > 6508 29.00 34.07 Cache misses > 6839 29.00 35.81 Backend connections success > 0 0.00 0.00 Backend connections failures > 6084 27.00 31.85 Backend connections reuses > 6759 28.00 35.39 Backend connections recycles > 1 -1.00 0.01 Backend connections unused > 3954 . . N struct srcaddr > 723 . . N active struct srcaddr > 816 . . N struct sess_mem > 782 . . N struct sess > 2259 . . N struct object > 2244 . . N struct objecthead > 2024 . . N struct smf > 19 . . N small free smf > 1 . . N large free smf > 27 . . N struct vbe_conn > 270 . . N worker threads > 270 0.00 1.41 N worker threads created > 0 0.00 0.00 N worker threads not created > 0 0.00 0.00 N worker threads limited > 0 0.00 0.00 N queued work requests > 270 0.00 1.41 N overflowed work requests > 0 0.00 0.00 N dropped work requests > 4501 . . N expired objects > 1041 . . N objects on deathrow > 0 0.00 0.00 HTTP header overflows > 0 0.00 0.00 Objects sent with sendfile > 25350 125.01 132.72 Objects sent with write > 15574 80.01 81.54 Total Sessions > 29001 146.01 151.84 Total Requests > 31 0.00 0.16 Total pipe > 0 0.00 0.00 Total pass > 6759 30.00 35.39 Total fetch > 9348459 45370.50 48944.81 Total header bytes > 125553523 560967.24 657348.29 Total body bytes > 526 6.00 2.75 Session Closed > 11 0.00 0.06 Session Pipeline > 0 0.00 0.00 Session Read Ahead > 28709 142.01 150.31 Session herd > 1448734 7050.54 7584.99 SHM records New description: Well we are still seeing varnish run out of virtual memory. Here is a varnishdump of when it reaches about 3.5G. We wonder if we are falling foul of the policy of: Allocate enough memory for 99% of the cases up front Unused & untouched memory is free ? as in ?peanuts? All we can think of is that our server is so busy requests are coming in faster than they can be garbage collected. I guess its time to go 64bit, seems silly when the current servers are 90% idle! If anyone has any ideas it would be great to hear from you. Centos 5, 32 bit, Basic settings with 128M file {{{ 0+00:03:11 Hitrate ratio: 10 100 558 Hitrate avg: 0.8030 0.7862 0.7786 15732 85.01 82.37 Client connections accepted 29255 156.01 153.17 Client requests received 22413 126.01 117.35 Cache hits 248 0.00 1.30 Cache hits for pass 6508 29.00 34.07 Cache misses 6839 29.00 35.81 Backend connections success 0 0.00 0.00 Backend connections failures 6084 27.00 31.85 Backend connections reuses 6759 28.00 35.39 Backend connections recycles 1 -1.00 0.01 Backend connections unused 3954 . . N struct srcaddr 723 . . N active struct srcaddr 816 . . N struct sess_mem 782 . . N struct sess 2259 . . N struct object 2244 . . N struct objecthead 2024 . . N struct smf 19 . . N small free smf 1 . . N large free smf 27 . . N struct vbe_conn 270 . . N worker threads 270 0.00 1.41 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 270 0.00 1.41 N overflowed work requests 0 0.00 0.00 N dropped work requests 4501 . . N expired objects 1041 . . N objects on deathrow 0 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile 25350 125.01 132.72 Objects sent with write 15574 80.01 81.54 Total Sessions 29001 146.01 151.84 Total Requests 31 0.00 0.16 Total pipe 0 0.00 0.00 Total pass 6759 30.00 35.39 Total fetch 9348459 45370.50 48944.81 Total header bytes 125553523 560967.24 657348.29 Total body bytes 526 6.00 2.75 Session Closed 11 0.00 0.06 Session Pipeline 0 0.00 0.00 Session Read Ahead 28709 142.01 150.31 Session herd 1448734 7050.54 7584.99 SHM records }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:34:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:34:21 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.7e3d6a725860b29e12a18b005e5a6f88@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by des): What do you mean by "running out of virtual memory"? We need to know the symptoms, not your interpretation. I have no idea what your second and third paragraphs mean. How big is your cache file? This looks like a support question, not a bug, but I'll leave it open until we know more. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:37:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:37:33 -0000 Subject: [Varnish] #248: Varnish doesn't automatically send host header if back-end is specified using hostname In-Reply-To: <051.58adfa174b689b331ef946f723ea9929@projects.linpro.no> References: <051.58adfa174b689b331ef946f723ea9929@projects.linpro.no> Message-ID: <060.3ad7ccad9ade540acf1af159124e3822@projects.linpro.no> #248: Varnish doesn't automatically send host header if back-end is specified using hostname ----------------------+----------------------------------------------------- Reporter: peter | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => closed * resolution: => wontfix Comment: This is not a bug. Varnish will use the Host: header it got from the client, it is up to you to validate and normalize it in VCL. There are examples in vcl(7). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:46:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:46:43 -0000 Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a patch provided In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no> Message-ID: <064.6da410c4f3fb58be4a6c93f6e8785b6f@projects.linpro.no> #202: Compile Fails on OpenBSD -current / Half a patch provided -----------------------+---------------------------------------------------- Reporter: bonetruck | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 1.2 Severity: normal | Resolution: wontfix Keywords: | -----------------------+---------------------------------------------------- Changes (by des): * status: reopened => closed * resolution: => wontfix Comment: There are too many issues with OpenBSD for us to even consider supporting it. I suggest you try FreeBSD instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:47:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:47:04 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.e23b9b3049ff9906832736e6d19da546@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: wontfix Keywords: | ------------------------+--------------------------------------------------- Changes (by des): * status: new => closed * resolution: => wontfix Comment: There are too many issues with OpenBSD for us to even consider supporting it. I suggest you try FreeBSD instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:47:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:47:46 -0000 Subject: [Varnish] #201: "download as zip archive" doesnt build In-Reply-To: <051.df78b50376565f503f76536374ea7092@projects.linpro.no> References: <051.df78b50376565f503f76536374ea7092@projects.linpro.no> Message-ID: <060.ac9327ba202058bb6b19d5c80884784f@projects.linpro.no> #201: "download as zip archive" doesnt build ---------------------+------------------------------------------------------ Reporter: trall | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: website | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by des): * status: new => closed * resolution: => invalid Comment: Content-free ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 09:51:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 09:51:10 -0000 Subject: [Varnish] #155: varnishncsa -b results in empty output In-Reply-To: <052.15db299ad6ec4d546be3f9c42090b487@projects.linpro.no> References: <052.15db299ad6ec4d546be3f9c42090b487@projects.linpro.no> Message-ID: <061.10c2879eb66d3c54ea9feba2e57273d2@projects.linpro.no> #155: varnishncsa -b results in empty output -------------------------+-------------------------------------------------- Reporter: anders | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishncsa | -------------------------+-------------------------------------------------- Changes (by des): * status: reopened => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 10:01:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 10:01:31 -0000 Subject: [Varnish] #208: Show a subset of the full statistics In-Reply-To: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no> References: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no> Message-ID: <058.6c941486055cf89f3958f5e34a392fa5@projects.linpro.no> #208: Show a subset of the full statistics -------------------------+-------------------------------------------------- Reporter: des | Owner: petter Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * owner: des => petter * status: assigned => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 10:18:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 10:18:05 -0000 Subject: [Varnish] #275: Varnish child stops responding Message-ID: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> #275: Varnish child stops responding ----------------------+----------------------------------------------------- Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Keywords: Varnish child stuck ----------------------+----------------------------------------------------- I am running Varnish trunk up to date to commit 2945, on FreeBSD/amd64 7.0-RELEASE. many times,my Varnish server stopped responding (just getting timeouts). I changed some codes for core dump changed file: mgt_child.c line 171 : "(void)kill(child_pid, SIGKILL); " changed to "(void)kill(child_pid, SIGABRT);" run environment: {{{ varnishd -F -a 0.0.0.0:80 -f /usr/local/etc/vcl.conf \ -u nobody -g nobody \ -T 10.71.5.25:8080 \ -s file,/data0/varnish/v,16G \ -s file,/data1/varnish/v,16G \ -s file,/data2/varnish/v,16G \ -s file,/data3/varnish/v,16G \ -w 300,3000,600 \ -h classic,500009 \ -p thread_pools=2 \ -p thread_pool_max=3000 \ -p sess_workspace=16384 -p listen_depth=4096 \ -p lru_interval=3600 \ -p ping_interval=10 >> $logdir/varnish.out 2>&1 }}} {{{ ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 33554432 stack size (kbytes, -s) 524288 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 5547 open files (-n) 98304 virtual mem size (kbytes, -v) unlimited sbsize (bytes, -b) unlimited }}} log information: {{{ Jul 15 16:58:54 236-25 varnishd[19424]: child (19429) Started Jul 15 16:58:54 236-25 varnishd[19424]: Child (19429) said Closed fds: 7 8 11 12 14 15 Jul 15 16:58:54 236-25 varnishd[19424]: Child (19429) said Child starts Jul 15 16:58:54 236-25 varnishd[19424]: Child (19429) said managed to mmap 17179869184 bytes of 17179869184 Jul 15 16:58:54 236-25 varnishd[19424]: Child (19429) said Ready Jul 16 15:30:09 236-25 varnishd[19424]: Child (19429) not responding to ping, killing it. Jul 16 15:30:56 236-25 varnishd[19424]: Child (19429) not responding to ping, killing it. Jul 16 15:30:59 236-25 kernel: pid 19429 (varnishd), uid 65534: exited on signal 6 (core dumped) Jul 16 15:30:59 236-25 varnishd[19424]: child (34746) Started Jul 16 15:31:00 236-25 varnishd[19424]: Child (34746) said Closed fds: 7 8 11 12 14 15 Jul 16 15:31:00 236-25 varnishd[19424]: Child (34746) said Child starts Jul 16 15:31:00 236-25 varnishd[19424]: Child (34746) said managed to mmap 17179869184 bytes of 17179869184 Jul 16 15:31:00 236-25 varnishd[19424]: Child (34746) said Ready }}} My VCL: {{{ backend image2 { .host = "10.71.5.248"; .port = "80"; } backend ad4 { .host = "10.71.5.247"; .port = "80"; } sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; hash; } sub vcl_hit { deliver; } sub vcl_miss { fetch; } sub vcl_recv { if ( req.request != "GET" && req.request != "HEAD" ) { error 403 "Invalid request method."; } elseif ( req.http.host == "image2.myserver.com.cn" || req.http.host ~ ".myserverimg.cn$" ) { set req.backend = image2; } elseif ( req.http.host ~ "^d[0-9].myserver.com.cn$" || req.http.host == "ad4.myserver.com.cn" || req.http.host ~ "^a[0-9].myserver.com.cn$" ) { set req.backend = ad4; } else { error 403 "Request denied."; } if (req.request == "GET" && req.http.cookie) { lookup; } lookup; } sub vcl_fetch { if ( req.http.host == "image2.myserver.com.cn" || req.http.host ~ ".myserverimg.cn$" ) { set obj.ttl = 86400s; } elseif ( req.http.host ~ "^d[0-9].myserver.com.cn$" || req.http.host == "ad4.myserver.com.cn" || req.http.host ~ "^a[0-9].myserver.com.cn$" ) { set obj.ttl = 300s; } if (obj.http.Set-Cookie) { insert; } insert; } sub vcl_deliver { deliver; } sub vcl_timeout { discard; } sub vcl_discard { discard; } }}} Backtrace: {{{ ...... [New Thread 0x806105ec0 (LWP 100128)] [New Thread 0x806103f20 (LWP 100105)] [New Thread 0x806103960 (LWP 100101)] [New Thread 0x806102de0 (LWP 100091)] [New Thread 0x806102990 (LWP 100087)] [New Thread 0x8061020f0 (LWP 100076)] [New Thread 0x806101f80 (LWP 100074)] [New Thread 0x806101e10 (LWP 100073)] [New Thread 0x8061016e0 (LWP 100060)] [New Thread 0x800f01850 (LWP 100056)] [New Thread 0x800f016e0 (LWP 100055)] [New Thread 0x800f01570 (LWP 100049)] [New Thread 0x800f01400 (LWP 100048)] [New Thread 0x800f01290 (LWP 100046)] [New Thread 0x800f01120 (LWP 100448)] (gdb) bt #0 0x0000000800dae871 in fwrite () from /lib/libc.so.7 #1 0x0000000800da428b in strchr () from /lib/libc.so.7 #2 0x0000000800da5f13 in strchr () from /lib/libc.so.7 #3 0x0000000800d2702c in vsnprintf () from /lib/libc.so.7 #4 0x00000000004329b3 in VSL (tag=SLT_WorkThread, id=0, fmt=0x43c630 "%p start") at shmlog.c:159 #5 0x000000000041c0de in wrk_thread (priv=0x800f620b0) at cache_pool.c:221 #6 0x0000000800aaba38 in pthread_getprio () from /lib/libthr.so.3 #7 0x00007fff4dc73000 in ?? () Cannot access memory at address 0x7fff4de73000 (gdb) frame 5 #5 0x000000000041c0de in wrk_thread (priv=0x800f620b0) at cache_pool.c:221 221 VSL(SLT_WorkThread, 0, "%p start", w); (gdb) print *w $1 = {magic = 1670491599, nobjhead = 0x0, nobj = 0x0, used = 1216193378.3797276, cond = 0x1825a1b340, list = { vtqe_next = 0x0, vtqe_prev = 0x0}, wrq = 0x0, wfd = 0x0, werr = 0, iov = {{iov_base = 0x0, iov_len = 0} }, niov = 0, liov = 0, vcl = 0x0, srcaddr = 0x0, acct = {first = 0, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, wlb = 0x7fff4de70ad0 "\004", wlp = 0x7fff4de70ad0 "\004", wle = 0x7fff4de72ad0 "?-\221c", wlr = 0} (gdb) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 13:09:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 13:09:43 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop Message-ID: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- We have a deployment with two varnish services in a load balanced setup. Both servers were started at the same time and both stopped working at the same time today. The observed symptoms were varnish eating 100% CPU time and not responding to requests at all. strace of the varnish process showed 27 threads running. Most of them were not doing anything, but one thread was showing a busy-loop: {{{ poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 164448162}) = 0 accept(6, 0x6fc69334, [128]) = -1 EMFILE (Too many open files) poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 164861833}) = 0 accept(6, 0x6fc69334, [128]) = -1 EMFILE (Too many open files) poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 165164688}) = 0 accept(6, 0x6fc69334, [128]) = -1 EMFILE (Too many open files) poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 165463395}) = 0 accept(6, 0x6fc69334, [128]) = -1 EMFILE (Too many open files) poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 165756394}) = 0 accept(6, 0x6fc69334, [128]) = -1 EMFILE (Too many open files) poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 1000) = 1 clock_gettime(CLOCK_REALTIME, {1216213167, 166071370}) = 0 }}} We saw the exact same behaviour on one of the servers last week (the other server was not running at the time). Both servers are running trunk as of r2877. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 13:12:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 13:12:17 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.c0b5966112cc051e6b9a0459012f6641@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Did you capture a varnishstat snapshot before you restated the servers ? Otherwise, please do so if it happens again, that might likely contain clues to were the leap could be. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 16 13:18:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 16 Jul 2008 13:18:10 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.7d8a6563992b6b1718c43eb6d4ffaf8a@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): Unfortuantely strace managed to kill varnishd so I could not get any further data. The munin logs for the machine did show an interesting pattern in the netstat data: it seems the number of established connections keeps increasing until varnishd run out of fds and needs to be restarted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 08:48:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 08:48:48 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.cb204712682148bb3a76fee4874a5b70@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by phk): In all likelyhood 3000 threads is waaay to many and the system is probably dyign trying to create that many. check in varnishstat how many threads you have on average, and set the max to 150% of that number. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 08:55:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 08:55:12 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.9078306c267fd7c206d6d0adbdb76b17@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: "I guess its time to go 64bit, seems silly when the current servers are 90% idle" It's two different dimensions really. 64bit is about how much memory your CPU can address. The cpu being idle is about how much work there is for it to do. I will warmly recommend going 64bit for varnish if you have more than about 1.5 GB of cached data. I'm not sure I see a bug here, so I'll take the liberty of closing the ticket with "worksforme" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 10:07:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 10:07:01 -0000 Subject: [Varnish] #208: Show a subset of the full statistics In-Reply-To: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no> References: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no> Message-ID: <058.2f3cfe6a3ddcaa548b34e7f2fa33d245@projects.linpro.no> #208: Show a subset of the full statistics -------------------------+-------------------------------------------------- Reporter: des | Owner: petter Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed Comment: Fixed in r2946. Use the new and shining -f to select the fields and -l options to list the available fields. Starting the field list with ^ will exclude the listed fields. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 10:17:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 10:17:58 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.3f77922e09b4b0fffe4a31db6154f57a@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): Thanks for response!! I see something like wichert's report..."The observed symptoms were varnish eating 100% CPU time and not responding to requests at all" .[[BR]] I write a program for debug today. [[BR]] It checks varnishstat's data and netstat's status. It gets data every two seconds. program: {{{ #!/bin/sh # # $Id: Check Varnish.in,v 0.1 2008/07/17 14:20:36 $ logdir=/usr/home/xiaoyong while : ; do echo "Startup: `date`">>$logdir/check.out echo "Running: ">>$logdir/check.out echo "varnishstat -1">>$logdir/check.out 2>&1 varnishstat -1 >>$logdir/check.out 2>&1 echo "---------------------------------------------">>$logdir/check.out echo "netstat -na >netstat_na.tmp 2>&1">>$logdir/check.out netstat -na >$logdir/netstat_na.tmp 2>&1 echo "cat netstat_na.tmp|grep 'tcp'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'tcp'|wc -l >> $logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'LISTEN'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'LISTEN'|wc -l >> $logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'SYN_RCVD'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'ESTABLISHED'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'LAST_ACK'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'LAST_ACK'|wc -l >> $logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'CLOSING'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'CLOSING'|wc -l >>$logdir/check.out 2>&1 echo "cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l">>$logdir/check.out cat $logdir/netstat_na.tmp|grep 'TIME_WAIT'|wc -l >>$logdir/check.out 2>&1 echo "---------------------------------------------">>$logdir/check.out echo "Stop: `date`" >>$logdir/check.out sleep 2 done }}} I see varnish child stunk again today. please see messages log messages: {{{ Jul 17 16:21:58 236-25 varnishd[19424]: Child (49408) not responding to ping, killing it. Jul 17 16:21:58 236-25 varnishd[19424]: Child (49408) not responding to ping, killing it. Jul 17 16:21:58 236-25 varnishd[19424]: child (69563) Started Jul 17 16:21:59 236-25 varnishd[19424]: Child (69563) said Closed fds: 7 8 11 12 14 15 Jul 17 16:21:59 236-25 varnishd[19424]: Child (69563) said Child starts Jul 17 16:21:59 236-25 varnishd[19424]: Child (69563) said managed to mmap 17179869184 bytes of 17179869184 Jul 17 16:21:59 236-25 varnishd[19424]: Child (69563) said Ready }}} now,please see check.out file.[[BR]] please see these lines:[[BR]] '''Stop: Thu Jul 17 16:21:30 CST 2008''' [[BR]] '''Startup: Thu Jul 17 16:21:58 CST 2008''' [[BR]] varnishd block 20-30 seconds?! It uses cpu time about 20-30 seconds ? check.out: {{{ ...... Startup: Thu Jul 17 16:21:25 CST 2008 Running: varnishstat -1 client_conn 2734292 226.18 Client connections accepted client_req 12120889 1002.64 Client requests received cache_hit 11890628 983.59 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 229800 19.01 Cache misses backend_conn 229800 19.01 Backend connections success backend_fail 0 0.00 Backend connections failures backend_reuse 229180 18.96 Backend connections reuses backend_recycle 229383 18.97 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 3008 . N struct srcaddr n_srcaddr_act 959 . N active struct srcaddr n_sess_mem 3574 . N struct sess_mem n_sess 2457 . N struct sess n_object 178395 . N struct object n_objecthead 178307 . N struct objecthead n_smf 356462 . N struct smf n_smf_frag 16 . N small free smf n_smf_large 1 . N large free smf n_vbe_conn 13 . N struct vbe_conn n_bereq 59 . N struct bereq n_wrk 0 . N worker threads n_wrk_create 281 0.02 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 51683 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 104388 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 4742690 392.31 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 2733858 226.14 Total Sessions s_req 12120922 1002.64 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 229797 19.01 Total fetch s_hdrbytes 2897869511 239711.27 Total header bytes s_bodybytes 29738672798 2459977.90 Total body bytes sess_closed 124542 10.30 Session Closed sess_pipeline 628 0.05 Session Pipeline sess_readahead 263 0.02 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 12062626 997.82 Session herd shm_records 438364349 36261.42 SHM records shm_writes 32586430 2695.54 SHM writes shm_flushes 341 0.03 SHM flushes due to overflow shm_cont 40486 3.35 SHM MTX contention sm_nreq 459796 38.03 allocator requests sm_nobj 356439 . outstanding allocations sm_balloc 4841578496 . bytes allocated sm_bfree 63877898240 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free backend_req 229800 19.01 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded --------------------------------------------- netstat -na >netstat_na.tmp 2>&1 cat netstat_na.tmp|grep 'tcp'|wc -l 9386 cat netstat_na.tmp|grep 'LISTEN'|wc -l 5 cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l 230 cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l 2320 cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l 2 cat netstat_na.tmp|grep 'LAST_ACK'|wc -l 113 cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l 831 cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l 5462 cat netstat_na.tmp|grep 'CLOSING'|wc -l 2 cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l 420 --------------------------------------------- Stop: Thu Jul 17 16:21:25 CST 2008 Startup: Thu Jul 17 16:21:27 CST 2008 Running: varnishstat -1 client_conn 2734811 226.19 Client connections accepted client_req 12123179 1002.66 Client requests received cache_hit 11892890 983.62 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 229828 19.01 Cache misses backend_conn 229828 19.01 Backend connections success backend_fail 0 0.00 Backend connections failures backend_reuse 229208 18.96 Backend connections reuses backend_recycle 229411 18.97 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 3027 . N struct srcaddr n_srcaddr_act 979 . N active struct srcaddr n_sess_mem 3574 . N struct sess_mem n_sess 2506 . N struct sess n_object 178414 . N struct object n_objecthead 178323 . N struct objecthead n_smf 356500 . N struct smf n_smf_frag 15 . N small free smf n_smf_large 1 . N large free smf n_vbe_conn 13 . N struct vbe_conn n_bereq 59 . N struct bereq n_wrk 0 . N worker threads n_wrk_create 281 0.02 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 51691 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 104413 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 4743582 392.32 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 2734367 226.15 Total Sessions s_req 12123210 1002.66 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 229823 19.01 Total fetch s_hdrbytes 2898417011 239716.90 Total header bytes s_bodybytes 29743733127 2459989.51 Total body bytes sess_closed 124567 10.30 Session Closed sess_pipeline 628 0.05 Session Pipeline sess_readahead 263 0.02 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 12064901 997.84 Session herd shm_records 438446414 36262.21 SHM records shm_writes 32592493 2695.60 SHM writes shm_flushes 341 0.03 SHM flushes due to overflow shm_cont 40492 3.35 SHM MTX contention sm_nreq 459851 38.03 allocator requests sm_nobj 356478 . outstanding allocations sm_balloc 4842508288 . bytes allocated sm_bfree 63876968448 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free backend_req 229828 19.01 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded --------------------------------------------- netstat -na >netstat_na.tmp 2>&1 cat netstat_na.tmp|grep 'tcp'|wc -l 9473 cat netstat_na.tmp|grep 'LISTEN'|wc -l 5 cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l 221 cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l 2368 cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l 1 cat netstat_na.tmp|grep 'LAST_ACK'|wc -l 98 cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l 837 cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l 5462 cat netstat_na.tmp|grep 'CLOSING'|wc -l 2 cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l 477 --------------------------------------------- Stop: Thu Jul 17 16:21:27 CST 2008 Startup: Thu Jul 17 16:21:30 CST 2008 Running: varnishstat -1 client_conn 2735317 226.17 Client connections accepted client_req 12125574 1002.61 Client requests received cache_hit 11895258 983.57 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 229855 19.01 Cache misses backend_conn 229855 19.01 Backend connections success backend_fail 0 0.00 Backend connections failures backend_reuse 229235 18.95 Backend connections reuses backend_recycle 229438 18.97 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 3043 . N struct srcaddr n_srcaddr_act 983 . N active struct srcaddr n_sess_mem 3574 . N struct sess_mem n_sess 2536 . N struct sess n_object 178422 . N struct object n_objecthead 178332 . N struct objecthead n_smf 356528 . N struct smf n_smf_frag 27 . N small free smf n_smf_large 1 . N large free smf n_vbe_conn 13 . N struct vbe_conn n_bereq 59 . N struct bereq n_wrk 0 . N worker threads n_wrk_create 281 0.02 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 51710 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 104460 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 4744498 392.30 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 2734865 226.13 Total Sessions s_req 12125609 1002.61 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 229851 19.01 Total fetch s_hdrbytes 2898989553 239704.78 Total header bytes s_bodybytes 29749433848 2459850.66 Total body bytes sess_closed 124591 10.30 Session Closed sess_pipeline 628 0.05 Session Pipeline sess_readahead 263 0.02 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 12067284 997.79 Session herd shm_records 438532393 36260.33 SHM records shm_writes 32598768 2695.45 SHM writes shm_flushes 341 0.03 SHM flushes due to overflow shm_cont 40495 3.35 SHM MTX contention sm_nreq 459905 38.03 allocator requests sm_nobj 356494 . outstanding allocations sm_balloc 4843315200 . bytes allocated sm_bfree 63876161536 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free backend_req 229855 19.01 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded --------------------------------------------- netstat -na >netstat_na.tmp 2>&1 cat netstat_na.tmp|grep 'tcp'|wc -l 9520 cat netstat_na.tmp|grep 'LISTEN'|wc -l 5 cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l 252 cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l 2399 cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l 1 cat netstat_na.tmp|grep 'LAST_ACK'|wc -l 94 cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l 846 cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l 5449 cat netstat_na.tmp|grep 'CLOSING'|wc -l 2 cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l 471 --------------------------------------------- Stop: Thu Jul 17 16:21:30 CST 2008 Startup: Thu Jul 17 16:21:58 CST 2008 Running: varnishstat -1 client_conn 2745062 226.45 Client connections accepted client_req 12143425 1001.77 Client requests received cache_hit 11912859 982.75 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 230047 18.98 Cache misses backend_conn 229967 18.97 Backend connections success backend_fail 0 0.00 Backend connections failures backend_reuse 229312 18.92 Backend connections reuses backend_recycle 229504 18.93 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 3115 . N struct srcaddr n_srcaddr_act 716 . N active struct srcaddr n_sess_mem 3574 . N struct sess_mem n_sess 3459 . N struct sess n_object 178434 . N struct object n_objecthead 178368 . N struct objecthead n_smf 356578 . N struct smf n_smf_frag 13 . N small free smf n_smf_large 1 . N large free smf n_vbe_conn 47 . N struct vbe_conn n_bereq 59 . N struct bereq n_wrk 0 . N worker threads n_wrk_create 285 0.02 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 51743 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 104628 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 4751108 391.94 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 2738965 225.95 Total Sessions s_req 12143265 1001.75 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 229918 18.97 Total fetch s_hdrbytes 2903173195 239496.22 Total header bytes s_bodybytes 29789221885 2457451.07 Total body bytes sess_closed 124927 10.31 Session Closed sess_pipeline 628 0.05 Session Pipeline sess_readahead 263 0.02 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 12084683 996.92 Session herd shm_records 439170084 36229.18 SHM records shm_writes 32656119 2693.95 SHM writes shm_flushes 341 0.03 SHM flushes due to overflow shm_cont 40535 3.34 SHM MTX contention sm_nreq 460032 37.95 allocator requests sm_nobj 356553 . outstanding allocations sm_balloc 4844146688 . bytes allocated sm_bfree 63875330048 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free backend_req 229967 18.97 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded --------------------------------------------- netstat -na >netstat_na.tmp 2>&1 cat netstat_na.tmp|grep 'tcp'|wc -l 10565 cat netstat_na.tmp|grep 'LISTEN'|wc -l 5 cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l 441 cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l 1796 cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l 487 cat netstat_na.tmp|grep 'LAST_ACK'|wc -l 92 cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l 826 cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l 5442 cat netstat_na.tmp|grep 'CLOSING'|wc -l 2 cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l 368 --------------------------------------------- Stop: Thu Jul 17 16:21:58 CST 2008 Startup: Thu Jul 17 16:22:00 CST 2008 Running: varnishstat -1 client_conn 811 811.00 Client connections accepted client_req 1102 1102.00 Client requests received cache_hit 703 703.00 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 398 398.00 Cache misses backend_conn 398 398.00 Backend connections success backend_fail 0 0.00 Backend connections failures backend_reuse 384 384.00 Backend connections reuses backend_recycle 393 393.00 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 413 . N struct srcaddr n_srcaddr_act 408 . N active struct srcaddr n_sess_mem 792 . N struct sess_mem n_sess 792 . N struct sess n_object 420 . N struct object n_objecthead 419 . N struct objecthead n_smf 818 . N struct smf n_smf_frag 0 . N small free smf n_smf_large 4 . N large free smf n_vbe_conn 14 . N struct vbe_conn n_bereq 11 . N struct bereq n_wrk 0 . N worker threads n_wrk_create 56 56.00 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 2 . N backends n_expired 0 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 0 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 362 362.00 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 769 769.00 Total Sessions s_req 1085 1085.00 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 382 382.00 Total fetch s_hdrbytes 245581 245581.00 Total header bytes s_bodybytes 1753432 1753432.00 Total body bytes sess_closed 11 11.00 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 0 0.00 Session Read Ahead sess_linger 0 0.00 Session Linger sess_herd 1081 1081.00 Session herd shm_records 52031 52031.00 SHM records shm_writes 3095 3095.00 SHM writes shm_flushes 0 0.00 SHM flushes due to overflow shm_cont 5 5.00 SHM MTX contention sm_nreq 814 814.00 allocator requests sm_nobj 814 . outstanding allocations sm_balloc 8380416 . bytes allocated sm_bfree 68711096320 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free backend_req 398 398.00 Backend requests made n_vcl 1 1.00 N vcl total n_vcl_avail 1 1.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded --------------------------------------------- netstat -na >netstat_na.tmp 2>&1 cat netstat_na.tmp|grep 'tcp'|wc -l 9416 cat netstat_na.tmp|grep 'LISTEN'|wc -l 5 cat netstat_na.tmp|grep 'SYN_RCVD'|wc -l 456 cat netstat_na.tmp|grep 'ESTABLISHED'|wc -l 808 cat netstat_na.tmp|grep 'CLOSE_WAIT'|wc -l 0 cat netstat_na.tmp|grep 'LAST_ACK'|wc -l 114 cat netstat_na.tmp|grep 'FIN_WAIT_1'|wc -l 866 cat netstat_na.tmp|grep 'FIN_WAIT_2'|wc -l 5206 cat netstat_na.tmp|grep 'CLOSING'|wc -l 2 cat netstat_na.tmp|grep 'TIME_WAIT'|wc -l 1958 --------------------------------------------- Stop: Thu Jul 17 16:22:00 CST 2008 ...... }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 10:22:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 10:22:51 -0000 Subject: [Varnish] #104: varnishncsa assertion fails sometimes In-Reply-To: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> References: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> Message-ID: <064.b99149667ac122fcc081cd34295b4273@projects.linpro.no> #104: varnishncsa assertion fails sometimes -------------------------+-------------------------------------------------- Reporter: dirkgomez | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 1.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * owner: des => petter * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 10:22:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 10:22:55 -0000 Subject: [Varnish] #104: varnishncsa assertion fails sometimes In-Reply-To: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> References: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> Message-ID: <064.6d007e871d1d9cce8507a5355ce7f1b7@projects.linpro.no> #104: varnishncsa assertion fails sometimes -------------------------+-------------------------------------------------- Reporter: dirkgomez | Owner: petter Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: 1.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 11:32:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 11:32:49 -0000 Subject: [Varnish] #126: SYN_ErrorPage() TTL should be a parameter In-Reply-To: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> References: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> Message-ID: <058.e911b8614b8deab924f54ca660c3d9ca@projects.linpro.no> #126: SYN_ErrorPage() TTL should be a parameter ----------------------+----------------------------------------------------- Reporter: des | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by petter): * owner: des => petter -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 17 11:32:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Jul 2008 11:32:53 -0000 Subject: [Varnish] #126: SYN_ErrorPage() TTL should be a parameter In-Reply-To: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> References: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> Message-ID: <058.7c28b34d56a74ff6348ca056c5c2387e@projects.linpro.no> #126: SYN_ErrorPage() TTL should be a parameter ----------------------+----------------------------------------------------- Reporter: des | Owner: petter Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by petter): * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 18 03:06:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 18 Jul 2008 03:06:20 -0000 Subject: [Varnish] #277: rfc2616.c marks expired content as acachable Message-ID: <054.30150cc1435b6fc108d1531e06bfac89@projects.linpro.no> #277: rfc2616.c marks expired content as acachable ----------------------+----------------------------------------------------- Reporter: richardc | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: caching rfc2616 ----------------------+----------------------------------------------------- I've been trying to get varnishd to not cache certain dynamic pages in my website. After spending some time reviewing the code in rfc2616.c adding additional logging and experimenting with cache control headers I have come to the conclusion that the code does not detect content with expiry dates in the past, as not cacheable. Near the bottom of RFC2616_cache_policy(): {{{ sp->obj->ttl = RFC2616_Ttl(sp, hp, sp->obj); if (sp->obj->ttl = 0) { sp->obj->cacheable = 0; } }}} The object is marked as not cacheable if RFC2616_Ttl() returns zero, however RFC2616_Ttl() returns the time to die as a unix timestamp. Instead I am using: {{{ sp->obj->ttl = RFC2616_Ttl(sp, hp, sp->obj); if (sp->obj->ttl <= sp->obj->entered) { sp->obj->cacheable = 0; } }}} However, RFC2616_Ttl() tries to detect clock skew, which has the effect that it never returns a time in the past. I have relaxed this clock skew detection by changing line 142 from: {{{ if (h_date < obj->entered && h_expires > obj->entered) { }}} to: {{{ if (h_date <= obj->entered) { }}} This seems to do the trick. I've also observed that RFC2616_Ttl() does not pay any attention to "Pragma: no-cache", and "Cache-Control: no-cache, must-revalidate" headers. I'm not an expert on RFC2616 and wouldn't be surprised if this was not standard compliant, however it is standard practice to use dates from the past, along with a plethora of cache control headers to stop pages from being cached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 18 07:02:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 18 Jul 2008 07:02:20 -0000 Subject: [Varnish] #126: SYN_ErrorPage() TTL should be a parameter In-Reply-To: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> References: <049.99e0c0710678c3cd2a4bfd5ebedf9e31@projects.linpro.no> Message-ID: <058.3411625a86ca9a15f1237ee8a683ab07@projects.linpro.no> #126: SYN_ErrorPage() TTL should be a parameter ----------------------+----------------------------------------------------- Reporter: des | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by petter): * status: assigned => closed * resolution: => fixed Comment: Added the parameter err_ttl with a default value of 0. Fixed in r2949. -- Ticket URL: Varnish The Varnish HTTP Accelerator From MAILER-DAEMON at projects.linpro.no Sat Jul 19 01:35:35 2008 From: MAILER-DAEMON at projects.linpro.no (Mail Delivery System) Date: Sat, 19 Jul 2008 03:35:35 +0200 (CEST) Subject: Undelivered Mail Returned to Sender Message-ID: <20080719013535.977591EC10F@projects.linpro.no> This is the mail system at host projects.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 : connect to sohumx.h.a.sohu.com[61.135.132.110]: Connection timed out -------------- next part -------------- An embedded message was scrubbed... From: "Varnish" Subject: Re: [Varnish] #132: Varnish 1.1 dies with assert error in SES_Delete Date: Mon, 14 Jul 2008 01:32:25 -0000 Size: 2426 URL: From varnish-bugs at projects.linpro.no Sat Jul 19 14:54:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 19 Jul 2008 14:54:06 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.d39e74c44294822069c5061a66f5381a@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): I changed the running's parameters {{{ varnishd -F -a 0.0.0.0:80 -f /usr/local/etc/vcl.conf \ -u nobody -g nobody \ -T 10.71.5.25:8080 \ -s file,/data0/varnish/v,16G \ -s file,/data1/varnish/v,16G \ -s file,/data2/varnish/v,16G \ -s file,/data3/varnish/v,16G \ -w 200,600,600 \ -h classic,500009 \ -p thread_pools=4 \ -p sess_workspace=16384 -p listen_depth=4096 \ -p lru_interval=3600 \ -p ping_interval=10 >> $logdir/varnish.out 2>&1 }}} set thread_pool_max=600 but stops responding again. threads are usually around 300 {{{ last pid: 38078; load averages: 0.03, 0.08, 0.11 up 127+10:26:46 22:48:48 232 processes: 1 running, 231 sleeping CPU states: 3.2% user, 0.0% nice, 2.1% system, 2.1% interrupt, 92.7% idle Mem: 2897M Active, 348M Inact, 530M Wired, 141M Cache, 214M Buf, 3924K Free Swap: 8192M Total, 50M Used, 8142M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 20890 nobody 207 96 0 66092M 3057M ucond 0 96:16 0.78% varnishd 611 root 1 96 0 10600K 752K select 0 2:05 0.00% sendmail 52548 root 1 8 0 6248K 380K wait 0 1:54 0.00% sh 93614 root 2 -8 0 10844K 1784K piperd 1 1:03 0.00% cfexecd 739 root 1 8 0 5736K 380K nanslp 1 0:35 0.00% cron 509 root 1 96 0 4684K 384K select 1 0:19 0.00% syslogd 733 smmsp 1 20 0 10600K 584K pause 0 0:02 0.00% sendmail 18982 root 1 96 0 92336K 82908K select 0 0:00 0.00% varnishd 38068 xiaoyong 1 96 0 7692K 2104K CPU1 0 0:00 0.00% top ...... }}} Replying to [comment:1 phk]: > In all likelyhood 3000 threads is waaay to many and the system is probably dyign trying to create that many. > > check in varnishstat how many threads you have on average, and set the max to 150% of that number. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 11:17:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 11:17:24 -0000 Subject: [Varnish] #264: server.port VCL variable In-Reply-To: <050.5d9930495dd68b333b50efa6dc82d62a@projects.linpro.no> References: <050.5d9930495dd68b333b50efa6dc82d62a@projects.linpro.no> Message-ID: <059.c07cd7332d3408e3d1fd9638335a0577@projects.linpro.no> #264: server.port VCL variable -------------------------+-------------------------------------------------- Reporter: adam | Owner: petter Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: vcl | -------------------------+-------------------------------------------------- Changes (by petter): * owner: des => petter -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 11:17:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 11:17:50 -0000 Subject: [Varnish] #244: Option to set the page size In-Reply-To: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> References: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> Message-ID: <061.19e08a4a7f380ec1699ff16d369b9f83@projects.linpro.no> #244: Option to set the page size -------------------------+-------------------------------------------------- Reporter: anders | Owner: petter Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * owner: phk => petter -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 11:18:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 11:18:47 -0000 Subject: [Varnish] #74: varnish doesn't clean /tmp/files during runtime. In-Reply-To: <052.4da4f6dd9ba900b71b218fa1d01145a2@projects.linpro.no> References: <052.4da4f6dd9ba900b71b218fa1d01145a2@projects.linpro.no> Message-ID: <061.11332229624cfeb965fd9bcdca5fc4e6@projects.linpro.no> #74: varnish doesn't clean /tmp/files during runtime. --------------------+------------------------------------------------------- Reporter: bahner | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by petter): * owner: des => petter -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 16:29:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 16:29:59 -0000 Subject: [Varnish] #278: Varnish at some point can't handle a spesific URL Message-ID: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> #278: Varnish at some point can't handle a spesific URL ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Keywords: PURGE ----------------------+----------------------------------------------------- Sometime varnish won't handle a specific URL. After a restart. Everything is back to normal. This happens quite often, and usually with with a specific URL. This works: (talking to backend) [root at fritz ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 HTTP/1.1 200 OK This works: (talking to backend) [root at fritz ~]# echo -e "GET /sport/fotball HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 HTTP/1.1 301 Moved Permanently This works: (talking to varnish on localhost) [root at fritz ~]# echo -e "GET /sport/fotball HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 HTTP/1.1 301 Moved Permanently This does not work at the moment on one of the varnishes: [root at fritz ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 It just hangs forever. ( waited up to 10 minutes ) Running on another varnish it works [root at maddie ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 HTTP/1.1 200 OK Same varnish, same vcl Varnishlog on the working varnish 2315 ReqStart c 127.0.0.1 51162 512297753 2315 RxRequest c GET 2315 RxURL c /sport/fotball/ 2315 RxProtocol c HTTP/1.0 2315 RxHeader c Host:www.vg.no 2315 VCL_call c recv lookup 2315 VCL_call c hash hash 2315 Hit c 510694686 2315 VCL_call c hit deliver 2315 Length c 158261 2315 VCL_call c deliver deliver 2315 TxProtocol c HTTP/1.1 2315 TxStatus c 200 2315 TxResponse c OK 2315 TxHeader c Server: Apache/1.3.27 (Unix) 2315 TxHeader c X-VG-WebServer: leonora, leonora 2315 TxHeader c Cache-Control: max-age=3600 2315 TxHeader c Expires: Mon, 21 Jul 2008 14:49:42 GMT 2315 TxHeader c Content-Type: text/html 2315 TxHeader c Content-Length: 158261 2315 TxHeader c X-VG-WebCache: maddie 2315 TxHeader c Date: Mon, 21 Jul 2008 14:03:24 GMT 2315 TxHeader c X-Varnish: 512297753 510694686 2315 TxHeader c Age: 822 2315 TxHeader c Via: 1.1 varnish 2315 TxHeader c Connection: close 2315 ReqEnd c 512297753 1216649004.307805061 1216649004.308098078 0.00003 0994 0.000028849 0.000264168 The non working 38070 SessionOpen c 127.0.0.1 56364 :80 38070 ReqStart c 127.0.0.1 56364 3818273786 38070 RxRequest c GET 38070 RxURL c /sport/fotball/ 38070 RxProtocol c HTTP/1.0 38070 RxHeader c Host:www.vg.no 38070 VCL_call c recv lookup 38070 VCL_call c hash hash Then nothing happens. No miss no hit Purge working version (hit) 3461 RxRequest c PURGE 3461 RxURL c /sport/fotball/ 3461 RxProtocol c HTTP/1.0 3461 RxHeader c Host:www.vg.no 3461 VCL_call c recv 3461 VCL_acl c MATCH purge "localhost" 3461 VCL_return c lookup 3461 VCL_call c hash hash 3461 Hit c 510694686 3461 VCL_call c hit 3461 TTL c 510694686 VCL 0 1216649372 3461 VCL_return c error 3461 SessionClose c error returned 3461 TxProtocol c HTTP/1.0 3461 TxStatus c 200 3461 TxResponse c OK 3461 TxHeader c Date: Mon, 21 Jul 2008 14:09:32 GMT 3461 TxHeader c Server: Varnish 3461 TxHeader c Retry-After: 0 3461 TxHeader c Content-Type: text/html; charset=utf-8 3461 TxHeader c X-Varnish: 513000671 3461 TxHeader c Connection: close 3461 ReqEnd c 513000671 1216649372.271184921 1216649372.271277905 0.00005 1975 nan nan Pruge Working version (miss) 5750 RxRequest c PURGE 5750 RxURL c /sport/fotball/ 5750 RxProtocol c HTTP/1.0 5750 RxHeader c Host:www.vg.no 5750 VCL_call c recv 5750 VCL_acl c MATCH purge "localhost" 5750 VCL_return c lookup 5750 VCL_call c hash hash 5750 VCL_call c miss error 5750 SessionClose c error returned 5750 TxProtocol c HTTP/1.0 5750 TxStatus c 404 5750 TxResponse c Not Found 5750 TxHeader c Date: Mon, 21 Jul 2008 14:10:49 GMT 5750 TxHeader c Server: Varnish 5750 TxHeader c Retry-After: 0 5750 TxHeader c Content-Type: text/html; charset=utf-8 5750 TxHeader c X-Varnish: 513145422 5750 TxHeader c Connection: close 5750 ReqEnd c 513145422 1216649449.873359919 1216649449.873445988 0.00004 6968 nan nan Purge non working version: 36848 RxRequest c PURGE 36848 RxURL c /sport/fotball/ 36848 RxProtocol c HTTP/1.0 36848 RxHeader c Host:www.vg.no 36848 VCL_call c recv 36848 VCL_acl c MATCH purge "localhost" 36848 VCL_return c lookup 36848 VCL_call c hash hash varnish-2.0-trunk2914 on redhat 5.2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 20:09:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 20:09:16 -0000 Subject: [Varnish] #244: Option to set the page size In-Reply-To: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> References: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> Message-ID: <061.c5f91f1bb12fedde8d2a35f161e678c4@projects.linpro.no> #244: Option to set the page size -------------------------+-------------------------------------------------- Reporter: anders | Owner: petter Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by phk): I cleaned up the "subargument" processing to hash and stevedores this past weekend in part to be able to make this change work sensibly. The way this should be done is to add yet another subargument being the pagesize to use. In other words: {{{ -sfile,,, }}} It should be a very trivial to implement now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 20:11:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 20:11:00 -0000 Subject: [Varnish] #278: Varnish at some point can't handle a spesific URL In-Reply-To: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> References: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> Message-ID: <057.920d5c71da2d0932e5fc845d6700f46e@projects.linpro.no> #278: Varnish at some point can't handle a spesific URL ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: PURGE | ----------------------+----------------------------------------------------- Old description: > Sometime varnish won't handle a specific URL. After a restart. Everything > is back to normal. This happens quite often, and usually with with a > specific URL. > > This works: (talking to backend) > [root at fritz ~]# echo -e "GET /sport/fotball/ > HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 > HTTP/1.1 200 OK > > This works: (talking to backend) > [root at fritz ~]# echo -e "GET /sport/fotball > HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 > HTTP/1.1 301 Moved Permanently > > This works: (talking to varnish on localhost) > [root at fritz ~]# echo -e "GET /sport/fotball > HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 > HTTP/1.1 301 Moved Permanently > > This does not work at the moment on one of the varnishes: > > [root at fritz ~]# echo -e "GET /sport/fotball/ > HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 > > It just hangs forever. ( waited up to 10 minutes ) > > Running on another varnish it works > > [root at maddie ~]# echo -e "GET /sport/fotball/ > HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 > HTTP/1.1 200 OK > > Same varnish, same vcl > > Varnishlog on the working varnish > > 2315 ReqStart c 127.0.0.1 51162 512297753 > 2315 RxRequest c GET > 2315 RxURL c /sport/fotball/ > 2315 RxProtocol c HTTP/1.0 > 2315 RxHeader c Host:www.vg.no > 2315 VCL_call c recv lookup > 2315 VCL_call c hash hash > 2315 Hit c 510694686 > 2315 VCL_call c hit deliver > 2315 Length c 158261 > 2315 VCL_call c deliver deliver > 2315 TxProtocol c HTTP/1.1 > 2315 TxStatus c 200 > 2315 TxResponse c OK > 2315 TxHeader c Server: Apache/1.3.27 (Unix) > 2315 TxHeader c X-VG-WebServer: leonora, leonora > 2315 TxHeader c Cache-Control: max-age=3600 > 2315 TxHeader c Expires: Mon, 21 Jul 2008 14:49:42 GMT > 2315 TxHeader c Content-Type: text/html > 2315 TxHeader c Content-Length: 158261 > 2315 TxHeader c X-VG-WebCache: maddie > 2315 TxHeader c Date: Mon, 21 Jul 2008 14:03:24 GMT > 2315 TxHeader c X-Varnish: 512297753 510694686 > 2315 TxHeader c Age: 822 > 2315 TxHeader c Via: 1.1 varnish > 2315 TxHeader c Connection: close > 2315 ReqEnd c 512297753 1216649004.307805061 1216649004.308098078 > 0.00003 > 0994 0.000028849 0.000264168 > > The non working > > 38070 SessionOpen c 127.0.0.1 56364 :80 > 38070 ReqStart c 127.0.0.1 56364 3818273786 > 38070 RxRequest c GET > 38070 RxURL c /sport/fotball/ > 38070 RxProtocol c HTTP/1.0 > 38070 RxHeader c Host:www.vg.no > 38070 VCL_call c recv lookup > 38070 VCL_call c hash hash > > Then nothing happens. No miss no hit > > Purge working version (hit) > > 3461 RxRequest c PURGE > 3461 RxURL c /sport/fotball/ > 3461 RxProtocol c HTTP/1.0 > 3461 RxHeader c Host:www.vg.no > 3461 VCL_call c recv > 3461 VCL_acl c MATCH purge "localhost" > 3461 VCL_return c lookup > 3461 VCL_call c hash hash > 3461 Hit c 510694686 > 3461 VCL_call c hit > 3461 TTL c 510694686 VCL 0 1216649372 > 3461 VCL_return c error > 3461 SessionClose c error returned > 3461 TxProtocol c HTTP/1.0 > 3461 TxStatus c 200 > 3461 TxResponse c OK > 3461 TxHeader c Date: Mon, 21 Jul 2008 14:09:32 GMT > 3461 TxHeader c Server: Varnish > 3461 TxHeader c Retry-After: 0 > 3461 TxHeader c Content-Type: text/html; charset=utf-8 > 3461 TxHeader c X-Varnish: 513000671 > 3461 TxHeader c Connection: close > 3461 ReqEnd c 513000671 1216649372.271184921 1216649372.271277905 > 0.00005 > 1975 nan nan > > Pruge Working version (miss) > 5750 RxRequest c PURGE > 5750 RxURL c /sport/fotball/ > 5750 RxProtocol c HTTP/1.0 > 5750 RxHeader c Host:www.vg.no > 5750 VCL_call c recv > 5750 VCL_acl c MATCH purge "localhost" > 5750 VCL_return c lookup > 5750 VCL_call c hash hash > 5750 VCL_call c miss error > 5750 SessionClose c error returned > 5750 TxProtocol c HTTP/1.0 > 5750 TxStatus c 404 > 5750 TxResponse c Not Found > 5750 TxHeader c Date: Mon, 21 Jul 2008 14:10:49 GMT > 5750 TxHeader c Server: Varnish > 5750 TxHeader c Retry-After: 0 > 5750 TxHeader c Content-Type: text/html; charset=utf-8 > 5750 TxHeader c X-Varnish: 513145422 > 5750 TxHeader c Connection: close > 5750 ReqEnd c 513145422 1216649449.873359919 1216649449.873445988 > 0.00004 > 6968 nan nan > > > Purge non working version: > > 36848 RxRequest c PURGE > 36848 RxURL c /sport/fotball/ > 36848 RxProtocol c HTTP/1.0 > 36848 RxHeader c Host:www.vg.no > 36848 VCL_call c recv > 36848 VCL_acl c MATCH purge "localhost" > 36848 VCL_return c lookup > 36848 VCL_call c hash hash > > varnish-2.0-trunk2914 on redhat 5.2 New description: Sometime varnish won't handle a specific URL. After a restart. Everything is back to normal. This happens quite often, and usually with with a specific URL. {{{ This works: (talking to backend) [root at fritz ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 HTTP/1.1 200 OK This works: (talking to backend) [root at fritz ~]# echo -e "GET /sport/fotball HTTP/1.0\nHost:www.vg.no\n\n" | nc 10.0.0.151 80 |head -1 HTTP/1.1 301 Moved Permanently This works: (talking to varnish on localhost) [root at fritz ~]# echo -e "GET /sport/fotball HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 HTTP/1.1 301 Moved Permanently This does not work at the moment on one of the varnishes: [root at fritz ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 It just hangs forever. ( waited up to 10 minutes ) Running on another varnish it works [root at maddie ~]# echo -e "GET /sport/fotball/ HTTP/1.0\nHost:www.vg.no\n\n" | nc localhost 80 |head -1 HTTP/1.1 200 OK Same varnish, same vcl Varnishlog on the working varnish 2315 ReqStart c 127.0.0.1 51162 512297753 2315 RxRequest c GET 2315 RxURL c /sport/fotball/ 2315 RxProtocol c HTTP/1.0 2315 RxHeader c Host:www.vg.no 2315 VCL_call c recv lookup 2315 VCL_call c hash hash 2315 Hit c 510694686 2315 VCL_call c hit deliver 2315 Length c 158261 2315 VCL_call c deliver deliver 2315 TxProtocol c HTTP/1.1 2315 TxStatus c 200 2315 TxResponse c OK 2315 TxHeader c Server: Apache/1.3.27 (Unix) 2315 TxHeader c X-VG-WebServer: leonora, leonora 2315 TxHeader c Cache-Control: max-age=3600 2315 TxHeader c Expires: Mon, 21 Jul 2008 14:49:42 GMT 2315 TxHeader c Content-Type: text/html 2315 TxHeader c Content-Length: 158261 2315 TxHeader c X-VG-WebCache: maddie 2315 TxHeader c Date: Mon, 21 Jul 2008 14:03:24 GMT 2315 TxHeader c X-Varnish: 512297753 510694686 2315 TxHeader c Age: 822 2315 TxHeader c Via: 1.1 varnish 2315 TxHeader c Connection: close 2315 ReqEnd c 512297753 1216649004.307805061 1216649004.308098078 0.00003 0994 0.000028849 0.000264168 The non working 38070 SessionOpen c 127.0.0.1 56364 :80 38070 ReqStart c 127.0.0.1 56364 3818273786 38070 RxRequest c GET 38070 RxURL c /sport/fotball/ 38070 RxProtocol c HTTP/1.0 38070 RxHeader c Host:www.vg.no 38070 VCL_call c recv lookup 38070 VCL_call c hash hash Then nothing happens. No miss no hit Purge working version (hit) 3461 RxRequest c PURGE 3461 RxURL c /sport/fotball/ 3461 RxProtocol c HTTP/1.0 3461 RxHeader c Host:www.vg.no 3461 VCL_call c recv 3461 VCL_acl c MATCH purge "localhost" 3461 VCL_return c lookup 3461 VCL_call c hash hash 3461 Hit c 510694686 3461 VCL_call c hit 3461 TTL c 510694686 VCL 0 1216649372 3461 VCL_return c error 3461 SessionClose c error returned 3461 TxProtocol c HTTP/1.0 3461 TxStatus c 200 3461 TxResponse c OK 3461 TxHeader c Date: Mon, 21 Jul 2008 14:09:32 GMT 3461 TxHeader c Server: Varnish 3461 TxHeader c Retry-After: 0 3461 TxHeader c Content-Type: text/html; charset=utf-8 3461 TxHeader c X-Varnish: 513000671 3461 TxHeader c Connection: close 3461 ReqEnd c 513000671 1216649372.271184921 1216649372.271277905 0.00005 1975 nan nan Pruge Working version (miss) 5750 RxRequest c PURGE 5750 RxURL c /sport/fotball/ 5750 RxProtocol c HTTP/1.0 5750 RxHeader c Host:www.vg.no 5750 VCL_call c recv 5750 VCL_acl c MATCH purge "localhost" 5750 VCL_return c lookup 5750 VCL_call c hash hash 5750 VCL_call c miss error 5750 SessionClose c error returned 5750 TxProtocol c HTTP/1.0 5750 TxStatus c 404 5750 TxResponse c Not Found 5750 TxHeader c Date: Mon, 21 Jul 2008 14:10:49 GMT 5750 TxHeader c Server: Varnish 5750 TxHeader c Retry-After: 0 5750 TxHeader c Content-Type: text/html; charset=utf-8 5750 TxHeader c X-Varnish: 513145422 5750 TxHeader c Connection: close 5750 ReqEnd c 513145422 1216649449.873359919 1216649449.873445988 0.00004 6968 nan nan Purge non working version: 36848 RxRequest c PURGE 36848 RxURL c /sport/fotball/ 36848 RxProtocol c HTTP/1.0 36848 RxHeader c Host:www.vg.no 36848 VCL_call c recv 36848 VCL_acl c MATCH purge "localhost" 36848 VCL_return c lookup 36848 VCL_call c hash hash varnish-2.0-trunk2914 on redhat 5.2 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 21 20:17:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Jul 2008 20:17:05 -0000 Subject: [Varnish] #278: Backend connection does not timeout In-Reply-To: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> References: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> Message-ID: <057.ff5e3fb5709d05a91fe7e5c12664f8e2@projects.linpro.no> #278: Backend connection does not timeout ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: PURGE | ----------------------+----------------------------------------------------- Changes (by phk): * summary: Varnish at some point can't handle a spesific URL => Backend connection does not timeout Comment: It seems pretty obvious that the request gets parked because the object is busy due to another client trying to fetch from the backend. Based on the above I cannot tell if that object is legitimately busy (ie: a transfer from the backend is stalled) or if there has been a mistake in the recordkeeping that has failed to un-busy the object. On pure probability the former is more likely than the latter because we are not working hard to time out backend connections which don't make any progress at present. Summary: I doubt it is a bug, it's far more likely a missing feature so I have changed the summary of this ticket accordingly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 07:52:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 07:52:23 -0000 Subject: [Varnish] #264: server.port VCL variable In-Reply-To: <050.5d9930495dd68b333b50efa6dc82d62a@projects.linpro.no> References: <050.5d9930495dd68b333b50efa6dc82d62a@projects.linpro.no> Message-ID: <059.244d77e3c9ae61fbe632ef507d8a69f7@projects.linpro.no> #264: server.port VCL variable -------------------------+-------------------------------------------------- Reporter: adam | Owner: petter Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: vcl | -------------------------+-------------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed Comment: Fixed in r2983. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 09:42:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 09:42:31 -0000 Subject: [Varnish] #244: Option to set the page size In-Reply-To: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> References: <052.f900a16ab635a784fad9de9dea3e354e@projects.linpro.no> Message-ID: <061.3a0936f997710770a0998fdaa97d7071@projects.linpro.no> #244: Option to set the page size -------------------------+-------------------------------------------------- Reporter: anders | Owner: petter Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed Comment: Fixed in r2988. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 11:16:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 11:16:44 -0000 Subject: [Varnish] #104: varnishncsa assertion fails sometimes In-Reply-To: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> References: <055.b2f86f700ad9117f39ea76f3dd2e454e@projects.linpro.no> Message-ID: <064.c175d60223980863308b478dbeab1ef6@projects.linpro.no> #104: varnishncsa assertion fails sometimes -------------------------+-------------------------------------------------- Reporter: dirkgomez | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 1.0.3 Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by petter): * status: assigned => closed * resolution: => worksforme Comment: Did not manage to reproduce any memory leaks or any crashes. Anders hasn't experienced any crashes since may, so closing the ticket under the assumption that it has been magically fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 12:01:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 12:01:04 -0000 Subject: [Varnish] #145: Issues whild loading VCL code on the fly In-Reply-To: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> References: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> Message-ID: <061.702d669e45205fe93fc59f452ae68525@projects.linpro.no> #145: Issues whild loading VCL code on the fly -------------------------------+-------------------------------------------- Reporter: anders | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1 Severity: normal | Resolution: Keywords: varnishd load VCL | -------------------------------+-------------------------------------------- Changes (by petter): * owner: des => petter * status: assigned => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 12:01:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 12:01:14 -0000 Subject: [Varnish] #135: default.vcl out of sync In-Reply-To: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> References: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> Message-ID: <061.b3875106d0ca5305d0f7a22d38339da3@projects.linpro.no> #135: default.vcl out of sync ---------------------------+------------------------------------------------ Reporter: anders | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: 1.1 Severity: normal | Resolution: Keywords: default.vcl | ---------------------------+------------------------------------------------ Changes (by petter): * owner: des => petter * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 12:02:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 12:02:17 -0000 Subject: [Varnish] #190: VCL Sample In-Reply-To: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> References: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> Message-ID: <066.d09f4c1cfbe7344e7f2fdbee35f2abd2@projects.linpro.no> #190: VCL Sample ---------------------------+------------------------------------------------ Reporter: michael.lee | Owner: petter Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: 1.1.1 Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by petter): * owner: des => petter -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 13:32:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 13:32:31 -0000 Subject: [Varnish] #279: varnishlog init file does not work Message-ID: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> #279: varnishlog init file does not work ------------------------+--------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- The varnishlog init file does not work on RHEL4.6 (and possibly other versions as well, I haven't had a chance to check as yet, though I will later today). The failures are due to syntax errors in a number of the functions included from /etc/init.d/functions. The attached patch will fix the errors (as well as a single spelling mistake). It simply changes the syntax to be the same as that used in /etc/init.d/varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 14:20:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 14:20:36 -0000 Subject: [Varnish] #280: VCL fault with restart logic if backend returns 403 Message-ID: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> #280: VCL fault with restart logic if backend returns 403 ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Issue description: With restart logic enabled, "403: Forbidden" responses are not handled correctly. It appears that they loop forever (sending requests to the backend, or backends), until they cause this fault: {{{ Child (25712) died signal=6 Child (25712) Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 558: Condition((p) != 0) not true. thread = (cache-worker)sp = 0x857546c { fd = 9, id = 9, xid = 1541762087, client = 127.0.0.1:35186, step = STP_LOOKUP, err_code = 403, err_reason = (null), ws = 0x85754b4 { overflow id = "sess", {s,f,r,e} = {0x8575934,,+8168,(nil),+8192}, }, worker = 0x6f2970e0 { }, vcl = { srcname = { "/etc/varnish/restarts.vcl", "Default", }, }, backend = 0x855fc98 { vcl_name = "tea", }, }, Child cleanup complete }}} Steps to reproduce: This issue is consistently reproducible. * Configure varnish with a backend that includes forbidden URLs. * Add logic to vcl_fetch that will cause a restart if the returned object has a response code other than 200 * Request the forbidden URL via varnish (eg, with wget) Workaround: There is a simple workaround to this issue. Instead of enabling restart logic with this: {{{ sub vcl_fetch { if (obj.status != 200) { restart; } } }}} use this: {{{ sub vcl_fetch { if (obj.status != 200 && obj.status != 403) { restart; } } }}} Attached VCL file is broken, and includes the workaround commented out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 14:34:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 14:34:14 -0000 Subject: [Varnish] #280: VCL fault with restart logic if backend returns 403 In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.bfef478a3e2ebfad2623a3bea01e1f7b@projects.linpro.no> #280: VCL fault with restart logic if backend returns 403 ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by marlier): Further experimentation shows that the exact same behavior occurs if the backend returns a "404" error code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 22 14:44:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Jul 2008 14:44:31 -0000 Subject: [Varnish] #280: VCL fault with restart logic if backend returns 403 In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.116e035f9bbb2b5e7d8223a8b6af5ae5@projects.linpro.no> #280: VCL fault with restart logic if backend returns 403 ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I think what is happening here is that you go into a loop of restarts and eventually run out of workspace in the session. Please verify this is the case in your varnishlog output. There is no point in doing a restart, if your next pass through encounters the exact same error. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 07:49:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 07:49:00 -0000 Subject: [Varnish] #281: Possible to load two configurations with the same name when stopped Message-ID: <052.7bbdf055b42d86969f247cd727a07102@projects.linpro.no> #281: Possible to load two configurations with the same name when stopped ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- It is possible to load two configurations with the same name when stopped, leading to a crash when started again: {{{ Connected to localhost. Escape character is '^]'. stop 200 0 vcl.load run1 /tmp/simple.vcl 200 13 VCL compiled. vcl.load run1 /tmp/simple.vcl 200 13 VCL compiled. vcl.list 200 69 active N/A boot available N/A run1 available N/A run1 start Connection closed by foreign host. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 09:08:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 09:08:05 -0000 Subject: [Varnish] #135: default.vcl out of sync In-Reply-To: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> References: <052.c196e75db5c13b3f37ec0b3a55dd4ad7@projects.linpro.no> Message-ID: <061.041aca9f7ccd3564844f4aaee43611ac@projects.linpro.no> #135: default.vcl out of sync ---------------------------+------------------------------------------------ Reporter: anders | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 1.1 Severity: normal | Resolution: fixed Keywords: default.vcl | ---------------------------+------------------------------------------------ Changes (by petter): * status: new => closed * resolution: => fixed Comment: Fixed in r2994. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 11:35:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 11:35:16 -0000 Subject: [Varnish] #145: Issues whild loading VCL code on the fly In-Reply-To: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> References: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> Message-ID: <061.6de8ab66681deb46ff0315cbb38d4c2d@projects.linpro.no> #145: Issues whild loading VCL code on the fly -------------------------------+-------------------------------------------- Reporter: anders | Owner: petter Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1 Severity: normal | Resolution: Keywords: varnishd load VCL | -------------------------------+-------------------------------------------- Comment (by anders): I've loaded 468 configs in a loop now, no problems. The issue seems to have been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 11:41:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 11:41:35 -0000 Subject: [Varnish] #145: Issues whild loading VCL code on the fly In-Reply-To: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> References: <052.cbf0da58c87c745a45933c736d50eec2@projects.linpro.no> Message-ID: <061.ac92063077c02ec675d2b690921f9061@projects.linpro.no> #145: Issues whild loading VCL code on the fly -------------------------------+-------------------------------------------- Reporter: anders | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1 Severity: normal | Resolution: fixed Keywords: varnishd load VCL | -------------------------------+-------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 16:34:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 16:34:35 -0000 Subject: [Varnish] #218: ACL matching needs IPv6 support In-Reply-To: <052.5c90c1ec7e1b5eef0e43290b275cf225@projects.linpro.no> References: <052.5c90c1ec7e1b5eef0e43290b275cf225@projects.linpro.no> Message-ID: <061.16d72b938ed7f1c140219c28ea637b4a@projects.linpro.no> #218: ACL matching needs IPv6 support -------------------------+-------------------------------------------------- Reporter: hucker | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: fixed Keywords: ipv6 acl | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Done. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 23 21:04:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Jul 2008 21:04:30 -0000 Subject: [Varnish] #281: Possible to load two configurations with the same name when stopped In-Reply-To: <052.7bbdf055b42d86969f247cd727a07102@projects.linpro.no> References: <052.7bbdf055b42d86969f247cd727a07102@projects.linpro.no> Message-ID: <061.59d0bba133148fed863270dab29ec638@projects.linpro.no> #281: Possible to load two configurations with the same name when stopped ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in 3006 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 11:41:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 11:41:42 -0000 Subject: [Varnish] #74: varnish doesn't clean /tmp/files during runtime. In-Reply-To: <052.4da4f6dd9ba900b71b218fa1d01145a2@projects.linpro.no> References: <052.4da4f6dd9ba900b71b218fa1d01145a2@projects.linpro.no> Message-ID: <061.579d758a4ba3f59ce635b11e87b47338@projects.linpro.no> #74: varnish doesn't clean /tmp/files during runtime. --------------------+------------------------------------------------------- Reporter: bahner | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by petter): * status: new => closed * resolution: => fixed Comment: Fixed by ssm. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 13:14:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 13:14:33 -0000 Subject: [Varnish] #237: Varnish crashes on assert error in http_dissect_hdrs(), cache_http.c line 375 In-Reply-To: <052.b912108d70e8121ab174125f63fe3742@projects.linpro.no> References: <052.b912108d70e8121ab174125f63fe3742@projects.linpro.no> Message-ID: <061.c9db19be1d6b37aa7d7600d0753f5e34@projects.linpro.no> #237: Varnish crashes on assert error in http_dissect_hdrs(), cache_http.c line 375 --------------------------------------------------+------------------------- Reporter: anders | Owner: petter Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: varnishd core dump http_dissect_hdrs | --------------------------------------------------+------------------------- Changes (by petter): * owner: phk => petter * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 13:20:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 13:20:08 -0000 Subject: [Varnish] #207: Varnishlog core dumps In-Reply-To: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> References: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> Message-ID: <061.3dec160ffecd45247a19d2e31a7c37cf@projects.linpro.no> #207: Varnishlog core dumps -----------------------------------+---------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: varnish log core dump | -----------------------------------+---------------------------------------- Changes (by petter): * status: closed => reopened * resolution: fixed => Comment: This is a varnishlog issue, not a varnishd issue - kqueue/session race is not relevant to varnishlog. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 13:21:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 13:21:12 -0000 Subject: [Varnish] #164: Varnishd core dumps because of segmentation violation In-Reply-To: <052.056d420b6ae1f4a78c1b835427e4222f@projects.linpro.no> References: <052.056d420b6ae1f4a78c1b835427e4222f@projects.linpro.no> Message-ID: <061.954e427954f5f64156e4d26b3f65a2b2@projects.linpro.no> #164: Varnishd core dumps because of segmentation violation --------------------------------+------------------------------------------- Reporter: anders | Owner: des Type: defect | Status: closed Priority: high | Milestone: Varnish 1.2 Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: varnishd core dump | --------------------------------+------------------------------------------- Comment (by petter): Superseded by #237 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 13:25:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 13:25:14 -0000 Subject: [Varnish] #237: Varnish crashes on assert error in http_dissect_hdrs(), cache_http.c line 375 In-Reply-To: <052.b912108d70e8121ab174125f63fe3742@projects.linpro.no> References: <052.b912108d70e8121ab174125f63fe3742@projects.linpro.no> Message-ID: <061.d260aca3600529496f64f0bc28ec432d@projects.linpro.no> #237: Varnish crashes on assert error in http_dissect_hdrs(), cache_http.c line 375 --------------------------------------------------+------------------------- Reporter: anders | Owner: petter Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishd core dump http_dissect_hdrs | --------------------------------------------------+------------------------- Changes (by petter): * status: assigned => closed * resolution: => fixed Comment: Fixed in r2633. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 18:54:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 18:54:38 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect Message-ID: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- See on recent trunk: {{{ 18 SessionOpen c 10.121.10.84 37279 0.0.0.0:80 18 ReqStart c 10.121.10.84 37279 437513765 18 RxRequest c GET 18 RxURL c /image-bank/TV.jpg/edit 18 RxProtocol c HTTP/1.1 18 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1 18 RxHeader c Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 18 RxHeader c Accept-Language: en-us 18 RxHeader c Accept-Encoding: gzip, deflate 18 RxHeader c Cookie: __ac="xxxxxx"; statusmessages="A+RXZWxjb21lISBZb3UgYXJlIG5vdyBsb2dnZWQgaW4uaW5mbw==" 18 RxHeader c Connection: keep-alive 18 RxHeader c Host: wrk-varn01.elkjop.int 18 VCL_call c recv 18 VCL_return c lookup 18 VCL_call c hash 18 VCL_return c hash 18 Hit c 437513731 18 VCL_call c hit 18 VCL_return c deliver 18 Length c 2522 18 VCL_call c deliver 18 VCL_return c deliver 18 TxProtocol c HTTP/1.1 18 TxStatus c 302 18 TxResponse c Moved Temporarily 18 TxHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.3, linux2) ZServer/1.1 Plone/3.0.6 18 TxHeader c Bobo-Exception-Line: 195 18 TxHeader c Bobo-Exception-Value: See the server error log for details 18 TxHeader c Content-Language: en-us 18 TxHeader c Content-Encoding: gzip 18 TxHeader c Bobo-Exception-File: Traversable.py 18 TxHeader c Bobo-Exception-Type: Unauthorized 18 TxHeader c Expires: Sat, 1 Jan 2000 00:00:00 GMT 18 TxHeader c Vary: Accept-Encoding 18 TxHeader c X-Ksscommands: system Unauthorized: You are not allowed to a 18 TxHeader c Content-Type: text/html;charset=utf-8 18 TxHeader c Location: http://wrk- varn01.elkjop.int/acl_users/credentials_cookie_auth/require_login?came_from=http%3A //wrk-varn01.elkjop.int/image-bank/TV.jpg/atct_edit 18 TxHeader c Content-Length: 2522 18 TxHeader c Date: Thu, 24 Jul 2008 18:43:36 GMT 18 TxHeader c X-Varnish: 437513765 437513731 18 TxHeader c Age: 102 18 TxHeader c Via: 1.1 varnish 18 TxHeader c Connection: keep-alive 18 ReqEnd c 437513765 1216925016.633212090 1216925016.633437634 0.008165836 0.000131130 0.000094414 0 StatAddr - 10.121.10.84 0 287288 5562 11937 0 0 1782 3339199 30718664 18 SessionClose c no request }}} Caching a response with a 302 response code sounds like a bad strategy. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 19:47:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 19:47:16 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.ad297ad5aa400828b5a203d0a835e286@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): If no caching instructions are provided by the backend, Varnish will generally use the default TTL as cache period, under the general assumption that it is there to offload the backend. In this case, the Expires header must have come from the backend, but since you have not provided the log for the xid that put this into the cache, I can't diagnose it any closer. Ticket 277 may be relevant. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 22:13:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 22:13:30 -0000 Subject: [Varnish] #277: rfc2616.c marks expired content as acachable In-Reply-To: <054.30150cc1435b6fc108d1531e06bfac89@projects.linpro.no> References: <054.30150cc1435b6fc108d1531e06bfac89@projects.linpro.no> Message-ID: <063.7584658f23ece26d74a05645c846c640@projects.linpro.no> #277: rfc2616.c marks expired content as acachable -----------------------------+---------------------------------------------- Reporter: richardc | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: caching rfc2616 | -----------------------------+---------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I've gone over the TTL calculation in changeset 3019, hopefully solving this issue. If not, feel free to reopen this ticket with new info. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 22:26:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 22:26:35 -0000 Subject: [Varnish] #236: Past-date Expires is not handled correctly In-Reply-To: <053.c78f5a31201fd3e4e808ade9133318c7@projects.linpro.no> References: <053.c78f5a31201fd3e4e808ade9133318c7@projects.linpro.no> Message-ID: <062.ea9d553d3fcf3d4113dcb843bcaf0bfc@projects.linpro.no> #236: Past-date Expires is not handled correctly ---------------------+------------------------------------------------------ Reporter: newbery | Owner: des 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 should be fixed in changeset 3019. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 22:36:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 22:36:00 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.28ce0792269026bcf8d484a25a346210@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): I probably have that log data. How can I find which XID put that entry into the cache? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 24 22:53:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 24 Jul 2008 22:53:21 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.902612e4cd211ec726b5ff73f5f868f5@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): That is the second XID in the X-Varnish header. Please also take a shot with #3019 or later, I've changed the TTL calculation to detect Expires: headers in the past, and that will probably solve your case as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:15:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:15:59 -0000 Subject: [Varnish] #207: Varnishlog core dumps In-Reply-To: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> References: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no> Message-ID: <061.bb5dfd12626522e3eed2793cb2a916d6@projects.linpro.no> #207: Varnishlog core dumps -----------------------------------+---------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: varnish log core dump | -----------------------------------+---------------------------------------- Changes (by petter): * status: reopened => closed * resolution: => fixed Comment: Did not manage to reproduce the error. Anders hasn't experienced any errors now, so closing the ticket under the assumption that it has been magically fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:17:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:17:53 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb Message-ID: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- We're running varnishlog on production servers running varnish trunk to collect data in case we see a varnishd problem. We see varnishlog aborting regularly and failing to restart with a ''File too large'' error. The manpage does not mention a size limit, so this was unexpected. The current filesize is 2147483647 bytes, ie 2.1Gb. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:23:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:23:16 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.40a2f0803d5b4ea0673c85abeb75d22d@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: invalid Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This is an error message from your operating system. Either your filsystem type does not support large files, or your resource limitations prevents you from making large files. Check the output of ulimit or limits command. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:29:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:29:30 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.9aa196050c6bbaad07351af79c658c55@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): Unfortunately due to #283 I do not have that log information. I'll check the caching headers generated by the backend by hand. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:42:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:42:00 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.33007a82e0a3b0a9008f142d9c24a303@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: invalid Keywords: | ------------------------+--------------------------------------------------- Comment (by wichert): OS limits seem fine: {{{ [root at wrk-varn01 proxy]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 27776 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 27776 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited }}} The filesystem (ext3) also supports larger files. As a test I made a copy of varnish.log and added it to itself, which worked fine: {{{ [root at wrk-varn01 log]# cp -a varnish.log /tmp [root at wrk-varn01 log]# cat varnish.log >> /tmp/varnish.log [root at wrk-varn01 log]# du -hs /tmp/varnish.log 4.1G /tmp/varnish.log }}} .. more poking around .. strace indeed shows write(2) failing: {{{ write(4, "\7\0\34\0\03010.7.50.183 59122 0.0.0.0:8"..., 34) = -1 EFBIG (File too large) --- SIGXFSZ (File size limit exceeded) @ 0 (0) --- +++ killed by SIGXFSZ +++ }}} I wonder why cat succeeds where varnishlog fails. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:48:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:48:16 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.f28b57f6dd82afce8fd1c17d1ca53715@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by wichert): * status: closed => reopened * resolution: invalid => Comment: This is a varnishlog problem: it needs to compiled with LFS support to be able to deal with files >2^31 bits. http://www.suse.de/~aj/linux_lfs.html has some useful information. If I remember correctly there are standard macros for autoconf to test for LFS support. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:51:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:51:38 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.c4430a500b6140c5d54eee2d42341f40@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * owner: phk => * status: reopened => new Comment: I am not going to say what I think about an operating system where files larger than 2GB is an option :-) Somebody with autocrap clue will need to take this one. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 10:59:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 10:59:58 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.5f749d2c47759f41978e695342f45fe5@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by wichert): It's an artefact of an old kernel ABI which only had 32-bit syscalls. When the kernel was fixed to use 64 bits where needed a new set of 64-bit syscalls was added. For safety reasons Linux still restricts the maximum filesize if an application does not indicate it can use those in order to prevent things like apps creating a file which they can't stat(2) themselves. I agree it's all a bit (ahum) painful though. I'll see if I can cobble up a patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 11:23:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 11:23:19 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.a11448a6d28b827a069bbce43fb49d2f@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by wichert): I've attached a preliminary patch. It looks correct and compiles at least. I'll test this on a running server to see if it behaves properly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 11:38:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 11:38:43 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.d7c792bce40ee6d6aaf0b3aa78257422@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by wichert): The patch appears to work fine: varnishlog is happily appending to my logfile now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From renatas.ulevicius at etalink.lt Fri Jul 25 11:45:09 2008 From: renatas.ulevicius at etalink.lt (=?windows-1257?Q?Renatas_Ulevi=E8ius?=) Date: Fri, 25 Jul 2008 14:45:09 +0300 Subject: varnish not reponds after one of backends death Message-ID: <00f601c8ee4b$e3f98e80$5a00a8c0@zvilgsnis.lt> vcl is attached. IF I corectly understand all threads are waiting from dead hosts reponse and there is no free threads. I not able to find thread timeout value parameter backend php5 { set backend.host = "192.168.0.5"; set backend.port = "80"; } backend php4 { set backend.host= "192.168.0.10"; set backend.port = "80"; } sub vcl_recv { if (req.http.host ~ "^((www.)?xxxxxxxxxxx.com)$") { set req.backend = php4; } else{ set req.backend=php5; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Fri Jul 25 12:02:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 12:02:16 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.18a357289fd812cf1f6a569eb196f310@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): r3019 should indeed help. The reponse Plone sends when you try to access an object for which you are not authorised look like this: {{{ HTTP/1.x 302 Moved Temporarily Server: Zope/(Zope 2.10.6-final, python 2.4.4, darwin) ZServer/1.1 Plone/3.0.6 Date: Fri, 25 Jul 2008 11:58:40 GMT Bobo-Exception-Line: 808 Content-Length: 2417 Bobo-Exception-Value: See the server error log for details Content-Language: en-us Content-Encoding: gzip Bobo-Exception-File: ImplPython.py Bobo-Exception-Type: Unauthorized Expires: Sat, 1 Jan 2000 00:00:00 GMT Vary: Accept-Encoding X-Ksscommands: system Content-Type: text/html;charset=utf-8 Location: http://localhost:8080/plone/acl_users/credentials_cookie_auth/require_login?came_from=http%3A//localhost%3A8080/plone/frontpage_view }}} We should probably add an explicit ''Cache-Control: no-cache'' header to that response as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 12:02:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 12:02:50 -0000 Subject: [Varnish] #283: varnishlog stops working at 2gb In-Reply-To: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> References: <053.25fe6f5f36638fa8b18fd38f9678f4a6@projects.linpro.no> Message-ID: <062.5c152c2f1e71b714b029a6309b378acc@projects.linpro.no> #283: varnishlog stops working at 2gb ------------------------+--------------------------------------------------- Reporter: wichert | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I have committed a slightly modified version of your patch, reopen if that doesn't work. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 12:07:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 12:07:38 -0000 Subject: [Varnish] #282: varnish cashes a temporary redirect In-Reply-To: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> References: <053.c47110a14fd14840fe0529e30b6085fb@projects.linpro.no> Message-ID: <062.931c85df27032106d6ad1ed9840274a2@projects.linpro.no> #282: varnish cashes a temporary redirect ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I guess that means that I can close this ticket then. Thanks for the help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 14:00:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 14:00:01 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.43e2e0edc712aaecd3221698544e0949@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by chrisrixon): * status: closed => reopened * resolution: worksforme => Comment: Replying to [comment:2 des]: > What do you mean by "running out of virtual memory"? We need to know the symptoms, not your interpretation. Well I monitor it in top and the VIRT column for varnishd reaches just over 3000m at which point varnish stops responding to requests. Here's what top looks like with -s set to 128M (malloc or file seems to make little difference). Note how VIRT is 1964m and rising. {{{ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29526 admin 16 0 1964m 23m 8984 S 3.3 1.2 0:05.66 varnishd }}} > How big is your cache file? 128M We have now commissioned a 64 bit server and it works much better although VIRT (on top) can reach 20G ! Here's a stat for the 64 bit: {{{ 0+00:19:26 Hitrate ratio: 10 100 141 Hitrate avg: 0.9573 0.9603 0.9604 179615 271.73 154.04 Client connections accepted 341046 547.45 292.49 Client requests received 321617 517.48 275.83 Cache hits 1763 0.00 1.51 Cache hits for pass 15671 25.97 13.44 Cache misses 19427 29.97 16.66 Backend connections success 0 0.00 0.00 Backend connections failures 0 0.00 0.00 Backend connections reuses 0 0.00 0.00 Backend connections recycles 8 -3.00 0.01 Backend connections unused 6788 . . N struct srcaddr 2510 . . N active struct srcaddr 3306 . . N struct sess_mem 3226 . . N struct sess 10069 . . N struct object 10059 . . N struct objecthead 9222 . . N struct smf 1040 . . N small free smf 1 . . N large free smf 77 . . N struct vbe_conn 1892 . . N worker threads 1892 0.00 1.62 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 1892 0.00 1.62 N overflowed work requests 0 0.00 0.00 N dropped work requests 7440 . . N expired objects 392 . . N objects on deathrow 0 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile 291708 467.53 250.18 Objects sent with write 178540 260.74 153.12 Total Sessions 339195 539.46 290.90 Total Requests 591 0.00 0.51 Total pipe 0 0.00 0.00 Total pass 18692 28.97 16.03 Total fetch 111559849 180511.33 95677.40 Total header bytes 1514209533 2136196.92 1298635.96 Total body bytes 5947 12.99 5.10 Session Closed }}} We are puzzled as to why N worker threads slowly climbs to 2000 odd with 500 requests per second. Thanks. PS sorry for late reply, I dont seem to be getting notification emails.' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 19:22:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 19:22:06 -0000 Subject: [Varnish] #258: Add Hostname to Error Pages In-Reply-To: <054.18fe511275e5b9e1fc2c1eb7a73b6afd@projects.linpro.no> References: <054.18fe511275e5b9e1fc2c1eb7a73b6afd@projects.linpro.no> Message-ID: <063.f53a77ccb7a56051f89ffb9bc5f7b61b@projects.linpro.no> #258: Add Hostname to Error Pages -------------------------+-------------------------------------------------- Reporter: maxclark | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: As of r3027 the error page is constructed in the vcl_error{} function, so you can add the hostname and any other information now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jul 25 19:24:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Jul 2008 19:24:50 -0000 Subject: [Varnish] #35: Support for external error documents In-Reply-To: <049.f5a4682a77c16d18dc89350f88936431@projects.linpro.no> References: <049.f5a4682a77c16d18dc89350f88936431@projects.linpro.no> Message-ID: <058.151fe4c7d5daccb59db6594bc4f73431@projects.linpro.no> #35: Support for external error documents -------------------------+-------------------------------------------------- Reporter: des | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: This is now working as of r3027 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 27 10:51:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 27 Jul 2008 10:51:41 -0000 Subject: [Varnish] #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 Message-ID: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 ----------------------+----------------------------------------------------- Reporter: wg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Built from trunk r2999. Many errors logged as below. Can provide other messages if required, but they don't seem to provide any further information. I'm unable to reproduce, as I've only noticed the errors passively. Jul 27 08:52:15 soyuz varnishd[60663]: Child (41081) Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476: Condition((getsockname(sp->fd, sp->mysockaddr, &sp->mysockaddrlen)) == 0) not true. errno = 54 (Connection reset by peer) thread = (cache- worker)sp = 0x823a004 { fd = 21, id = 21, xid = 263428262, client = 65.55.110.26:62815, step = STP_RECV, ws = 0x823a04c { id = "sess", {s,f,r,e} = {0x823a4cc,,+371,0x0,+8192}, }, worker = 0xbeff4cf0 { }, vcl = { srcname = { "/usr/local/etc/varnish/soyuz+virtual.vcl", "Default", }, }, }, Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Child starts Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Closed fds: 4 5 6 7 13 14 16 17 Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Ready Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said managed to mmap 2147467264 bytes of 2147467264 Jul 27 08:52:15 soyuz varnishd[60663]: child (49962) Started -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jul 27 11:10:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 27 Jul 2008 11:10:20 -0000 Subject: [Varnish] #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 In-Reply-To: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> References: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> Message-ID: <057.58be15baf79a2283ba4d28790ede4e33@projects.linpro.no> #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 ----------------------+----------------------------------------------------- Reporter: wg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > Built from trunk r2999. Many errors logged as below. Can provide other > messages if required, but they don't seem to provide any further > information. I'm unable to reproduce, as I've only noticed the errors > passively. > > Jul 27 08:52:15 soyuz varnishd[60663]: Child (41081) Panic message: > Assert error in VRT_r_server_ip(), cache_vrt.c line 476: > Condition((getsockname(sp->fd, sp->mysockaddr, &sp->mysockaddrlen)) == 0) > not true. errno = 54 (Connection reset by peer) thread = (cache- > worker)sp = 0x823a004 { fd = 21, id = 21, xid = 263428262, client = > 65.55.110.26:62815, step = STP_RECV, ws = 0x823a04c { id = > "sess", {s,f,r,e} = {0x823a4cc,,+371,0x0,+8192}, }, worker = > 0xbeff4cf0 { }, vcl = { srcname = { > "/usr/local/etc/varnish/soyuz+virtual.vcl", "Default", }, > }, }, > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Child starts > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Closed fds: 4 5 > 6 7 13 14 16 17 > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Ready > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said managed to mmap > 2147467264 bytes of 2147467264 > Jul 27 08:52:15 soyuz varnishd[60663]: child (49962) Started New description: Built from trunk r2999. Many errors logged as below. Can provide other messages if required, but they don't seem to provide any further information. I'm unable to reproduce, as I've only noticed the errors passively. {{ Jul 27 08:52:15 soyuz varnishd[60663]: Child (41081) Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476: Condition((getsockname(sp->fd, sp->mysockaddr, &sp->mysockaddrlen)) == 0) not true. errno = 54 (Connection reset by peer) thread = (cache-worker) sp = 0x823a004 { fd = 21, id = 21, xid = 263428262, client = 65.55.110.26:62815, step = STP_RECV, ws = 0x823a04c { id = "sess", {s,f,r,e} = {0x823a4cc,,+371,0x0,+8192}, }, worker = 0xbeff4cf0 { }, vcl = { srcname = { "/usr/local/etc/varnish/soyuz+virtual.vcl", "Default", }, }, }, Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Child starts Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Closed fds: 4 5 6 7 13 14 16 17 Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Ready Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said managed to mmap 2147467264 bytes of 2147467264 Jul 27 08:52:15 soyuz varnishd[60663]: child (49962) Started }}} Comment (by phk): Appearantly the client closed the connection before we ever got to work on it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jul 28 12:08:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 28 Jul 2008 12:08:29 -0000 Subject: [Varnish] #260: varnishd pid file is created with too restrictive file mode In-Reply-To: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no> References: <050.9dc2432fcafe6f6ef0b3fe6f7c547b9b@projects.linpro.no> Message-ID: <059.b9c82a185944adcdb6a5f83ee1519dbd@projects.linpro.no> #260: varnishd pid file is created with too restrictive file mode ----------------------+----------------------------------------------------- Reporter: hans | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: assigned => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jul 29 09:20:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 29 Jul 2008 09:20:23 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.5f761c5840ba252176dad2ae82bb6e3e@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): We have upgraded to r3020 last week and this appears to have fixed filehandle leaking at first sight, see the new munin output. We'll keep monitoring this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jul 30 22:55:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 30 Jul 2008 22:55:46 -0000 Subject: [Varnish] #285: Child gets SIGSEGV when starting with default config Message-ID: <049.ef6f60ef1c19ca587b95032b6000e275@projects.linpro.no> #285: Child gets SIGSEGV when starting with default config ----------------------+----------------------------------------------------- Reporter: Tim | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Built from r3032, running on Gentoo Linux with a simple config: ./varnishd -F -b www.example.com -a :9999 If additional details are required, please let me know. Some gdb details I managed to get from child: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 15257] 0x0806c19a in VCL_Load (fn=0x80b2130 "./vcl.FANefPfn.o", name=0x80b2678 "boot", cli=0xbf8aefe8) at cache_vcl.c:166 166 vcl->conf->priv = vcl; (gdb) backPushing vcls failed: CLI communication error Child (15257) said Closed fds: 3 4 5 6 8 11 12 14 15 Child (15257) said Child starts Child (15257) said managed to mmap 2147479552 bytes of 2147479552 Child (15257) said Ready unlink ./vcl.FANefPfn.o #0 0x0806c19a in VCL_Load (fn=0x80b2130 "./vcl.FANefPfn.o", name=0x80b2678 "boot", cli=0xbf8aefe8) at cache_vcl.c:166 #1 0x0806c8cc in ccf_config_load (cli=0xbf8aefe8, av=0x80b20e8, priv=0x0) at cache_vcl.c:247 #2 0xb7f8b6dd in cli_dispatch (cli=0xbf8aefe8, clp=0x80b26f8, line=0x80aaf80 "vcl.load boot ./vcl.FANefPfn.o") at cli.c:133 #3 0x0805940b in cli_vlu (priv=0xbf8aefe8, p=0x80aaf80 "vcl.load boot ./vcl.FANefPfn.o") at cache_cli.c:109 #4 0xb7f8e67a in LineUpProcess (l=0x80b28e8) at vlu.c:92 #5 0x080597b8 in CLI_Run () at cache_cli.c:162 #6 0x08064f16 in child_main () at cache_main.c:129 #7 0x08078161 in start_child () at mgt_child.c:301 #8 0x08078f08 in mgt_run (dflag=0, T_arg=0x0) at mgt_child.c:535 #9 0x08086f80 in main (argc=0, argv=0xbf8af69c) at varnishd.c:612 (gdb) info locals vcl = (struct vcls *) 0x80b2908 __func__ = "VCL_Load" (gdb) print vcl $1 = (struct vcls *) 0x80b2908 (gdb) print vcl->conf $2 = (struct VCL_conf *) 0x30cecea0 (gdb) print vcl->conf->priv $3 = (void *) 0x0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 10:02:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 10:02:07 -0000 Subject: [Varnish] #285: Child gets SIGSEGV when starting with default config In-Reply-To: <049.ef6f60ef1c19ca587b95032b6000e275@projects.linpro.no> References: <049.ef6f60ef1c19ca587b95032b6000e275@projects.linpro.no> Message-ID: <058.204c385164c63e9569d74216a58eacaf@projects.linpro.no> #285: Child gets SIGSEGV when starting with default config ----------------------+----------------------------------------------------- Reporter: Tim | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Oversight on my part, fixed in 3039 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 10:07:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 10:07:04 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.2ec77eee4582f1a4fc805cb5544dfbbb@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Varnish 1.2 Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): Is this still varnish 1.1.2 or are you running a newer version now ? If it is 1.1.2, could you try running -trunk to see if that has the same thread buildup behaviour ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 10:08:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 10:08:16 -0000 Subject: [Varnish] #279: varnishlog init file does not work In-Reply-To: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> References: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> Message-ID: <062.2087ac3e75cce055bee5a8ecf5c71b98@projects.linpro.no> #279: varnishlog init file does not work -----------------------+---------------------------------------------------- Reporter: marlier | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Changes (by phk): * owner: phk => * component: varnishlog => packaging Comment: This one is not mine, I have no clue about startup on RHEL -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 10:20:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 10:20:23 -0000 Subject: [Varnish] #68: Uptime in varnishstat -1 In-Reply-To: <048.98a3a6782d6f223ad2295fea101b26ef@projects.linpro.no> References: <048.98a3a6782d6f223ad2295fea101b26ef@projects.linpro.no> Message-ID: <057.2431ce52fd854c153c401774c2da4d37@projects.linpro.no> #68: Uptime in varnishstat -1 -------------------------+-------------------------------------------------- Reporter: ay | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishstat | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: assigned => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 10:20:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 10:20:56 -0000 Subject: [Varnish] #68: Uptime in varnishstat -1 In-Reply-To: <048.98a3a6782d6f223ad2295fea101b26ef@projects.linpro.no> References: <048.98a3a6782d6f223ad2295fea101b26ef@projects.linpro.no> Message-ID: <057.125cbb940432a1ac610d7515d5cb847f@projects.linpro.no> #68: Uptime in varnishstat -1 -------------------------+-------------------------------------------------- Reporter: ay | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishstat | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Comment (by tfheen): Fixed in commit #3041 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 12:47:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 12:47:30 -0000 Subject: [Varnish] #280: Workspace overflows give confusing error messaqe In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.5bd66937523e172581dde49156023af4@projects.linpro.no> #280: Workspace overflows give confusing error messaqe ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * summary: VCL fault with restart logic if backend returns 403 => Workspace overflows give confusing error messaqe * milestone: => After 2.0 Old description: > Issue description: > With restart logic enabled, "403: Forbidden" responses are not handled > correctly. It appears that they loop forever (sending requests to the > backend, or backends), until they cause this fault: > > {{{ > Child (25712) died signal=6 > Child (25712) Panic message: Missing errorhandling code in cnt_lookup(), > cache_center.c line 558: > Condition((p) != 0) not true. thread = (cache-worker)sp = 0x857546c { > fd = 9, id = 9, xid = 1541762087, > client = 127.0.0.1:35186, > step = STP_LOOKUP, > err_code = 403, err_reason = (null), > ws = 0x85754b4 { overflow > id = "sess", > {s,f,r,e} = {0x8575934,,+8168,(nil),+8192}, > }, > worker = 0x6f2970e0 { > }, > vcl = { > srcname = { > "/etc/varnish/restarts.vcl", > "Default", > }, > }, > backend = 0x855fc98 { > vcl_name = "tea", > }, > }, > > Child cleanup complete > }}} > > Steps to reproduce: > This issue is consistently reproducible. > > * Configure varnish with a backend that includes forbidden URLs. > * Add logic to vcl_fetch that will cause a restart if the returned object > has a response code other than 200 > * Request the forbidden URL via varnish (eg, with wget) > > Workaround: > There is a simple workaround to this issue. Instead of enabling restart > logic with this: > {{{ > sub vcl_fetch { > if (obj.status != 200) { > restart; > } > } > }}} > > use this: > {{{ > sub vcl_fetch { > if (obj.status != 200 && obj.status != 403) { > restart; > } > } > }}} > > Attached VCL file is broken, and includes the workaround commented out. New description: Issue description: If a request overflows the workspace (such as if the configuration uses "restart" and it ends up in an endless loop), the child dies with a somewhat confusing error message such as: {{{ Child (25712) died signal=6 Child (25712) Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 558: Condition((p) != 0) not true. thread = (cache-worker)sp = 0x857546c { fd = 9, id = 9, xid = 1541762087, client = 127.0.0.1:35186, step = STP_LOOKUP, err_code = 403, err_reason = (null), ws = 0x85754b4 { overflow id = "sess", {s,f,r,e} = {0x8575934,,+8168,(nil),+8192}, }, worker = 0x6f2970e0 { }, vcl = { srcname = { "/etc/varnish/restarts.vcl", "Default", }, }, backend = 0x855fc98 { vcl_name = "tea", }, }, Child cleanup complete }}} We should try to detect what's happened and report a better error. Ideally, the child should not die. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 13:45:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 13:45:35 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.7d48361932c510a80ca2a7673ccded57@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Closing as this seems fixed; please do reopen the ticket if you see the problem again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jul 31 13:47:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 31 Jul 2008 13:47:46 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.5c483676624459c2f3c82710e6a3064e@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by tfheen): Can you please see if updating to a later version fixes this for you as it did for Wichert? If it's still a real bug, I would be happy to try to try to get it chased down, but if it's accidentially fixed, I'd rather not waste my time. :-) - tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator