From varnish-bugs at varnish-cache.org Thu Sep 1 07:58:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 07:58:00 -0000 Subject: [Varnish] #994: Assert error in http_GetHdr(), cache_http.c In-Reply-To: <044.f0d406a02a1c326238466e3afe45c0f3@varnish-cache.org> References: <044.f0d406a02a1c326238466e3afe45c0f3@varnish-cache.org> Message-ID: <053.d04c18ff5564c5923eb4f63334bd8310@varnish-cache.org> #994: Assert error in http_GetHdr(), cache_http.c ----------------------+----------------------------------------------------- Reporter: pmialon | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: blocker Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [0d079cc0576fa5bb9c84f34131c61ebb51dcc89c]) Reset the "built vary spec" (also) if we came back from the waiting list, otherwise it might turn into garbage. Fixes #994 Fixes #1001 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 07:58:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 07:58:00 -0000 Subject: [Varnish] #1001: Varnish 3.0.1 crashes in http_GetHdr In-Reply-To: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> References: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> Message-ID: <052.d5535c6aa65067a62f1075b5a80c5198@varnish-cache.org> #1001: Varnish 3.0.1 crashes in http_GetHdr ----------------------+----------------------------------------------------- Reporter: anders | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.1 Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [0d079cc0576fa5bb9c84f34131c61ebb51dcc89c]) Reset the "built vary spec" (also) if we came back from the waiting list, otherwise it might turn into garbage. Fixes #994 Fixes #1001 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 08:03:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 08:03:32 -0000 Subject: [Varnish] #998: Separation of Varnish and vmod builds In-Reply-To: <043.126822ebe98abf838ee4b489ec46bd96@varnish-cache.org> References: <043.126822ebe98abf838ee4b489ec46bd96@varnish-cache.org> Message-ID: <052.a4a0c1a86d904dabe74104e9ac30d56c@varnish-cache.org> #998: Separation of Varnish and vmod builds --------------------+------------------------------------------------------- Reporter: anders | Owner: tfheen Type: task | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Sorry, this ticket is not a bug report but a change request. I have moved it to the [wiki:Future_VMODS] wiki page, all subsequent discussion should happen there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 08:05:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 08:05:05 -0000 Subject: [Varnish] #940: ETag for gzip'd variant identical to ETag of ungzipped variant. In-Reply-To: <042.bc99dca97e165d223cfd474527b5eda1@varnish-cache.org> References: <042.bc99dca97e165d223cfd474527b5eda1@varnish-cache.org> Message-ID: <051.a94d79ec045a8ea934bf035a23eac04f@varnish-cache.org> #940: ETag for gzip'd variant identical to ETag of ungzipped variant. -------------------+-------------------------------------------------------- Reporter: david | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: critical Keywords: | -------------------+-------------------------------------------------------- Comment(by phk): We have not changed the code and I am very tempted to leave this as one of the things you have to do in VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 08:39:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 08:39:28 -0000 Subject: [Varnish] #992: s_bodybytes increased by storage-size not sent size In-Reply-To: <045.e0582ad2fc8e7c6f06ab198451604622@varnish-cache.org> References: <045.e0582ad2fc8e7c6f06ab198451604622@varnish-cache.org> Message-ID: <054.20906d762500520893e6ca64ca11bc51@varnish-cache.org> #992: s_bodybytes increased by storage-size not sent size ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [d600ab8745c72f08272250cdb86dd4254f3feacd]) Move acct_tmp to worker instead of session and report # gunziped bytes rather than storage size when we gunzip for delivery. Fixes #992 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 08:39:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 08:39:46 -0000 Subject: [Varnish] #1001: Varnish 3.0.1 crashes in http_GetHdr In-Reply-To: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> References: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> Message-ID: <052.603ffec6830737c324d5ad5c54d7bb4b@varnish-cache.org> #1001: Varnish 3.0.1 crashes in http_GetHdr ----------------------+----------------------------------------------------- Reporter: anders | Owner: Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: 3.0.1 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * status: closed => reopened * resolution: fixed => Comment: Fix does not fix this, at least not completely. I still get crashes: {{{ Sep 1 08:30:22 cache1 varnishd[9245]: Child (9495) Panic message: Assert error in http_GetHdr(), cache_http.c line 266: Condition(l == strlen(hdr + 1)) not true. thread = (cache-worker) ident = FreeBSD,8.1-RELEASE-p1,amd64,-smalloc,-smalloc,-hcritbit,kqueue }}} With gdb attached I get after a while: {{{ [New Thread 8075fe040 (LWP 102099)] [New Thread 8075fde80 (LWP 102100)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 806610a00 (LWP 100579)] 0x00000008008c9e7f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:273 273 case 2: return __builtin_frame_address(3); (gdb) bt #0 0x00000008008c9e7f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:273 #1 0x00000008008c9ebc in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:53 #2 0x000000000042d889 in pan_ic (func=0x455e50 "http_GetHdr", file=0x455850 "cache_http.c", line=266, cond=0x455960 "l == strlen(hdr + 1)", err=Variable "err" is not available. ) at cache_panic.c:283 #3 0x0000000000429b3c in http_GetHdr (hp=0x81b09d3e8, hdr=0x81ecaefda ".91.37.197", ptr=0x7ffffa1be4c8) at cache_http.c:266 #4 0x00000000004333df in VRY_Match (sp=0x81b09d008, vary=0x81ecaefd8 "80.91.37.197") at cache_vary.c:192 #5 0x000000000042634b in HSH_Lookup (sp=0x81b09d008, poh=0x7ffffa1be580) at cache_hash.c:358 #6 0x00000000004145c0 in cnt_lookup (sp=0x81b09d008) at cache_center.c:1090 #7 0x0000000000417aef in CNT_Session (sp=0x81b09d008) at steps.h:38 #8 0x0000000000430261 in wrk_do_cnt_sess (w=0x7ffffa1d1c80, priv=Variable "priv" is not available. ) at cache_pool.c:301 #9 0x000000000042f3fa in wrk_thread_real (qp=0x801213560, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:184 #10 0x0000000800e61511 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffa1d2000: Bad address. (gdb) frame 4 #4 0x00000000004333df in VRY_Match (sp=0x81b09d008, vary=0x81ecaefd8 "80.91.37.197") at cache_vary.c:192 192 i = http_GetHdr(sp->http, (const char*)(vary+2), &h); (gdb) print *hp No symbol "hp" in current context. (gdb) print *sp->http $1 = {magic = 1680389577, logtag = HTTP_Rx, ws = 0x81b09d080, hd = 0x81b09d410, hdf = 0x81b09d810 "", shd = 64, nhd = 12, status = 0, protover = 11 '\v', conds = 0 '\0'} (gdb) print *sp $2 = {magic = 741317722, fd = 1382, id = 1382, xid = 1286732790, restarts = 0, esi_level = 0, disable_esi = 0, hash_ignore_busy = 0 '\0', hash_always_miss = 0 '\0', wrk = 0x7ffffa1d1c80, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x81b09d2e8, mysockaddr = 0x81b09d368, mylsock = 0x801222520, addr = 0x81b09dcb8 "161.4.150.7", port = 0x81b09dcc8 "15176", client_identity = 0x0, doclose = 0x0, http = 0x81b09d3e8, http0 = 0x81b09d850, ws = {{magic = 905626964, overflow = 0, id = 0x4533b6 "sess", s = 0x81b09dcb8 "161.4.150.7", f = 0x81b09df38 "29", r = 0x81b0adcb8 "", e = 0x81b0adcb8 ""}}, ws_ses = 0x81b09dcd0 "GET", ws_req = 0x81b09df08 "Accept-Encoding: gzip", digest = "A?f\201Lw?-p\031/?hq*?\032\210l\202\213^?*Vp\217?xJqO", vary_b = 0x81b09df38 "29", vary_l = 0x0, vary_e = 0x81b0adcb8 "", htc = {{ magic = 1041886673, fd = 1382, maxbytes = 32768, maxhdr = 4096, ws = 0x81b09d080, rxbuf = {b = 0x81b09dcd0 "GET", e = 0x81b09df01 ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1314865981.1631174, t_req = 1314865981.1632659, t_resp = nan(0x8000000000000), t_end = 1314865981.1631174, exp = {ttl = -1, grace = 21600, keep = -1, age = 0, entered = 0}, step = STP_LOOKUP, cur_method = 0, handling = 3, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x801213978, vbc = 0x0, obj = 0x0, objcore = 0x0, vcl = 0x80130cf28, hash_objhead = 0x0, mem = 0x81b09d000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x4301a0 , priv = 0x81b09d008}, acct_tmp = { first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_ses = { first = 1314865981.1631174, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}} (gdb) }}} It does seem to run a little longer before crashing however? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 08:40:03 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 08:40:03 -0000 Subject: [Varnish] #1001: Varnish 3.0.1 crashes in http_GetHdr In-Reply-To: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> References: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> Message-ID: <052.b5ffa5dcbda147aa05984bba215044f7@varnish-cache.org> #1001: Varnish 3.0.1 crashes in http_GetHdr ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.1 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * status: reopened => new * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 10:28:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 10:28:13 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) Message-ID: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) ----------------------+----------------------------------------------------- Reporter: albertas | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- we're serving images through Varnish. Backend is lighttpd 1.4.28 and sometimes get 503 error. Maybe someone can explain why. Log file: 12 SessionOpen c [snip] 50872 :80 12 ReqStart c [snip] 50872 1580592381 12 RxRequest c GET 12 RxURL c /images/anns/plius/142/293/98/_477260_small.jpg?id=95?id=10 12 RxProtocol c HTTP/1.1 12 RxHeader c Host: [snip] 12 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1 12 RxHeader c Accept: image/png,image/*;q=0.8,*/*;q=0.5 12 RxHeader c Accept-Language: en-us,en;q=0.5 12 RxHeader c Accept-Encoding: gzip, deflate 12 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 12 RxHeader c Connection: keep-alive 12 RxHeader c Referer: [snip] 12 VCL_call c recv lookup 12 VCL_call c hash 12 Hash c /images/anns/plius/142/293/98/_477260_small.jpg?id=95?id=10 12 Hash c [snip] 12 VCL_return c hash 12 VCL_call c miss fetch 12 Backend c 14 [snip] [snip] 12 TTL c 1580592381 RFC 1.2096e+06 1314872203 0 0 1209600 0 12 VCL_call c fetch deliver 12 ObjProtocol c HTTP/1.1 12 ObjResponse c OK 12 ObjHeader c Expires: Thu, 15 Sep 2011 10:16:43 GMT 12 ObjHeader c Cache-Control: max-age=1209600 12 ObjHeader c Content-Type: image/jpeg 12 ObjHeader c ETag: "268010547" 12 ObjHeader c Last-Modified: Thu, 01 Sep 2011 10:16:30 GMT 12 ObjHeader c Date: Thu, 01 Sep 2011 10:16:43 GMT 12 ObjHeader c Server: [snip] 12 ObjHeader c X-Served-by: [snip] 12 FetchError c straight read_error: 0 0 (Success) 12 VCL_call c error deliver 12 VCL_call c deliver deliver 12 TxProtocol c HTTP/1.1 12 TxStatus c 503 12 TxResponse c Service Unavailable 12 TxHeader c Server: Varnish 12 TxHeader c Content-Type: text/html; charset=utf-8 12 TxHeader c Retry-After: 5 12 TxHeader c Content-Length: 419 12 TxHeader c Accept-Ranges: bytes 12 TxHeader c Date: Thu, 01 Sep 2011 10:16:43 GMT 12 TxHeader c X-Varnish: 1580592381 12 TxHeader c Age: 0 12 TxHeader c Via: 1.1 varnish 12 TxHeader c Connection: close 12 TxHeader c X-Cache: MISS 12 Length c 419 12 ReqEnd c 1580592381 1314872203.445305109 1314872203.485908985 0.000080109 0.040563822 0.000040054 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 10:31:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 10:31:36 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) In-Reply-To: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> References: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> Message-ID: <054.92d1cd3c447f49affc465c2c69fb4f9f@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) ----------------------+----------------------------------------------------- Reporter: albertas | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by albertas): Log: {{{ 12 SessionOpen c [snip] 50872 :80 12 ReqStart c [snip] 50872 1580592381 12 RxRequest c GET 12 RxURL c /images/anns/plius/142/293/98/_477260_small.jpg?id=95?id=10 12 RxProtocol c HTTP/1.1 12 RxHeader c Host: [snip] 12 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1 12 RxHeader c Accept: image/png,image/*;q=0.8,*/*;q=0.5 12 RxHeader c Accept-Language: en-us,en;q=0.5 12 RxHeader c Accept-Encoding: gzip, deflate 12 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 12 RxHeader c Connection: keep-alive 12 RxHeader c Referer: [snip] 12 VCL_call c recv lookup 12 VCL_call c hash 12 Hash c /images/anns/plius/142/293/98/_477260_small.jpg?id=95?id=10 12 Hash c [snip] 12 VCL_return c hash 12 VCL_call c miss fetch 12 Backend c 14 [snip] [snip] 12 TTL c 1580592381 RFC 1.2096e+06 1314872203 0 0 1209600 0 12 VCL_call c fetch deliver 12 ObjProtocol c HTTP/1.1 12 ObjResponse c OK 12 ObjHeader c Expires: Thu, 15 Sep 2011 10:16:43 GMT 12 ObjHeader c Cache-Control: max-age=1209600 12 ObjHeader c Content-Type: image/jpeg 12 ObjHeader c ETag: "268010547" 12 ObjHeader c Last-Modified: Thu, 01 Sep 2011 10:16:30 GMT 12 ObjHeader c Date: Thu, 01 Sep 2011 10:16:43 GMT 12 ObjHeader c Server: [snip] 12 ObjHeader c X-Served-by: [snip] 12 FetchError c straight read_error: 0 0 (Success) 12 VCL_call c error deliver 12 VCL_call c deliver deliver 12 TxProtocol c HTTP/1.1 12 TxStatus c 503 12 TxResponse c Service Unavailable 12 TxHeader c Server: Varnish 12 TxHeader c Content-Type: text/html; charset=utf-8 12 TxHeader c Retry-After: 5 12 TxHeader c Content-Length: 419 12 TxHeader c Accept-Ranges: bytes 12 TxHeader c Date: Thu, 01 Sep 2011 10:16:43 GMT 12 TxHeader c X-Varnish: 1580592381 12 TxHeader c Age: 0 12 TxHeader c Via: 1.1 varnish 12 TxHeader c Connection: close 12 TxHeader c X-Cache: MISS 12 Length c 419 12 ReqEnd c 1580592381 1314872203.445305109 1314872203.485908985 0.000080109 0.040563822 0.000040054 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 10:36:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 10:36:35 -0000 Subject: [Varnish] #1004: Removing auto-start of service under deb install In-Reply-To: <042.497d2a98979a31b609781e323b7eca3b@varnish-cache.org> References: <042.497d2a98979a31b609781e323b7eca3b@varnish-cache.org> Message-ID: <051.6984fb2df932943d5a9aec74e1d555c3@varnish-cache.org> #1004: Removing auto-start of service under deb install ----------------------+----------------------------------------------------- Reporter: eitch | Type: enhancement Status: closed | Priority: normal Milestone: | Component: packaging Version: 3.0.0 | Severity: normal Resolution: wontfix | Keywords: package, service, auto-start ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: Debian policy states it should start by default, and START=no was a mistake added by the Debian maintainer at the time. As you noticed, just use policy-rc.d, it's the right interface. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 11:16:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 11:16:49 -0000 Subject: [Varnish] #1001: Varnish 3.0.1 crashes in http_GetHdr In-Reply-To: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> References: <043.27ab9d55feea7248ae5fbc7018024693@varnish-cache.org> Message-ID: <052.6481b4e53ffa018bc54282059d9818f5@varnish-cache.org> #1001: Varnish 3.0.1 crashes in http_GetHdr ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.1 Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * status: new => closed * resolution: => fixed Comment: Changetset [c14ced83338ed506318c98d167b28787d24669d8] seems to fix it, finally. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 13:09:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 13:09:04 -0000 Subject: [Varnish] #993: 32-bit math somewhere in s_bodybytes (was: 32-bit somewhere math in s_bodybytes) In-Reply-To: <045.818f4a5681e0c9bf025f0897ac2a5620@varnish-cache.org> References: <045.818f4a5681e0c9bf025f0897ac2a5620@varnish-cache.org> Message-ID: <054.24c11630be58e9f5d1c65393ac6a7dfd@varnish-cache.org> #993: 32-bit math somewhere in s_bodybytes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 1 19:23:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 01 Sep 2011 19:23:09 -0000 Subject: [Varnish] #940: ETag for gzip'd variant identical to ETag of ungzipped variant. In-Reply-To: <042.bc99dca97e165d223cfd474527b5eda1@varnish-cache.org> References: <042.bc99dca97e165d223cfd474527b5eda1@varnish-cache.org> Message-ID: <051.fb7a0d44bbc596f7362b6023a0032bba@varnish-cache.org> #940: ETag for gzip'd variant identical to ETag of ungzipped variant. -------------------+-------------------------------------------------------- Reporter: david | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: critical Keywords: | -------------------+-------------------------------------------------------- Comment(by david): phk, My entire website became problematic for many of my users after installing Varnish 3 because of this ETag issue. We had hundreds of support requests on our support board complaining of "Content encoding" errors. If you intend to leave this flaky behavior as the default, I would recommend changing the default VCL to work-around the bug. Expecting users to find this ticket and come up with their own solution doesn't sit well with me. Ultimately, it's your decision to serve conflicting etags or not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 13:02:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 13:02:13 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason Message-ID: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Hi. I've updated my production servers from 2.1.5 to 3.0.1 and since then, I see that my varnishncsa process sometimes just stops with no apparent reason. I will try to get some debug information and will add them to the ticket. Funny thing is that with 2 varnishncsa instances running, both stop at the same time. Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 13:44:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 13:44:20 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.544e87476a09277679ea962eb106bd14@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by tmagnien): Well, finally got it to crash while attached to a gdb : {{{ Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fb09bfc56e0 (LWP 1661)] 0x00007fb09b24ded5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007fb09b24ded5 in raise () from /lib/libc.so.6 #1 0x00007fb09b24f3f3 in abort () from /lib/libc.so.6 #2 0x00007fb09b246dc9 in __assert_fail () from /lib/libc.so.6 #3 0x000000000040370b in collect_client (lp=0x620050, tag=SLT_RxHeader, spec=, ptr=0x7fb096efcb54 "#", len=) at varnishncsa.c:453 #4 0x0000000000403877 in h_ncsa (priv=0x7fb09b569780, tag=SLT_RxHeader, fd=, len=7, spec=1, ptr=0x7fb096efcb54 "#", bitmap=0) at varnishncsa.c:558 #5 0x00007fb09b9ab3c1 in VSL_Dispatch () from /usr/lib/libvarnishapi.so.1 #6 0x00000000004028c4 in main (argc=4, argv=0x7fffa3fd1c78) at varnishncsa.c:881 }}} So the code block that fails is : {{{ case SLT_TxHeader: case SLT_RxHeader: if (!lp->active) break; if (tag == SLT_RxHeader && isprefix(ptr, "authorization:", end, &next) && isprefix(next, "basic", end, &next)) { free(lp->df_u); lp->df_u = trimline(next, end); } else { struct hdr *h; const char *split; h = malloc(sizeof(struct hdr)); AN(h); split = strchr(ptr, ':'); AN(split); h->key = trimline(ptr, split); h->value = trimline(split+1, end); if (tag == SLT_RxHeader) VTAILQ_INSERT_HEAD(&lp->req_headers, h, list); else VTAILQ_INSERT_HEAD(&lp->resp_headers, h, list); } break; }}} And it fails at: {{{ AN(split); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 14:09:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 14:09:11 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.6cf5e00eb518644c7eb42056c220405c@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by scoof): A header without ":" will trigger this assert. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 14:32:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 14:32:20 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.f175f927b4caa451f5e2d1701a55c653@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by scoof): Proposed patch attached -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 21:07:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 21:07:23 -0000 Subject: [Varnish] #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) Message-ID: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) -----------------------+---------------------------------------------------- Reporter: tonyflint | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: major Keywords: | -----------------------+---------------------------------------------------- Varnish version: 3.0.1 (3.0.1-1~lucid1) Architecture: x86_64 RAM: 12G OS/Kernel: Ubuntu 10.04.1/2.6.27.21-0.1-xen VCL: Customized, attached (IPs obfuscated) Varnish is crashing when given a simple request that includes both Range: and Accept-Encoding: headers. The simplest request I've found so far that causes this is: curl -H "Range: bytes=0-40960" -H "Accept-Encoding: gzip" localhost -o /dev/null I'm starting varnish through init with the following DAEMON_OPTS: -a :80 \ -T localhost:2000 \ -f /etc/varnish/default_varnish_3.0.vcl \ -S /etc/varnish/secret \ -s malloc,11G \ -p thread_pool_min=100 \ -p thread_pools=4 \ -p thread_pool_add_delay=2" The syslog panic messages are as follows: Sep 2 13:47:30 localhost varnishd[10752]: Platform: Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Rd start Sep 2 13:47:32 localhost varnishd[10752]: child (10779) Started Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Wr 200 Sep 2 13:47:32 localhost varnishd[10752]: Child (10779) said Child starts Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) died signal=6 Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) Panic message: Assert error in res_dorange(), cache_response.c line 99:#012 Condition(sp->wrk->res_mode & RES_LEN) not true.#012thread = (cache- worker)#012ident = Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x42ea38: /usr/sbin/varnishd() [0x42ea38]#012 0x4320ad: /usr/sbin/varnishd(RES_WriteObj+0x6bd) [0x4320ad]#012 0x416d5b: /usr/sbin/varnishd() [0x416d5b]#012 0x4190cd: /usr/sbin/varnishd(CNT_Session+0x55d) [0x4190cd]#012 0x430398: /usr/sbin/varnishd() [0x430398]#012 0x430821: /usr/sbin/varnishd() [0x430821]#012 0x7fe4a473a9ca: /lib/libpthread.so.0(+0x69ca) [0x7fe4a473a9ca]#012 0x7fe4a449770d: /lib/libc.so.6(clone+0x6d) [0x7fe4a449770d]#012sp = 0x7fe499738008 {#012 fd = 3, id = 3, xid = 887019497,#012 client = 127.0.0.1 49463,#012 step = STP_DELIVER,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esi_level = 0#012 flags = do_gzip do_esi is_gunzip#012 bodystatus = 4#012 ws = 0x7fe499738080 { #012 id = "sess",#012 {s,f,r,e} = {0x7fe499738cc8,+544,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7fe499738080[sess]#012 "GET",#012 "/",#012 "HTTP/1.1",#012 "User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15",#012 "Host: localhost",#012 "Accept: */*",#012 "Range: bytes=0-40960",#012 "app_request: true",#012 "esi_compatible: true",#012 "mobileDelivery: no",#012 "saveMobileOption: ",#012 "wpCookie: ",#012 "mobileOverride: false",#012 "mobileDevice: false",#012 "saveABgroup: true",#012 "X-ABGROUP: B",#012 "X-Forwarded-For: 127.0.0.1",#012 "Accept-Encoding: gzip",#012 },#012 worker = 0x7fe42ee29b60 {#012 ws = 0x7fe42ee29d08 { #012 id = "wrk",#012 {s,f,r,e} = {0x7fe42ee17af0,+2064,(nil),+65536},#012 },#012 http[resp] = {#012 ws = 0x7fe42ee29d08[wrk]#012 "HTTP/1.1",#012 "OK",#012 "Cache Sep 2 13:47:57 localhost varnishd[10752]: Child cleanup complete Attachments: varnish_debug_output.txt -- screen log of running varnishd in debug mode and causing the crash varnishlog_crash_request -- varnishlog of request/crash sequence running_vcl -- VCL running when this crash occurs I have not attached the coredump; it is 3.3G. If it's needed I can upload it to S3 or some other convenient place. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 2 21:12:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Sep 2011 21:12:23 -0000 Subject: [Varnish] #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) In-Reply-To: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> References: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> Message-ID: <055.01142001944f3e38a91125fa47f8ff76@varnish-cache.org> #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) -----------------------+---------------------------------------------------- Reporter: tonyflint | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: major Keywords: | -----------------------+---------------------------------------------------- Comment(by tonyflint): More readable panic message: http://pastebin.com/L1dL31aZ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Sep 3 19:53:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 03 Sep 2011 19:53:17 -0000 Subject: [Varnish] #1008: varnishd not cleaning up temporary files Message-ID: <041.c91458563df5e3cc06dddc6936df00a6@varnish-cache.org> #1008: varnishd not cleaning up temporary files -------------------+-------------------------------------------------------- Reporter: mikl | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I have tried a couple of times setting Varnish up on my Mac. Previously on OS X 10.6 and now on 10.7. I tried setting it up via the launchd service OS X provides for running services. Each time I've tried, Varnish has repaid me with promptly filling up my disks with it's memory files. Here's a sample: {{{ (/usr/local/var/varnish/kerry-pippin.vbg29.local) % la -rw-r--r-- 1 mikl wheel 13M 3 Sep 21:31 _.vsm -rw------- 1 mikl wheel 2,3G 3 Sep 21:29 varnish.HD5s3C -rw------- 1 mikl wheel 26G 3 Sep 21:16 varnish.WJZMH8 -rw------- 1 mikl wheel 325M 3 Sep 21:31 varnish.WtELtL -rw------- 1 mikl wheel 645M 3 Sep 21:30 varnish.XOY0FO -rw------- 1 mikl wheel 13G 3 Sep 21:21 varnish.Xs2Pah -rw------- 1 mikl wheel 9,0G 3 Sep 21:24 varnish.pgcEjg -rw------- 1 mikl wheel 4,5G 3 Sep 21:27 varnish.z1x6hp -rwxr-xr-x 1 mikl wheel 27K 3 Sep 21:31 vcl.Z4hKfxO9.so }}} I think what happens is that I tried to start varnishd with my normal user account, which fails. launchd then restarts varnishd after a cool down period. Each restart causes it to create a new memory file, and at 13 GB each, it tends to fill a 120 GB SSD pretty quickly. Perhaps it would be helpful to remove those files when varnish fails to start? (the error I get when starting is ?03/09/11 21.21.49,388 org.varnish- cache.varnish: Child start failed: could not open sockets?) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 5 09:24:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Sep 2011 09:24:37 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.145859476d73b45bc87fef9494e715e7@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by tmagnien): Well, the patch corrects the problem but I wonder if this is not masking another bug somewehere else. I've added a trace in varnishncsa to print the line that was missing the ":" and the one I got is : {{{ If-None-Match-190bd33-190bd-4a921e68c409c"b6 }}} I wonder if a client really sent this or if varnish made a wrong log entry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 5 11:09:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Sep 2011 11:09:53 -0000 Subject: [Varnish] #1009: Varnish allows invalid headers Message-ID: <042.a4c73404fddab5392acef0625fb76ef0@varnish-cache.org> #1009: Varnish allows invalid headers -------------------+-------------------------------------------------------- Reporter: scoof | Type: defect Status: new | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- See #1006 Varnish should 400 when a client or a server sends an invalid header (one without :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 5 17:29:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Sep 2011 17:29:51 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. Message-ID: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- 3.0.1 build runs on FreeBSD 7.4-RELEASE amd64 and keeps ~20Mbps of traffic volume. Varnishncsa works for half an hour, then makes a coredump. Bt in gdb shows only {{{ #0 0x0000000800b9554c in kill () from /lib/libc.so.7 #1 0x0000000800b9436b in abort () from /lib/libc.so.7 #2 0x0000000000403191 in ?? () #3 0x0000000000402521 in ?? () #4 0x000000000040275d in ?? () #5 0x00000008007538ce in VSL_Dispatch () from /usr/local/lib/libvarnishapi.so.1 (..) #704 0x0000000000000011 in ?? () Cannot access memory at address 0x800000000000 }}} Daemon runs with custom logging parameters: {{{ varnishncsa_logformat='%h %{Host}i %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\" \"%{Cookie}i\" firstbyte:%{Varnish:time_firstbyte}x hitmiss:%{Varnish:hitmiss}x handling:%{handling}x' varnishncsa_flags="-D -F \"${varnishncsa_logformat}\" -P ${varnishncsa_pidfile} -a -c -w ${varnishncsa_file}" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 5 18:11:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Sep 2011 18:11:48 -0000 Subject: [Varnish] #991: vcl(7) does not document rollback, synthetic or panic In-Reply-To: <042.1bfd826bdef13cdfffb10d25f6f62507@varnish-cache.org> References: <042.1bfd826bdef13cdfffb10d25f6f62507@varnish-cache.org> Message-ID: <051.700ad0a84bc45dec32b36bd4bfdaf453@varnish-cache.org> #991: vcl(7) does not document rollback, synthetic or panic ---------------------+------------------------------------------------------ Reporter: fgsch | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Andreas Plesner Jacobsen ): * status: new => closed * resolution: => fixed Comment: (In [db1a21ffba8f34776c0c971de80e29c7fd0766d6]) Add documentation of string syntax, rollback, panic and synthetic keywords. Fixes: #991 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 5 18:50:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Sep 2011 18:50:16 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.5db9af3155f9e2f755b523b1dc862f14@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by scoof): adhering to a one bug per ticket policy, I think we should close this ticket until you have a documented case. Maybe you could get a tcpdump of a request that doesn't make it through? -- Ticket URL: Varnish The Varnish HTTP Accelerator From jeanpralo at gmail.com Mon Sep 5 20:05:49 2011 From: jeanpralo at gmail.com (Jean Praloran) Date: Mon, 5 Sep 2011 22:05:49 +0200 Subject: Bug with VRT_GetHDR on vcl_fetch In-Reply-To: References: Message-ID: Hi there, I'm currently using varnish 3.0.0 on debian Squeeze 64bits, installed from the devbian varnish repository. I'm trying to follow the idea of this script : https://www.varnish-cache.org/trac/wiki/VCLExampleExtendingCacheControl I can't manage to make it work since varnish child crashes : Sep 5 11:51:30 hb03-varnishtest01 varnishd[6396]: Child (6440) Panic message: Assert error in http_GetHdr(), cache_http.c line 266:#012 Condition(l == strlen(hdr + 1)) not true.#012thread = (cache-worker)#012ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x42e678: /usr/sbin/varnishd() [0x42e678]#012 0x429db8: /usr/sbin/varnishd(http_GetHdr+0x68) [0x429db8]#012 0x436cf7: /usr/sbin/varnishd(VRT_GetHdr+0x67) [0x436cf7]#012 0x7f1a44aefb1e: ./ vcl.aubX1cQ8.so(+0x3b1e) [0x7f1a44aefb1e]#012 0x4352d6: /usr/sbin/varnishd(VCL_fetch_method+0x46) [0x4352d6]#012 0x4169b4: /usr/sbin/varnishd() [0x4169b4]#012 0x418fbd: /usr/sbin/varnishd(CNT_Session+0x5fd) [0x418fbd]#012 0x430e28: /usr/sbin/varnishd() [0x430e28]#012 0x42fff9: /usr/sbin/varnishd() [0x42fff9]#012 0x7f1a4d4908ba: /lib/libpthread.so.0(+0x68ba) [0x7f1a4d4908ba]#012sp = 0x7f1a46593008 {#012 fd = 10, id = 10, xid = 1669376956,#012 client = 192.168.1.179 53991,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esi_level = 0#012 flags = #012 bodystatus = 4#012 ws = 0x7f1a46593080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f1a46593cc8,+952,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7f1a46593080[sess]#012 "GET",#012 "/home/index.htm",#012 "HTTP/1.1",#012 "Host: touchpad.xxxx.com",#012 "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21",#012 "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",#012 "Accept-Language: en-us,en;q=0.5",#012 "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",#012 "Keep-Alive: 115",#012 "Connection: keep-alive",#012 "Cookie: RDC_VISITOR_ID=45F47911-FBB0-4751-974E-2F604148814A; xtvrn=$308378$416383$; __utma=7226029.1033579658.1311842517.1315235244.1315251639.39; __utmz=7226029.1315251639.39.35.utmcsr=rueducommerce.fr|utmccn=(referral)|utmcmd=referral|utmcct=/home/index.htm; ST=107716; ORDERID=55339 while using this C embedded : ttl = VRT_GetHdr(sp, HDR_OBJ, "\016Varnish-Control:"); and this crash : Sep 5 11:51:30 hb03-varnishtest01 varnishd[6396]: Child (6440) Panic message: Assert error in http_GetHdr(), cache_http.c line 266:#012 Condition(l == strlen(hdr + 1)) not true.#012thread = (cache-worker)#012ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x42e678: /usr/sbin/varnishd() [0x42e678]#012 0x429db8: /usr/sbin/varnishd(http_GetHdr+0x68) [0x429db8]#012 0x436cf7: /usr/sbin/varnishd(VRT_GetHdr+0x67) [0x436cf7]#012 0x7f1a44aefb1e: ./ vcl.aubX1cQ8.so(+0x3b1e) [0x7f1a44aefb1e]#012 0x4352d6: /usr/sbin/varnishd(VCL_fetch_method+0x46) [0x4352d6]#012 0x4169b4: /usr/sbin/varnishd() [0x4169b4]#012 0x418fbd: /usr/sbin/varnishd(CNT_Session+0x5fd) [0x418fbd]#012 0x430e28: /usr/sbin/varnishd() [0x430e28]#012 0x42fff9: /usr/sbin/varnishd() [0x42fff9]#012 0x7f1a4d4908ba: /lib/libpthread.so.0(+0x68ba) [0x7f1a4d4908ba]#012sp = 0x7f1a46593008 {#012 fd = 10, id = 10, xid = 1669376956,#012 client = 192.168.1.179 53991,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esi_level = 0#012 flags = #012 bodystatus = 4#012 ws = 0x7f1a46593080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f1a46593cc8,+952,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7f1a46593080[sess]#012 "GET",#012 "/home/index.htm",#012 "HTTP/1.1",#012 "Host: touchpad.xxxx.com",#012 "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21",#012 "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",#012 "Accept-Language: en-us,en;q=0.5",#012 "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",#012 "Keep-Alive: 115",#012 "Connection: keep-alive",#012 "Cookie: RDC_VISITOR_ID=45F47911-FBB0-4751-974E-2F604148814A; xtvrn=$308378$416383$; __utma=7226029.1033579658.1311842517.1315235244.1315251639.39; __utmz=7226029.1315251639.39.35.utmcsr=rueducommerce.fr|utmccn=(referral)|utmcmd=referral|utmcct=/home/index.htm; ST=107716; ORDERID=55339 when using this C embedded : ttl = VRT_GetHdr(sp, HDR_BERESP, "\016Varnish-Control:"); I've tried upgrading to 3.0.1 and I still have the same behaviour Thanks for anybody who could help me ! -- Praloran Jean -- Praloran Jean -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Tue Sep 6 07:41:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 07:41:38 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.68e71d2e6f1dc6f8622e03d09f013098@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by tmagnien): No problem for closing this ticket. I'll try to see if I can dump a request but it's real traffic and I don't know if I'll be able to dump all traffic during several hours until I have one fail. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 07:53:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 07:53:22 -0000 Subject: [Varnish] #1009: Varnish allows invalid headers In-Reply-To: <042.a4c73404fddab5392acef0625fb76ef0@varnish-cache.org> References: <042.a4c73404fddab5392acef0625fb76ef0@varnish-cache.org> Message-ID: <051.3eab7c555646ec648a818a98fc278ccb@varnish-cache.org> #1009: Varnish allows invalid headers -------------------------+-------------------------------------------------- Reporter: scoof | Type: defect Status: closed | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: The reason why we do not do this, is that Varnish does not text-process all headers, only the ones it needs to use. RFC2616 says {{{ 10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. }}} If an HTTP request contains a dskfjsldkfslkfjsdl line, Varnish is still perfectly able to understand it, it just ignores that line. If you want to have Varnish be anal retentive about HTTP request, the way to do it, is to write a VMOD::strict. The bug in this case is in varnishncsa (as per ticket #1006). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 07:54:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 07:54:19 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.5299ed051e1602a3dd0edac89119c980@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -------------------------------+-------------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa stops | -------------------------------+-------------------------------------------- Comment(by phk): The bug is in varnishncsa, and should be fixed there. See reply to #1009 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 08:02:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 08:02:37 -0000 Subject: [Varnish] #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) In-Reply-To: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> References: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> Message-ID: <055.243a5326466fae6425d3fc2fe52622f3@varnish-cache.org> #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) -----------------------+---------------------------------------------------- Reporter: tonyflint | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: major Keywords: | -----------------------+---------------------------------------------------- Description changed by phk: Old description: > Varnish version: 3.0.1 (3.0.1-1~lucid1) > Architecture: x86_64 > RAM: 12G > OS/Kernel: Ubuntu 10.04.1/2.6.27.21-0.1-xen > VCL: Customized, attached (IPs obfuscated) > > Varnish is crashing when given a simple request that includes both Range: > and Accept-Encoding: headers. > > The simplest request I've found so far that causes this is: > > curl -H "Range: bytes=0-40960" -H "Accept-Encoding: gzip" localhost -o > /dev/null > > I'm starting varnish through init with the following DAEMON_OPTS: > -a :80 \ > -T localhost:2000 \ > -f /etc/varnish/default_varnish_3.0.vcl \ > -S /etc/varnish/secret \ > -s malloc,11G \ > -p thread_pool_min=100 \ > -p thread_pools=4 \ > -p thread_pool_add_delay=2" > > The syslog panic messages are as follows: > > Sep 2 13:47:30 localhost varnishd[10752]: Platform: > Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit > Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Rd start > Sep 2 13:47:32 localhost varnishd[10752]: child (10779) Started > Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Wr 200 > Sep 2 13:47:32 localhost varnishd[10752]: Child (10779) said Child > starts > Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) died signal=6 > Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) Panic message: > Assert error in res_dorange(), cache_response.c line 99:#012 > Condition(sp->wrk->res_mode & RES_LEN) not true.#012thread = (cache- > worker)#012ident = > Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x42ea38: /usr/sbin/varnishd() [0x42ea38]#012 0x4320ad: > /usr/sbin/varnishd(RES_WriteObj+0x6bd) [0x4320ad]#012 0x416d5b: > /usr/sbin/varnishd() [0x416d5b]#012 0x4190cd: > /usr/sbin/varnishd(CNT_Session+0x55d) [0x4190cd]#012 0x430398: > /usr/sbin/varnishd() [0x430398]#012 0x430821: /usr/sbin/varnishd() > [0x430821]#012 0x7fe4a473a9ca: /lib/libpthread.so.0(+0x69ca) > [0x7fe4a473a9ca]#012 0x7fe4a449770d: /lib/libc.so.6(clone+0x6d) > [0x7fe4a449770d]#012sp = 0x7fe499738008 {#012 fd = 3, id = 3, xid = > 887019497,#012 client = 127.0.0.1 49463,#012 step = STP_DELIVER,#012 > handling = deliver,#012 err_code = 200, err_reason = (null),#012 > restarts = 0, esi_level = 0#012 flags = do_gzip do_esi is_gunzip#012 > bodystatus = 4#012 ws = 0x7fe499738080 { #012 id = "sess",#012 > {s,f,r,e} = {0x7fe499738cc8,+544,(nil),+65536},#012 },#012 http[req] = > {#012 ws = 0x7fe499738080[sess]#012 "GET",#012 "/",#012 > "HTTP/1.1",#012 "User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) > libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15",#012 "Host: > localhost",#012 "Accept: */*",#012 "Range: bytes=0-40960",#012 > "app_request: true",#012 "esi_compatible: true",#012 > "mobileDelivery: no",#012 "saveMobileOption: ",#012 "wpCookie: > ",#012 "mobileOverride: false",#012 "mobileDevice: false",#012 > "saveABgroup: true",#012 "X-ABGROUP: B",#012 "X-Forwarded-For: > 127.0.0.1",#012 "Accept-Encoding: gzip",#012 },#012 worker = > 0x7fe42ee29b60 {#012 ws = 0x7fe42ee29d08 { #012 id = "wrk",#012 > {s,f,r,e} = {0x7fe42ee17af0,+2064,(nil),+65536},#012 },#012 > http[resp] = {#012 ws = 0x7fe42ee29d08[wrk]#012 > "HTTP/1.1",#012 "OK",#012 "Cache > Sep 2 13:47:57 localhost varnishd[10752]: Child cleanup complete > > Attachments: > > varnish_debug_output.txt -- screen log of running varnishd in debug mode > and causing the crash > varnishlog_crash_request -- varnishlog of request/crash sequence > running_vcl -- VCL running when this crash occurs > > I have not attached the coredump; it is 3.3G. If it's needed I can upload > it to S3 or some other convenient place. New description: Varnish version: 3.0.1 (3.0.1-1~lucid1) Architecture: x86_64 RAM: 12G OS/Kernel: Ubuntu 10.04.1/2.6.27.21-0.1-xen VCL: Customized, attached (IPs obfuscated) Varnish is crashing when given a simple request that includes both Range: and Accept-Encoding: headers. The simplest request I've found so far that causes this is: curl -H "Range: bytes=0-40960" -H "Accept-Encoding: gzip" localhost -o /dev/null {{{ I'm starting varnish through init with the following DAEMON_OPTS: -a :80 \ -T localhost:2000 \ -f /etc/varnish/default_varnish_3.0.vcl \ -S /etc/varnish/secret \ -s malloc,11G \ -p thread_pool_min=100 \ -p thread_pools=4 \ -p thread_pool_add_delay=2" The syslog panic messages are as follows: Sep 2 13:47:30 localhost varnishd[10752]: Platform: Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Rd start Sep 2 13:47:32 localhost varnishd[10752]: child (10779) Started Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Wr 200 Sep 2 13:47:32 localhost varnishd[10752]: Child (10779) said Child starts Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) died signal=6 Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) Panic message: Assert error in res_dorange(), cache_response.c line 99: Condition(sp->wrk->res_mode & RES_LEN) not true. thread = (cache-worker) ident = Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42ea38: /usr/sbin/varnishd() [0x42ea38] 0x4320ad: /usr/sbin/varnishd(RES_WriteObj+0x6bd) [0x4320ad] 0x416d5b: /usr/sbin/varnishd() [0x416d5b] 0x4190cd: /usr/sbin/varnishd(CNT_Session+0x55d) [0x4190cd] 0x430398: /usr/sbin/varnishd() [0x430398] 0x430821: /usr/sbin/varnishd() [0x430821] 0x7fe4a473a9ca: /lib/libpthread.so.0(+0x69ca) [0x7fe4a473a9ca] 0x7fe4a449770d: /lib/libc.so.6(clone+0x6d) [0x7fe4a449770d] sp = 0x7fe499738008 { fd = 3, id = 3, xid = 887019497, client = 127.0.0.1 49463, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 flags = do_gzip do_esi is_gunzip bodystatus = 4 ws = 0x7fe499738080 { id = "sess", {s,f,r,e} = {0x7fe499738cc8,+544,(nil),+65536}, }, http[req] = { ws = 0x7fe499738080[sess] "GET", "/", "HTTP/1.1", "User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15", "Host: localhost", "Accept: */*", "Range: bytes=0-40960", "app_request: true", "esi_compatible: true", "mobileDelivery: no", "saveMobileOption: ", "wpCookie: ", "mobileOverride: false", "mobileDevice: false", "saveABgroup: true", "X-ABGROUP: B", "X-Forwarded-For: 127.0.0.1", "Accept-Encoding: gzip", }, worker = 0x7fe42ee29b60 { ws = 0x7fe42ee29d08 { id = "wrk", {s,f,r,e} = {0x7fe42ee17af0,+2064,(nil),+65536}, }, http[resp] = { ws = 0x7fe42ee29d08[wrk] "HTTP/1.1", "OK", "Cache Sep 2 13:47:57 localhost varnishd[10752]: Child cleanup complete }}} Attachments: varnish_debug_output.txt -- screen log of running varnishd in debug mode and causing the crash varnishlog_crash_request -- varnishlog of request/crash sequence running_vcl -- VCL running when this crash occurs I have not attached the coredump; it is 3.3G. If it's needed I can upload it to S3 or some other convenient place. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From kristian at varnish-software.com Tue Sep 6 08:13:53 2011 From: kristian at varnish-software.com (Kristian Lyngstol) Date: Tue, 6 Sep 2011 10:13:53 +0200 Subject: Bug with VRT_GetHDR on vcl_fetch In-Reply-To: References: Message-ID: <20110906081353.GE3515@freud.kly.no> On Mon, Sep 05, 2011 at 10:05:49PM +0200, Jean Praloran wrote: > I'm currently using varnish 3.0.0 on debian Squeeze 64bits, installed from > the devbian varnish repository. I'm trying to follow the idea of this script > : https://www.varnish-cache.org/trac/wiki/VCLExampleExtendingCacheControl > > I can't manage to make it work since varnish child crashes : [...] > Condition(l == strlen(hdr + 1)) not true.#012thread = > > while using this C embedded : > > ttl = VRT_GetHdr(sp, HDR_OBJ, "\016Varnish-Control:"); [...] \016 is octal. Your length thus ends up being incorrect. I suggest \020. Also, you should use either a bug report or the -misc or -dev list. The -bug list is mainly intended for automatic mails from trac. - Kristian From varnish-bugs at varnish-cache.org Tue Sep 6 08:15:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 08:15:59 -0000 Subject: [Varnish] #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) In-Reply-To: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> References: <046.d569a499df4430b5a9755fbb9a334b40@varnish-cache.org> Message-ID: <055.cf985d31c16c9c2be5aa7cfb0b6f5494@varnish-cache.org> #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99) ------------------------+--------------------------------------------------- Reporter: tonyflint | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: major Resolution: fixed | Keywords: ------------------------+--------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [8548216821a2710953f2063be75490bb0d9d7eba]) I have not been able to reproduce this exact circumstance, but the fix is readily obvious, so: Tighten requirement for range delivery. Fixes #1007 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 08:21:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 08:21:19 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.ed5b9c39395851d908df8ca787db6ef4@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by tfheen): Could you please provide us a backtrace from a non-stripped varnishncsa, preferably one compiled with debug symbols? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 08:25:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 08:25:37 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.9018da59a39be0fce5362563fb2fe2cd@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -----------------------+---------------------------------------------------- Reporter: tmagnien | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: varnishncsa stops -----------------------+---------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => fixed Comment: Fixed in [e0007862dee9352d63bc2da613304f4652810b9d] -- Ticket URL: Varnish The Varnish HTTP Accelerator From jeanpralo at gmail.com Tue Sep 6 08:30:16 2011 From: jeanpralo at gmail.com (Jean Praloran) Date: Tue, 6 Sep 2011 10:30:16 +0200 Subject: Bug with VRT_GetHDR on vcl_fetch In-Reply-To: <20110906081353.GE3515@freud.kly.no> References: <20110906081353.GE3515@freud.kly.no> Message-ID: Ok sure ! Thanks for your help should have search more on the internet. Found few doc about the embedded c thought. Wouldn't it be better just checking the lenght first and returns a null pointer instead of crashing the process ? On Tue, Sep 6, 2011 at 10:13 AM, Kristian Lyngstol < kristian at varnish-software.com> wrote: > On Mon, Sep 05, 2011 at 10:05:49PM +0200, Jean Praloran wrote: > > I'm currently using varnish 3.0.0 on debian Squeeze 64bits, installed > from > > the devbian varnish repository. I'm trying to follow the idea of this > script > > : > https://www.varnish-cache.org/trac/wiki/VCLExampleExtendingCacheControl > > > > I can't manage to make it work since varnish child crashes : > > [...] > > > Condition(l == strlen(hdr + 1)) not true.#012thread = > > > > while using this C embedded : > > > > ttl = VRT_GetHdr(sp, HDR_OBJ, "\016Varnish-Control:"); > > [...] > > \016 is octal. Your length thus ends up being incorrect. I suggest \020. > > Also, you should use either a bug report or the -misc or -dev list. The > -bug list is mainly intended for automatic mails from trac. > > - Kristian > -- Praloran Jean -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Tue Sep 6 09:12:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 09:12:37 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) In-Reply-To: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> References: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> Message-ID: <054.cdef6563fe6f9307be62dfdb5134f2ea@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) ----------------------+----------------------------------------------------- Reporter: albertas | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by phk): This is a poor log message, but basically it means that your backend closed the connection on you. It is not a bug in varnish, but it could be a matter of tuning timeout parameters. I'm leaving the ticket open as reminder to improve that message. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 10:56:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 10:56:28 -0000 Subject: [Varnish] #1003: Fix libedit (libreadline) support for FreeBSD In-Reply-To: <043.f95607e90f4cdd104e1a516653ef63ba@varnish-cache.org> References: <043.f95607e90f4cdd104e1a516653ef63ba@varnish-cache.org> Message-ID: <052.98548a260dff596d98e422f0decc48a9@varnish-cache.org> #1003: Fix libedit (libreadline) support for FreeBSD -------------------------+-------------------------------------------------- Reporter: anders | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by anders): Possible solutions: - use canonware.com libedit (also in ports system) - use libreadline which is in FreeBSD base but which has a GPL licence - wait for FreeBSD libedit to grow rl_ readline hooks Would prefer not to wait for ages. :P What do we do, auto tools meister? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 11:37:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 11:37:10 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.940af787d4069e2de588c5e287bd4d1c@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by konrad.grzybowski@?): {{{ (gdb) bt full #0 0x0000000800b9654c in kill () from /lib/libc.so.7 No symbol table info available. #1 0x0000000800b9536b in abort () from /lib/libc.so.7 No symbol table info available. #2 0x0000000000403c82 in VAS_Fail_default (func=Could not find the frame base for "VAS_Fail_default". ) at ../../lib/libvarnish/assert.c:59 No locals. #3 0x0000000000402821 in collect_client (lp=0x800d49d00, tag=SLT_RxHeader, spec=1, ptr=0x801255e04 "User-Agees/mostimp.gif HTTP/1.1 J", len=31) at varnishncsa.c:453 h = (struct hdr *) 0x800d6aae0 split = 0x0 end = 0x801255e23 " J" next = 0x402bf0 "UH\211?SH\201?\001" l = 34373211680 t = 34373402848 __func__ = "collect_client" #4 0x0000000000402e29 in h_ncsa (priv=0x800cd9620, tag=SLT_RxHeader, fd=307, len=31, spec=1, ptr=0x801255e04 "User-Agees/mostimp.gif HTTP/1.1 J", bitmap=0) at varnishncsa.c:558 lp = (struct logline *) 0x800d49d00 fo = (FILE *) 0x800cd9620 q = 0x206
tbuf = "[06/Sep/2011:13:22:21 +0200]\000\000\000\000??\000\b\000\000\000\022C\232\000\b\000\000\000?\200?\000\b\000\000\000\032\000\000\000\000\000\000" p = 0x7fffffffe938 "" os = (struct vsb *) 0x7fffffffe940 __func__ = "h_ncsa" #5 0x00000008007548ce in VSL_Dispatch () from /usr/local/lib/libvarnishapi.so.1 No symbol table info available. #6 0x0000000000403a69 in main (argc=10, argv=0x7fffffffea20) at varnishncsa.c:881 c = -1 a_flag = 1 D_flag = 1 format_flag = 1 P_arg = 0x7fffffffedaf "/var/run/varnishncsa.pid" w_arg = 0x7fffffffedd1 "/var/log/varnishncsa.log" pfh = (struct vpf_fh *) 0x800d22800 of = (FILE *) 0x800cd9620 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 12:56:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 12:56:18 -0000 Subject: [Varnish] #1008: varnishd not cleaning up temporary files In-Reply-To: <041.c91458563df5e3cc06dddc6936df00a6@varnish-cache.org> References: <041.c91458563df5e3cc06dddc6936df00a6@varnish-cache.org> Message-ID: <050.569f3a51709424e2049ad2925d562ac0@varnish-cache.org> #1008: varnishd not cleaning up temporary files ---------------------+------------------------------------------------------ Reporter: mikl | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [daa446eb29a1d90b452dc8ccf31bf28b6c4c516b]) Unlink -s file with autogenerated names If just -s file or -s file,/path/to/directory is given, the file stevedore will generate a name. Make sure to unlink this to not leak disk space over time. Fixes: #1008 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 13:10:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 13:10:10 -0000 Subject: [Varnish] #999: format keyword "handling" and the '>' in %s In-Reply-To: <040.1057bddb127c1f0c6e49cfad280c49bf@varnish-cache.org> References: <040.1057bddb127c1f0c6e49cfad280c49bf@varnish-cache.org> Message-ID: <049.0455dde119e39945caeee3d967913628@varnish-cache.org> #999: format keyword "handling" and the '>' in %s ------------------------------+--------------------------------------------- Reporter: Kai | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: trunk | Severity: normal Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [4633d008fac58813b06bdc421dd31787851b6c50]) Fix up default format string in man page and code comments We're actually using %s, not %>s, since we don't support >. Thanks to Kai for patch Fixes: #999 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 13:10:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 13:10:13 -0000 Subject: [Varnish] #999: format keyword "handling" and the '>' in %s In-Reply-To: <040.1057bddb127c1f0c6e49cfad280c49bf@varnish-cache.org> References: <040.1057bddb127c1f0c6e49cfad280c49bf@varnish-cache.org> Message-ID: <049.6314cd916d164d23d4a598dfc609023d@varnish-cache.org> #999: format keyword "handling" and the '>' in %s ------------------------------+--------------------------------------------- Reporter: Kai | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: trunk | Severity: normal Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Comment(by Tollef Fog Heen ): (In [efaa48a908806f9d0a0969f840393e5b77771036]) Fix handling vs Varnish:handling in varnishncsa Thanks to Kai for patch Fixes: #999 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 14:33:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 14:33:08 -0000 Subject: [Varnish] #1011: --disable-jemalloc has changed to --without-jemalloc Message-ID: <040.eea826921b07684d05125d7ac513e066@varnish-cache.org> #1011: --disable-jemalloc has changed to --without-jemalloc -------------------+-------------------------------------------------------- Reporter: pej | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Keywords: | -------------------+-------------------------------------------------------- Attempting to build rpm's on ppc64 gives the following warning:[[BR]] configure: WARNING: unrecognized options: --disable-jemalloc[[BR]] It seems this parameter has changed to --without-jemalloc. I have attached a patch for updating the varnish.spec. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 6 16:08:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Sep 2011 16:08:36 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) In-Reply-To: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> References: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> Message-ID: <054.ece6e56348f5f2beea6f91099cd16fb4@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) ----------------------+----------------------------------------------------- Reporter: albertas | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by rzuidhof): I can confirm this problem in 3.0.1 {{{ 425 TxURL b /images/test.pdf 425 TxProtocol b HTTP/1.1 425 TxHeader b Host: www.localhost.localdomain 425 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21 GTB7.1 ( .NET CLR 3.5.30729) 425 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 425 TxHeader b Accept-Language: en-us,en;q=0.5 425 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 425 TxHeader b X-Forwarded-For: 192.168.1.6 425 TxHeader b X-Varnish: 1101341981 425 TxHeader b Accept-Encoding: gzip 425 RxProtocol b HTTP/1.1 425 RxStatus b 200 425 RxResponse b OK 425 RxHeader b Date: Tue, 06 Sep 2011 15:12:00 GMT 425 RxHeader b Server: Apache/2.2.3 (CentOS) 425 RxHeader b Last-Modified: Tue, 06 Sep 2011 13:53:29 GMT 425 RxHeader b ETag: "169c519-3688b6-4ac3627026840" 425 RxHeader b Accept-Ranges: bytes 425 RxHeader b Content-Length: 3574942 425 RxHeader b Connection: close 425 RxHeader b Content-Type: application/pdf 425 Fetch_Body b 4 -1 1 425 BackendClose b localhost 22 VCL_call c recv lookup 22 VCL_call c hash 22 Hash c /images/test.pdf 22 Hash c www.localhost.localdomain 22 VCL_return c hash 22 VCL_call c miss fetch 22 Backend c 425 default localhost 22 TTL c 1101341981 RFC 120 -1 -1 1315321921 0 1315321920 0 0 22 VCL_call c fetch 22 TTL c 1101341981 VCL 120 43200 -1 1315321921 -0 22 TTL c 1101341981 VCL 1200 43200 -1 1315321921 -0 22 VCL_return c deliver 22 ObjProtocol c HTTP/1.1 22 ObjResponse c OK 22 ObjHeader c Date: Tue, 06 Sep 2011 15:12:00 GMT 22 ObjHeader c Server: Apache/2.2.3 (CentOS) 22 ObjHeader c Last-Modified: Tue, 06 Sep 2011 13:53:29 GMT 22 ObjHeader c ETag: "169c519-3688b6-4ac3627026840" 22 ObjHeader c Content-Type: application/pdf 22 FetchError c straight read_error: -1 12 (Cannot allocate memory) 22 VCL_call c error restart 22 VCL_call c recv lookup 22 VCL_call c hash 22 Hash c /images/test.pdf 22 Hash c www.localhost.localdomain 22 VCL_return c hash 22 VCL_call c miss fetch 22 Backend c 425 default localhost 22 TTL c 1101341981 RFC 120 -1 -1 1315321921 0 1315321920 0 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 7 12:08:24 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Sep 2011 12:08:24 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) In-Reply-To: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> References: <045.4267be1b0158919ced17c313f45cdafc@varnish-cache.org> Message-ID: <054.13965a2df97edac99a4d1ab4730e95f3@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) -----------------------+---------------------------------------------------- Reporter: albertas | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [bac89d865448f9525e2a82a9ace0c8d708e0c144]) Improve the FetchError VSL messages. Fixes #1005 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 7 13:18:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 07 Sep 2011 13:18:22 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) Message-ID: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) ----------------------+----------------------------------------------------- Reporter: rzuidhof | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Keywords: | ----------------------+----------------------------------------------------- Sometimes we receive "FetchError c straight read_error: -1 12 (Cannot allocate memory)" which results in a 503 error. The backend response on these cases is good and fast: a 200 response with the proper byte count. It seems to happen more for big files (100 KB - 1 MB). In case of a chunked backend response this is "FetchError c chunked read_error: 12 (Cannot allocate memory)". It looks like a memory problem. We used to be affected by the memory problem in 3.0.0 with the malloc storage. This happens just as well on malloc as on file storage. But only when the storage is filled, so not directly after restart. We have a high value for beresp.grace (hours). {{{ 425 TxURL b /images/test.pdf 425 TxProtocol b HTTP/1.1 425 TxHeader b Host: www.localhost.localdomain 425 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21 GTB7.1 ( .NET CLR 3.5.30729) 425 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 425 TxHeader b Accept-Language: en-us,en;q=0.5 425 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 425 TxHeader b X-Forwarded-For: 192.168.1.6 425 TxHeader b X-Varnish: 1101341981 425 TxHeader b Accept-Encoding: gzip 425 RxProtocol b HTTP/1.1 425 RxStatus b 200 425 RxResponse b OK 425 RxHeader b Date: Tue, 06 Sep 2011 15:12:00 GMT 425 RxHeader b Server: Apache/2.2.3 (CentOS) 425 RxHeader b Last-Modified: Tue, 06 Sep 2011 13:53:29 GMT 425 RxHeader b ETag: "169c519-3688b6-4ac3627026840" 425 RxHeader b Accept-Ranges: bytes 425 RxHeader b Content-Length: 3574942 425 RxHeader b Connection: close 425 RxHeader b Content-Type: application/pdf 425 Fetch_Body b 4 -1 1 425 BackendClose b localhost 22 VCL_call c recv lookup 22 VCL_call c hash 22 Hash c /images/test.pdf 22 Hash c www.localhost.localdomain 22 VCL_return c hash 22 VCL_call c miss fetch 22 Backend c 425 default localhost 22 TTL c 1101341981 RFC 120 -1 -1 1315321921 0 1315321920 0 0 22 VCL_call c fetch 22 TTL c 1101341981 VCL 120 43200 -1 1315321921 -0 22 TTL c 1101341981 VCL 1200 43200 -1 1315321921 -0 22 VCL_return c deliver 22 ObjProtocol c HTTP/1.1 22 ObjResponse c OK 22 ObjHeader c Date: Tue, 06 Sep 2011 15:12:00 GMT 22 ObjHeader c Server: Apache/2.2.3 (CentOS) 22 ObjHeader c Last-Modified: Tue, 06 Sep 2011 13:53:29 GMT 22 ObjHeader c ETag: "169c519-3688b6-4ac3627026840" 22 ObjHeader c Content-Type: application/pdf 22 FetchError c straight read_error: -1 12 (Cannot allocate memory) 22 VCL_call c error restart 22 VCL_call c recv lookup 22 VCL_call c hash 22 Hash c /images/test.pdf 22 Hash c www.localhost.localdomain 22 VCL_return c hash 22 VCL_call c miss fetch 22 Backend c 425 default localhost 22 TTL c 1101341981 RFC 120 -1 -1 1315321921 0 1315321920 0 0 22 VCL_call c fetch 22 TTL c 1101341981 VCL 120 43200 -1 1315321921 -0 22 TTL c 1101341981 VCL 1200 43200 -1 1315321921 -0 22 VCL_return c deliver 22 ObjProtocol c HTTP/1.1 22 ObjResponse c OK 22 ObjHeader c Date: Tue, 06 Sep 2011 15:12:00 GMT 22 ObjHeader c Server: Apache/2.2.3 (CentOS) 22 ObjHeader c Last-Modified: Tue, 06 Sep 2011 13:53:29 GMT 22 ObjHeader c ETag: "169c519-3688b6-4ac3627026840" 22 ObjHeader c Content-Type: application/pdf 22 FetchError c straight read_error: -1 12 (Cannot allocate memory) 22 VCL_call c error deliver 22 VCL_call c deliver deliver 22 TxProtocol c HTTP/1.1 22 TxStatus c 503 22 TxResponse c Service Unavailable 22 TxHeader c Server: Varnish 22 TxHeader c Content-Type: text/html; charset=utf-8 22 TxHeader c Retry-After: 5 22 TxHeader c Content-Length: 419 22 TxHeader c Accept-Ranges: bytes 22 TxHeader c Date: Tue, 06 Sep 2011 15:12:00 GMT 22 TxHeader c X-Varnish: 1101341981 22 TxHeader c Age: 0 22 TxHeader c Via: 1.1 varnish 22 TxHeader c Connection: close 22 Length c 419 22 ReqEnd c 1101341981 1315321920.669218063 1315321920.738457918 0.000200033 0.069125891 0.000113964 22 SessionClose c error 22 StatSess c 192.168.1.6 10521 0 1 1 0 0 0 257 419 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 08:10:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 08:10:15 -0000 Subject: [Varnish] #1006: varnishncsa stops with no apparent reason In-Reply-To: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> References: <045.1610c80da6a814aac1a82a957bc093df@varnish-cache.org> Message-ID: <054.b865481de213eb68aafd6f0c4fd1eabb@varnish-cache.org> #1006: varnishncsa stops with no apparent reason -----------------------+---------------------------------------------------- Reporter: tmagnien | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: varnishncsa stops -----------------------+---------------------------------------------------- Comment(by tmagnien): Just to keep track of what happened, here are the varnishlog output and tcpdump making this bug happen. This was due to a broken client sending linefeed in the cookie header: {{{ 100 ReqStart c 95.136.165.85 49759 1046477818 100 RxRequest c GET 100 RxURL c /reboot/images/mn-trame.png 100 RxProtocol c HTTP/1.1 100 RxHeader c Host: cache.20minutes.fr 100 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0 100 RxHeader c Accept: image/png,image/*;q=0.8,*/*;q=0.5 100 RxHeader c Accept-Language: fr,fr-fr;q=0.8,en- us;q=0.5,en;q=0.3 100 RxHeader c Accept-Encoding: gzip, deflate 100 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 100 RxHeader c Connection: keep-alive 100 RxHeader c Referer: http://cache.20minutes.fr/minified /common-prepend-1311002095.css 100 RxHeader c Cookie: __utma=141384369.1022668416.1305831876.1315410001.1315428713.17; __utmz=141384369.1315428713.17.17.utmcsr=news.google.fr|utmccn=(referral)|utmcmd=referral|utmcct=/nwshp; TestIfCookieP=ok; pid=9015983930972768243; pbw=%24b%3D12999%3B%24o%3D11061%3B 100 RxHeader c ?zAsuivreet%C3%A0commenterici%C3%A0partirde17h&cliccz=N&dest=http%3A%2F%2Fwww.20minutes.fr%2Farticle%2F781966 %2Fus-open-simon-isner-suivre-live-comme-a-la-maison-retarde- pluie&posx=0.5&posy=0.5&time=77&pmed=Simon-Isner&s2med=3 100 RxHeader c If-Modified-Since: Tue, 16 Aug 2011 09:33:22 GMT 100 RxHeader c If-None-Match: "1242f3-67-4aa9c12179c80" 100 VCL_call c recv 100 VCL_Log c X-Backend: bush_pilote_cdn_16 100 VCL_return c lookup 100 VCL_call c hash 100 Hash c /reboot/images/mn-trame.png 100 Hash c cache.20minutes.pullorigin.pilote-cdn.sfr-sh.fr 100 VCL_return c hash 100 Hit c 970966282 100 VCL_call c hit deliver 100 VCL_call c deliver deliver 100 TxProtocol c HTTP/1.1 100 TxStatus c 304 100 TxResponse c Not Modified 100 TxHeader c Server: Apache 100 TxHeader c Last-Modified: Tue, 16 Aug 2011 09:33:22 GMT 100 TxHeader c ETag: "1242f3-67-4aa9c12179c80" 100 TxHeader c Content-Type: image/png 100 TxHeader c X-Pad: avoid browser bug 100 TxHeader c Accept-Ranges: bytes 100 TxHeader c Date: Wed, 07 Sep 2011 20:53:29 GMT 100 TxHeader c X-Varnish: 1046477818 970966282 100 TxHeader c Age: 211277 100 TxHeader c Connection: keep-alive 100 TxHeader c Via: 1.1 proxy-1.pilote-cdn.sfr-sh.fr, 1.1 cbv4 -ncdn-cache05 100 Length c 0 100 ReqEnd c 1046477818 1315428809.932852983 1315428809.932941437 2.745071650 0.000051498 0.000036955 }}} {{{ 22:53:29.932802 IP (tos 0x0, ttl 116, id 8418, offset 0, flags [DF], proto TCP (6), length 1282) 95.136.165.85.49759 > 93.20.64.247.80: P, cksum 0xf573 (correct), 1239:2481(1242) ack 368 win 17057 0x0000: 4500 0502 20e2 4000 7406 3e2b 5f88 a555 E..... at .t.>+_..U 0x0010: 5d14 40f7 c25f 0050 133c 4519 56cb 0a8a ]. at .._.P.. 0x03b0: d1c9 9356 095f dcb9 7bcb 223e 7492 940a ...V._..{.">t... 0x03c0: e87a 4173 7569 7672 6565 7425 4333 2541 .zAsuivreet%C3%A 0x03d0: 3063 6f6d 6d65 6e74 6572 6963 6925 4333 0commenterici%C3 0x03e0: 2541 3070 6172 7469 7264 6531 3768 2663 %A0partirde17h&c 0x03f0: 6c69 6363 7a3d 4e26 6465 7374 3d68 7474 liccz=N&dest=htt 0x0400: 7025 3341 2532 4625 3246 7777 772e 3230 p%3A%2F%2Fwww.20 0x0410: 6d69 6e75 7465 732e 6672 2532 4661 7274 minutes.fr%2Fart 0x0420: 6963 6c65 2532 4637 3831 3936 3625 3246 icle%2F781966%2F 0x0430: 7573 2d6f 7065 6e2d 7369 6d6f 6e2d 6973 us-open-simon-is 0x0440: 6e65 722d 7375 6976 7265 2d6c 6976 652d ner-suivre-live- 0x0450: 636f 6d6d 652d 612d 6c61 2d6d 6169 736f comme-a-la-maiso 0x0460: 6e2d 7265 7461 7264 652d 706c 7569 6526 n-retarde-pluie& 0x0470: 706f 7378 3d30 2e35 2670 6f73 793d 302e posx=0.5&posy=0. 0x0480: 3526 7469 6d65 3d37 3726 706d 6564 3d53 5&time=77&pmed=S 0x0490: 696d 6f6e 2d49 736e 6572 2673 326d 6564 imon-Isner&s2med 0x04a0: 3d33 0d0a 4966 2d4d 6f64 6966 6965 642d =3..If-Modified- 0x04b0: 5369 6e63 653a 2054 7565 2c20 3136 2041 Since:.Tue,.16.A 0x04c0: 7567 2032 3031 3120 3039 3a33 333a 3232 ug.2011.09:33:22 0x04d0: 2047 4d54 0d0a 4966 2d4e 6f6e 652d 4d61 .GMT..If-None-Ma 0x04e0: 7463 683a 2022 3132 3432 6633 2d36 372d tch:."1242f3-67- 0x04f0: 3461 6139 6331 3231 3739 6338 3022 0d0a 4aa9c12179c80".. 0x0500: 0d0a }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 09:24:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 09:24:57 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.1f2245dc5a5f488ac7026e7221f3aa07@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by Armdan): Hi all. The same problem here with Varnish 3.0.1 on CentOS 5.x with precompiled rpms. I can't provide the backtrace but the daemon dies with the following message: Assert error in collect_client(), varnishncsa.c line 453: Condition((split) != 0) not true. Kind regards. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 09:28:44 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 09:28:44 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.0b298c7eeeef22c5b768cef0407970ac@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by scoof): Armdan: That's a completely different issue that is already fixed. See #1006. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 09:53:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 09:53:22 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.1ef0f8b4761d19f411a2156394710266@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by Armdan): scoof: yeah you are right ! The next time I'll check closed tickets also. Sorry about the noise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 12:00:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 12:00:42 -0000 Subject: [Varnish] #1013: New planet.varnish.org feed Message-ID: <040.02feeed3f1ae8266c4ea6223a1e45958@varnish-cache.org> #1013: New planet.varnish.org feed -------------------+-------------------------------------------------------- Reporter: moo | Type: documentation Status: new | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: minor Keywords: | -------------------+-------------------------------------------------------- Hi, I am a huge fan of Varnish and have blogged about it few times. What's the policy of having your feed in planet.varnish.org? Does one quality even though not being a core developer of Varnish? My Varnish posts are available from this RSS URL: http://opensourcehacker.com/tag/varnish/feed Cheers, Mikko -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 15:48:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 15:48:54 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() Message-ID: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() --------------------+------------------------------------------------------- Reporter: russki | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Hiya Running Varnish 3.0.1 on Debian Lenny, 64bit kernel, seeing these crashes, related to Gzip compression Using the instructions about Compression from https://www.varnish- cache.org/trac/wiki/FAQ/Compression in my VCL file -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 15:56:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 15:56:28 -0000 Subject: [Varnish] #1015: varnishncsa frequently segfaults Message-ID: <043.73f0f4dd5bda5c0dfc06d5ae3fbb94ee@varnish-cache.org> #1015: varnishncsa frequently segfaults --------------------+------------------------------------------------------- Reporter: russki | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Hiya Running Varnish 3.0.1 on 64bit Lenny, using these flags for Varnishncsa: /usr/bin/varnishncsa -c -F %{Host}i %b %{Varnish:time_firstbyte}x -- %h %l %u %t "%m %U%q %H" %s %b "%{Referer}i" "%{User-agent}i" | /usr/bin/logger -t varnish -p local2.info Seeing these segfaults: kernel: varnishncsa[9960]: segfault at 0 ip 0000000000403b6c sp 00007fff6e369eb0 error 4 in varnishncsa[400000+6000] Full list is included in the attachment Thanky in advance for your time :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 8 22:56:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Sep 2011 22:56:18 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> References: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> Message-ID: <054.f5df1726a09a530b6ca6e6eb8ea41d6d@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) ----------------------+----------------------------------------------------- Reporter: rzuidhof | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by scoof): I assume you've hit your max cache size. Could you try increasing nuke_limit? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 06:02:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 06:02:04 -0000 Subject: [Varnish] #1013: New planet.varnish.org feed In-Reply-To: <040.02feeed3f1ae8266c4ea6223a1e45958@varnish-cache.org> References: <040.02feeed3f1ae8266c4ea6223a1e45958@varnish-cache.org> Message-ID: <049.7efeaa83249d232147affdfaba9176bc@varnish-cache.org> #1013: New planet.varnish.org feed ---------------------+------------------------------------------------------ Reporter: moo | Type: documentation Status: closed | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: minor Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: As long as the posts are about Varnish we'd like to have it, so I've added your feed now. Should arrive with the next planet run. Cheers! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 08:50:50 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 08:50:50 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> References: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> Message-ID: <054.761261362294547aa8a93199aa3bd70e@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) ----------------------+----------------------------------------------------- Reporter: rzuidhof | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by rzuidhof): Thanks. Resetting nuke_limit to its former default of 50 instead of 10 did the trick. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 09:04:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 09:04:04 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> References: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> Message-ID: <054.6f1cc7e36fff3418e38381bcf4ea2c74@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) ----------------------+----------------------------------------------------- Reporter: rzuidhof | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by rzuidhof): Please change this in the source code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 11:36:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 11:36:19 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> References: <045.4cf664cf15566d05ce451f19dd5d7b49@varnish-cache.org> Message-ID: <054.570cdc72eafdf927ab864688dff0ce01@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) -----------------------+---------------------------------------------------- Reporter: rzuidhof | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by Andreas Plesner Jacobsen ): * status: new => closed * resolution: => fixed Comment: (In [8156c297082a43396324f062bdc97aba2a9af2ec]) Restore old nuke_limit, as 10 seems to be too low Fixes #1012 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 12:56:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 12:56:33 -0000 Subject: [Varnish] #997: vcl(7) does not documents probe's expected_response or interval In-Reply-To: <042.09e85bcd8e611c8a0148bcbbd15f5618@varnish-cache.org> References: <042.09e85bcd8e611c8a0148bcbbd15f5618@varnish-cache.org> Message-ID: <051.04f65d6895c49eeea76bb5ee07080e94@varnish-cache.org> #997: vcl(7) does not documents probe's expected_response or interval ---------------------+------------------------------------------------------ Reporter: fgsch | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Andreas Plesner Jacobsen ): * status: new => closed * resolution: => fixed Comment: (In [76a050fd10b6ab423be673cce5ee12fda049356f]) Add .expected_response to probe documentation. Fix error message for .expected_response. Fixes #997 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 13:31:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 13:31:46 -0000 Subject: [Varnish] #971: Broken DNS director In-Reply-To: <041.9508303297df487382a44071219d6bc8@varnish-cache.org> References: <041.9508303297df487382a44071219d6bc8@varnish-cache.org> Message-ID: <050.6697300d7938bd710cfb13f13e23761e@varnish-cache.org> #971: Broken DNS director ----------------------+----------------------------------------------------- Reporter: rdvn | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by Andreas Plesner Jacobsen ): (In [ce9dd3bb3b887731a203781e6d23b85010497191]) Add type to connect_timeout References #971 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 9 15:44:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 09 Sep 2011 15:44:14 -0000 Subject: [Varnish] #997: vcl(7) does not documents probe's expected_response or interval In-Reply-To: <042.09e85bcd8e611c8a0148bcbbd15f5618@varnish-cache.org> References: <042.09e85bcd8e611c8a0148bcbbd15f5618@varnish-cache.org> Message-ID: <051.853b59508fd09d21dda049fee2459339@varnish-cache.org> #997: vcl(7) does not documents probe's expected_response or interval ---------------------+------------------------------------------------------ Reporter: fgsch | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Andreas Plesner Jacobsen ): (In [f7c36f94d4be6f1b92c93d9c723267700a8c5b97]) Tabulate probe properties and add all missing ones Really fixes #997 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 07:37:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 07:37:10 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() In-Reply-To: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> References: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> Message-ID: <052.6936bbabf212b2a8504e592a5fb7468a@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() ---------------------+------------------------------------------------------ Reporter: russki | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [c71797102fae2ea0775ceabba96431990394939f]) Always call fetch- processor begin, also if C-L header is bogus. Fixes #1014 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 07:38:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 07:38:29 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() In-Reply-To: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> References: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> Message-ID: <052.c3751192c4012c13954f2d9fb0222225@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() ---------------------+------------------------------------------------------ Reporter: russki | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by phk): Please notice that you backend sent a "Content-Length:" header with no specified value, this is probably a problem somewhere on you backend. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 08:17:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 08:17:21 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> References: <060.4172f39127fecc78fbf9dadc8977af8e@varnish-cache.org> Message-ID: <069.d1dd4c6397c6fc64d8c36ab11d38db55@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. -----------------------------------------+---------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: new | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Keywords: varnishncsa memory coredump | -----------------------------------------+---------------------------------- Comment(by konrad.grzybowski@?): Is there anything more that I can do to help you with this issue? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 10:13:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 10:13:56 -0000 Subject: [Varnish] #993: 32-bit math somewhere in s_bodybytes In-Reply-To: <045.818f4a5681e0c9bf025f0897ac2a5620@varnish-cache.org> References: <045.818f4a5681e0c9bf025f0897ac2a5620@varnish-cache.org> Message-ID: <054.69af4bcb74d7be33bca2f1c4e0ebcb5b@varnish-cache.org> #993: 32-bit math somewhere in s_bodybytes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [b16790a74f5e5ffb34d2f27027778399a90a3f71]) Avoid 32 bit variables in stats aggregation. Fixes #993 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 10:15:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 10:15:01 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() In-Reply-To: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> References: <043.e1f9f299c5e04112618787a8ab3aaaa6@varnish-cache.org> Message-ID: <052.79b4b2ba037fe1de9c64016b7d9ce45a@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() ---------------------+------------------------------------------------------ Reporter: russki | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Poul-Henning Kamp ): (In [f336ffe66fe7f0a565539cf83e46aa93ba96f5ef]) Commit the actual fix for #1014 and not just the test-case. Fixes #1014 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 12 10:33:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Sep 2011 10:33:17 -0000 Subject: [Varnish] #1011: --disable-jemalloc has changed to --without-jemalloc In-Reply-To: <040.eea826921b07684d05125d7ac513e066@varnish-cache.org> References: <040.eea826921b07684d05125d7ac513e066@varnish-cache.org> Message-ID: <049.20cc6eaeca14bf976feba2aa60193811@varnish-cache.org> #1011: --disable-jemalloc has changed to --without-jemalloc ---------------------+------------------------------------------------------ Reporter: pej | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [6447d64122b337c6c6ef662a398eac6babc1dd80]) Updating configure line for ppc64, as --disabled-jemalloc has changed to --without-jemalloc Patch from P?l-Eivind Johnsen Fixes: #1011 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 13 06:09:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Sep 2011 06:09:49 -0000 Subject: [Varnish] #1015: varnishncsa frequently segfaults In-Reply-To: <044.7f34c08db42070969e1cca0520956dd6@varnish-cache.org> References: <044.7f34c08db42070969e1cca0520956dd6@varnish-cache.org> Message-ID: <053.b39558f081773aebc9446ca95578151f@varnish-cache.org> #1015: varnishncsa frequently segfaults --------------------+------------------------------------------------------- Reporter: russki | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by tfheen): Could you try to capture a backtrace or a core file please? Just the segfault and address doesn't actually tell us much. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 13 06:10:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Sep 2011 06:10:43 -0000 Subject: [Varnish] #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. In-Reply-To: <061.f76dd36142bbc28545c878442f8ed6bc@varnish-cache.org> References: <061.f76dd36142bbc28545c878442f8ed6bc@varnish-cache.org> Message-ID: <070.0084768d86f8bd64685dbdbaf4eddd9c@varnish-cache.org> #1010: varnishncsa makes a coredump with an "Cannot access memory at address 0x800000000000" error. --------------------------------------+------------------------------------- Reporter: konrad.grzybowski@? | Type: defect Status: closed | Priority: low Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: normal Resolution: duplicate | Keywords: varnishncsa memory coredump --------------------------------------+------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1006. I'll backport the fix for that to the 3.0 git branch and it'll be in 3.0.2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 13 14:01:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Sep 2011 14:01:28 -0000 Subject: [Varnish] #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) Message-ID: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) --------------------------------+------------------------------------------- Reporter: christian.albrecht | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | --------------------------------+------------------------------------------- Hi, after upgrading to Varnish 3.0.1 from 2.1.5 I've noticed many 413 requests in varnishlog. The 413 requests are triggered by very long cookie headers. After some research I found your fix in Changeset d7c7c39abd8c56a7bce04991c7a8c35b58940dca (ticket #939). I manually increased the value of http_resp_hdr_len and http_req_hdr_len from 4096 bytes to 8192 bytes. I have not seen any 413 requests since then. Is it possible to increase both values in trunk too? Best regards, Christian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 14 14:30:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Sep 2011 14:30:22 -0000 Subject: [Varnish] #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) In-Reply-To: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> References: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> Message-ID: <065.261b264422a46ccd4075b5268f2c7591@varnish-cache.org> #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) --------------------------------+------------------------------------------- Reporter: christian.albrecht | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | --------------------------------+------------------------------------------- Comment(by rgacogne): Hi, Just to add that, if I'm not mistaken, Apache HTTPd uses a default maximum request header size of 8190 (LimitRequestFieldsize) and Nginx 4k ok 8k (large_client_header_buffers) depending of the platform's size of page. Regards, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 14 21:32:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 14 Sep 2011 21:32:30 -0000 Subject: [Varnish] #1017: ESI includes not getting parsed due to faulty comments Message-ID: <045.981863e14617d6b1135311ff58c5c5c9@varnish-cache.org> #1017: ESI includes not getting parsed due to faulty comments --------------------------+------------------------------------------------- Reporter: ddunlop | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.1 | Severity: normal Keywords: esi, parsing | --------------------------+------------------------------------------------- When a document has invalid comments in it esi tags are missed. for example: a comment such as this: This was not the case prior to 3.0.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 15 07:04:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Sep 2011 07:04:45 -0000 Subject: [Varnish] #1018: Man vcl missing director options Message-ID: <043.0ef8568f105acbda1448ea0094a04325@varnish-cache.org> #1018: Man vcl missing director options ---------------------------+------------------------------------------------ Reporter: scoof | Owner: scoof Type: documentation | Status: new Priority: lowest | Milestone: Component: documentation | Version: trunk Severity: trivial | Keywords: ---------------------------+------------------------------------------------ DNS director is missing .host_header and there's probably more. -- Ticket URL: Varnish The Varnish HTTP Accelerator From mailing.lists.wam at gmail.com Thu Sep 15 17:28:41 2011 From: mailing.lists.wam at gmail.com (mailing.lists.wam) Date: Thu, 15 Sep 2011 19:28:41 +0200 Subject: varnish 3 trunk crash with persistent storage enabled Message-ID: <4E7235C9.4010900@gmail.com> Hello, We encounter various varnish panic (the forked processus crash, won't restart and nothing listen to http/80 port anymore), with persistent storage (tested with 20/35/40/90G) and kernel address randomize On/Off. Same servers with file,malloc parameters instead of persistent are healthy. Feel free to contact me to get the full coredump. All details below :) Varnish Version : 3 - trunk d56069e Sep 06, 2011 d56069e8ef221310d75455feb9b03483c9caf63b Ubuntu 10.04 64Bits Linux 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux 48G RAM / two Intel(R) Xeon(R) CPU L5640 @ 2.27GHz SSD-SATA 90G 2) Startup config : VARNISH_INSTANCE=default START=yes NFILES="131072" MEMLOCK="82000" VARNISH_VCL_CONF=/etc/varnish/default/default.vcl VARNISH_LISTEN_ADDRESS= VARNISH_LISTEN_PORT=80 VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 VARNISH_ADMIN_LISTEN_PORT=6082 VARNISH_SECRET_FILE=/etc/varnish/default/secret VARNISH_THREAD_POOLS=12 VARNISH_STORAGE_FILE_1=/mnt/ssd/varnish/cachefile1 VARNISH_STORAGE_SIZE=30G VARNISH_STORAGE_1="persistent,${VARNISH_STORAGE_FILE_1},${VARNISH_STORAGE_SIZE}" DAEMON_OPTS=" -n ${VARNISH_INSTANCE} \ -u root \ -a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \ -f ${VARNISH_VCL_CONF} \ -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \ -S ${VARNISH_SECRET_FILE} \ -s ${VARNISH_STORAGE_1} \ -s Transient=malloc,1G\ -p first_byte_timeout=5 \ -p between_bytes_timeout=5 \ -p pipe_timeout=5 \ -p send_timeout=2700 \ -p default_grace=240 \ -p default_ttl=3600 \ -p http_gzip_support=off \ -p http_range_support=on \ -p max_restarts=2 \ -p thread_pool_add_delay=2 \ -p thread_pool_max=4000 \ -p thread_pool_min=80 \ -p thread_pool_timeout=120 \ -p thread_pools=12 \ -p thread_stats_rate=50 #### VCL FILE ##### ### SECDownMod ### https://github.com/footplus/libvmod-secdown import secdown; include "/etc/varnish/backend/director_edge_2xx.vcl"; include "/etc/varnish/acl/purge.vcl"; sub vcl_recv { set req.backend = origin; if (req.request !~ "(GET|HEAD|PURGE)") { error 405 "Not allowed."; } if (req.url ~ "^/files") { set req.url = secdown.check_url(req.url, "MySecretIsNotYourSecret", "/link-expired.html", "/link-error.html"); } # Before anything else we need to fix gzip compression if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|flv|ts|mp4)$") { # No point in compressing these remove req.http.Accept-Encoding; } else if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } else if (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unknown algorithm remove req.http.Accept-Encoding; } } # Allow a PURGE method to clear cache via regular expression. if (req.request == "PURGE") { # If the client has not an authorized IP or # if he comes from the HTTPS proxy on localhost, deny it. if (!client.ip ~ purge || req.http.X-Forwarded-For) { error 405 "Not allowed."; } ban_url(req.url); error 200 "Expression " + req.url + " added to ban.list."; } } sub vcl_pipe { set bereq.http.connection = "close"; } sub vcl_pass { # return (pass); } sub vcl_hash { hash_data(req.url); return (hash); } sub vcl_hit { # return (deliver); } sub vcl_miss { # return (fetch); } sub vcl_fetch { unset beresp.http.expires; set beresp.http.cache-control = "max-age=86400"; set beresp.ttl = 365d; if (beresp.status >= 400) { set beresp.ttl = 1m; } if ((beresp.status == 301) || (beresp.status == 302) || (beresp.status == 401)) { return (hit_for_pass); } } sub vcl_deliver { # Rename Varnish XIDs headers if (resp.http.X-Varnish) { set resp.http.X-Object-ID = resp.http.X-Varnish; unset resp.http.X-Varnish; } remove resp.http.Via; remove resp.http.X-Powered-By; # return (deliver); } sub vcl_error { # Do not reveal what's inside the box :) remove obj.http.Server; set obj.http.Server = "EdgeCache/1.4"; } sub vcl_init { # return (ok); } sub vcl_fini { # return (ok); } 3) Assert Message (from syslog) Sep 15 18:21:02 e101 default[18290]: Child (19438) said Out of space in persistent silo Sep 15 18:21:02 e101 default[18290]: Child (19438) said Committing suicide, restart will make space Sep 15 18:21:02 e101 default[18290]: Child (19438) ended Sep 15 18:21:02 e101 default[18290]: Child cleanup complete Sep 15 18:21:02 e101 default[18290]: child (20924) Started Sep 15 18:21:02 e101 default[18290]: Child (20924) said Child starts Sep 15 18:21:02 e101 default[18290]: Child (20924) said Dropped 11 segments to make free_reserve Sep 15 18:21:02 e101 default[18290]: Child (20924) said Silo completely loaded Sep 15 18:21:27 e101 default[18290]: Child (20924) died signal=6 (core dumped) Sep 15 18:21:27 e101 default[18290]: Child (20924) Panic message: Assert error in smp_oc_getobj(), storage_persistent_silo.c line 401:#012 Condition((o)->mag ic == 0x32851d42) not true.#012thread = (ban-lurker)#012ident = Linux,2.6.32-33-generic,x86_64,-spersistent,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x437e 49: pan_backtrace+19#012 0x43811e: pan_ic+1ad#012 0x45da38: smp_oc_getobj+282#012 0x415407: oc_getobj+14c#012 0x417848: ban_lurker_work+299#012 0x41793d: ban_lurker+5b#012 0x43ad91: wrk_bgthread+184#012 0x7ffff6a9c9ca: _end+7ffff6408692#012 0x7ffff67f970d: _end+7ffff61653d5#012 Sep 15 18:21:27 e101 default[18290]: Child cleanup complete Sep 15 18:21:27 e101 default[18290]: child (21898) Started Sep 15 18:21:27 e101 default[18290]: Pushing vcls failed: CLI communication error (hdr) Sep 15 18:21:27 e101 default[18290]: Stopping Child Sep 15 18:21:27 e101 default[18290]: Child (21898) died signal=6 (core dumped) Sep 15 18:21:27 e101 default[18290]: Child (21898) Panic message: Assert error in smp_open_segs(), storage_persistent.c line 239:#012 Condition(sg1->p.offset != sg->p.offset) not true.#012thread = (cache-main)#012ident = Linux,2.6.32-33-generic,x86_64,-spersistent,-smalloc,-hcritbit,no_waiter#012Backtrace:#012 0x 437e49: pan_backtrace+19#012 0x43811e: pan_ic+1ad#012 0x45a568: smp_open_segs+415#012 0x45ab93: smp_open+236#012 0x456391: STV_open+40#012 0x435fa4: chil d_main+124#012 0x44d3a7: start_child+36a#012 0x44ddce: mgt_sigchld+3e7#012 0x7ffff7bd1fec: _end+7ffff753dcb4#012 0x7ffff7bd2348: _end+7ffff753e010#012 Sep 15 18:21:27 e101 default[18290]: Child (-1) said Child starts Sep 15 18:21:27 e101 default[18290]: Child cleanup complete 4) GDB Core bt (gdb) bt #0 0x00007ffff6746a75 in raise () from /lib/libc.so.6 #1 0x00007ffff674a5c0 in abort () from /lib/libc.so.6 #2 0x00000000004381dd in pan_ic (func=0x482dd5 "smp_open_segs", file=0x4827c4 "storage_persistent.c", line=239, cond=0x48283f "sg1->p.offset != sg->p.offset", err=0, xxx=0) at cache_panic.c:374 #3 0x000000000045a568 in smp_open_segs (sc=0x7ffff6433000, ctx=0x7ffff6433220) at storage_persistent.c:239 #4 0x000000000045ab93 in smp_open (st=0x7ffff64213c0) at storage_persistent.c:331 #5 0x0000000000456391 in STV_open () at stevedore.c:406 #6 0x0000000000435fa4 in child_main () at cache_main.c:128 #7 0x000000000044d3a7 in start_child (cli=0x0) at mgt_child.c:345 #8 0x000000000044ddce in mgt_sigchld (e=0x7ffff64da1d0, what=-1) at mgt_child.c:524 #9 0x00007ffff7bd1fec in vev_sched_signal (evb=0x7ffff6408380) at vev.c:435 #10 0x00007ffff7bd2348 in vev_schedule_one (evb=0x7ffff6408380) at vev.c:478 #11 0x00007ffff7bd1d2a in vev_schedule (evb=0x7ffff6408380) at vev.c:363 #12 0x000000000044e1c9 in MGT_Run () at mgt_child.c:602 #13 0x0000000000461a64 in main (argc=0, argv=0x7fffffffebd0) at varnishd.c:650 5) Last lines of varnishlog 221 SessionOpen c 85.93.199.29 58335 :80 234 SessionOpen c 77.196.147.182 2273 :80 From varnish-bugs at varnish-cache.org Sun Sep 18 16:44:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 18 Sep 2011 16:44:10 -0000 Subject: [Varnish] #1019: FastCGI backend support Message-ID: <046.dc635463c8fe4d92be00d3fa72f208c2@varnish-cache.org> #1019: FastCGI backend support ----------------------+----------------------------------------------------- Reporter: weltling | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- An useful feature I'm suggesting is the FCGI backend support. The main idea behind it is to decrease the timeout between backend and varnish. For now, the schema to work with a FCGI backend is to include a webserver, wich translates HTTP to FCGI, so for instance Varnish => Apache => FCGI site Using Varnish to translate the HTTP stuff for a FCGI backend would decrease timeouts and also would fit the Varnish threading concept, as FCGI potentially supports a request ids, which can be processed parallel within the same backend instance. Despite many FastCGI apps do not use this feature, since implemented, could have essential performance impacts. So the schema would be than Varnish => FCGI backend This could be done declaratively in the backend definition, for instance backend fcgi_default { .host = "::1"; .type = "fcgi"; .port = "8085"; } so the type could be "http" or "fcgi" ... or future pursuant anything ... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 18 16:53:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 18 Sep 2011 16:53:02 -0000 Subject: [Varnish] #1020: UNIX socket support Message-ID: <046.7883390102b927e928d7dc262eec8aa0@varnish-cache.org> #1020: UNIX socket support ----------------------+----------------------------------------------------- Reporter: weltling | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- When backend and varnish are running on the same mashine, it would make sense to let to communicate both through the local UNIX socket. Possible declaration in the VCL would look like backend default { .sock = "/tmp/backend.sock"; } This would be also match the #1019 for fcgi, so the declaration could look like backend default { .sock = "/tmp/backend.sock"; .type = "fcgi"; } so performance could go up by this two things. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 18 16:54:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 18 Sep 2011 16:54:02 -0000 Subject: [Varnish] #1019: FastCGI backend support In-Reply-To: <046.dc635463c8fe4d92be00d3fa72f208c2@varnish-cache.org> References: <046.dc635463c8fe4d92be00d3fa72f208c2@varnish-cache.org> Message-ID: <055.917677cc401221294b73703c9998b5a0@varnish-cache.org> #1019: FastCGI backend support ----------------------+----------------------------------------------------- Reporter: weltling | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by weltling): please see also #1020 for increasing more performance on fcgi -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 18 17:08:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 18 Sep 2011 17:08:19 -0000 Subject: [Varnish] #1020: UNIX socket support In-Reply-To: <046.7883390102b927e928d7dc262eec8aa0@varnish-cache.org> References: <046.7883390102b927e928d7dc262eec8aa0@varnish-cache.org> Message-ID: <055.519571a474b9191272373932644ab1cd@varnish-cache.org> #1020: UNIX socket support -----------------------+---------------------------------------------------- Reporter: weltling | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Hi, Suggestions of this sort belongs in the wiki on the "Future_*" pages, so I'm closing this and #1019. This does not mean we don't want you ideas, we just want to reserve the tickets for actual bugs which can be fixed, otherwise the bugs tend to drown in a sea of good ideas and intentions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 18 17:08:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 18 Sep 2011 17:08:52 -0000 Subject: [Varnish] #1019: FastCGI backend support In-Reply-To: <046.dc635463c8fe4d92be00d3fa72f208c2@varnish-cache.org> References: <046.dc635463c8fe4d92be00d3fa72f208c2@varnish-cache.org> Message-ID: <055.826e2b50f8b0d690a91520539c1d27f4@varnish-cache.org> #1019: FastCGI backend support -----------------------+---------------------------------------------------- Reporter: weltling | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Closed, ideas and changerequsts go in the wiki (see also #1020) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 07:06:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 07:06:34 -0000 Subject: [Varnish] #1021: varnishlog -1 Message-ID: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> #1021: varnishlog -1 --------------------+------------------------------------------------------- Reporter: yves | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Keywords: varnishlog --------------------+------------------------------------------------------- output of varnishlog -1 is always empty. tested on CentOS 5.6 & Ubuntu 10.04.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 07:43:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 07:43:02 -0000 Subject: [Varnish] #1022: Mac OS X compilation error Message-ID: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> #1022: Mac OS X compilation error -----------------------------+---------------------------------------------- Reporter: 191919 | Type: defect Status: new | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Keywords: | -----------------------------+---------------------------------------------- Mac OS X does not implement clock_gettime.[[BR]] [[BR]] gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib/libvgz -I../../include -I/usr/local/include -DVARNISH_STATE_DIR='"/usr/local/var/varnish"' -DVARNISH_VMOD_DIR='"/usr/local/lib/varnish/vmods"' -DVARNISH_VCL_DIR='"/usr/local/etc/varnish"' -g -O2 -D_THREAD_SAFE -Wextra -Wno-missing-field-initializers -Wno-sign-compare -MT varnishd- cache_pool.o -MD -MP -MF .deps/varnishd-cache_pool.Tpo -c -o varnishd- cache_pool.o `test -f 'cache_pool.c' || echo './'`cache_pool.c[[BR]] [[BR]] cache_pool.c: In function 'pool_herder':[[BR]] cache_pool.c:426: warning: implicit declaration of function 'clock_gettime'[[BR]] cache_pool.c:426: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)[[BR]] cache_pool.c:426: error: (Each undeclared identifier is reported only once[[BR]] cache_pool.c:426: error: for each function it appears in.)[[BR]] cache_pool.c: In function 'pool_mkpool':[[BR]] cache_pool.c:503: warning: implicit declaration of function 'pthread_condattr_setclock'[[BR]] cache_pool.c:503: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)[[BR]] cache_pool.c: At top level:[[BR]] cache_pool.c:557: fatal error: opening dependency file .deps/varnishd- cache_pool.Tpo: Permission denied[[BR]] compilation terminated.[[BR]] make[3]: *** [varnishd-cache_pool.o] Error 1[[BR]] make[2]: *** [all-recursive] Error 1[[BR]] make[1]: *** [all-recursive] Error 1[[BR]] make: *** [all] Error 2[[BR]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 10:04:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 10:04:38 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.b5e576a0850a441b4cbe761c8cdbb1ae@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [f0746df953ca90e11a48e10d9b6383feb63ac1f6]) OS/X does not have CLOCK_MONOTONIC, use CLOCK_REALTIME and hope nobody steps the clock... Fixes #1022 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 10:08:03 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 10:08:03 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.bdff56f3ac77619559c78e46904a7f69@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: reopened | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: | Keywords: ------------------------------+--------------------------------------------- Changes (by 191919): * status: closed => reopened * resolution: fixed => Comment: Mac OS X doesn't have clock_gettime, not just CLOCK_MONOTONIC.[[BR]] [[BR]] {{{ cache_pool.c: In function 'pool_herder': cache_pool.c:430: warning: implicit declaration of function 'clock_gettime' cache_pool.c:430: error: 'CLOCK_REALTIME' undeclared (first use in this function) cache_pool.c:430: error: (Each undeclared identifier is reported only once cache_pool.c:430: error: for each function it appears in.) cache_pool.c: In function 'pool_mkpool': cache_pool.c:508: warning: implicit declaration of function 'pthread_condattr_setclock' cache_pool.c:508: error: 'CLOCK_REALTIME' undeclared (first use in this function) cache_pool.c: At top level: cache_pool.c:563: fatal error: opening dependency file .deps/varnishd- cache_pool.Tpo: Permission denied compilation terminated. make[3]: *** [varnishd-cache_pool.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 10:13:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 10:13:32 -0000 Subject: [Varnish] #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) In-Reply-To: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> References: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> Message-ID: <065.ef0566670d898bc9f9fe995e628dac09@varnish-cache.org> #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) --------------------------------+------------------------------------------- Reporter: christian.albrecht | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: --------------------------------+------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 10:33:40 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 10:33:40 -0000 Subject: [Varnish] #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog In-Reply-To: <042.15b343f5b586622bfa8da764e472d2fe@varnish-cache.org> References: <042.15b343f5b586622bfa8da764e472d2fe@varnish-cache.org> Message-ID: <051.0e3b5e6dd582db48a1736a851e5564aa@varnish-cache.org> #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog -------------------------+-------------------------------------------------- Reporter: wido | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Keywords: init,ubuntu,debian -------------------------+-------------------------------------------------- Changes (by martin): * owner: martin => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 10:34:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 10:34:02 -0000 Subject: [Varnish] #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa In-Reply-To: <042.70dfaa156eefaf7b04de37f215b09c9a@varnish-cache.org> References: <042.70dfaa156eefaf7b04de37f215b09c9a@varnish-cache.org> Message-ID: <051.e78e2783a6099de81ac11585938fa0f1@varnish-cache.org> #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa -------------------------+-------------------------------------------------- Reporter: wido | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by martin): * owner: martin => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 19 18:26:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Sep 2011 18:26:51 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.6cb7b948e8773c22f62276dc477da1ea@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Changes (by Poul-Henning Kamp ): * status: reopened => closed * resolution: => fixed Comment: (In [e5975a5f721fa91b954735b54121d54554696cba]) Fix OS/X compilation for good. Fixes #1022 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 02:16:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 02:16:48 -0000 Subject: [Varnish] #1023: If all idle clients stay idle, none of the idle connections are closed when they timeout. Message-ID: <045.39fa878ad93af23ad23dd0f71697689b@varnish-cache.org> #1023: If all idle clients stay idle, none of the idle connections are closed when they timeout. ---------------------+------------------------------------------------------ Reporter: drwilco | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ https://www.varnish- cache.org/trac/browser/bin/varnishd/cache_waiter_poll.c?rev=c10599526e8f43d9c999a470d530f643752d2564#L147 That little if right there makes it so if the poll returns 0 (no idle clients did anything) the connection isn't closed. This is potentially bad, and is not in line with the other waiters' behavior. Simplest thing would be to remove lines 147 & 148. The whole waiter could probably use a rewrite to go through the idle connections a bit more efficiently, like the other waiters do. But do people actually use the poll() waiter? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 07:03:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 07:03:55 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run (was: varnishlog -1) In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <051.da2371bc699b03fa4f276eea671db065@varnish-cache.org> #1021: varnishtop -1 takes a long time to run --------------------+------------------------------------------------------- Reporter: yves | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Keywords: varnishlog --------------------+------------------------------------------------------- Old description: > output of varnishlog -1 is always empty. > > tested on CentOS 5.6 & Ubuntu 10.04.3. New description: varnishtop -1 on a busy server takes a very long time to run where we've seen run times of 22 minutes (!) on a single machine. -- Comment(by tfheen): Updating description and summary to match reality. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 07:50:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 07:50:54 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.b224e1fde6410c037ca54378f5a33dae@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Comment(by andreacampi): Have a look at https://github.com/ThomasHabets/monotonic_clock/blob/c8ccb9eb9d1def8b1b8193a3d515fbd3e9a527be/src/monotonic_mach.c for a Mac-native implementation of a monotonic clock. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 08:10:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 08:10:33 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.53c191fe2471e6a9d7269435f27686ef@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Comment(by phk): I'm not going to bother as long as OSX is a Tier-B platform (see: https://www.varnish-cache.org/docs/trunk/phk/platforms.html) I want OSX to work well enough that people can work with the source code on their macbooks, but as far as I am informed, OSX is not a relevant operating system for production use of Varnish, so optimizations like the one you suggest is overkill. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 08:47:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 08:47:38 -0000 Subject: [Varnish] #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog In-Reply-To: <042.15b343f5b586622bfa8da764e472d2fe@varnish-cache.org> References: <042.15b343f5b586622bfa8da764e472d2fe@varnish-cache.org> Message-ID: <051.bec079292ab133866a5277da819b8649@varnish-cache.org> #830: Init script doesn't allow you to set DAEMON_OPTS for varnishlog --------------------------------+------------------------------------------- Reporter: wido | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: init,ubuntu,debian | --------------------------------+------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in the Debian packaging in git: commit f0bb6a736ddaa6d0418ede93a7a8f8566dea2ab5 Author: Tollef Fog Heen Date: Tue Sep 20 10:40:58 2011 +0200 Make it possible to override DAEMON_OPTS for varnishlog, varnishncsa Move setting of DAEMON_OPTS earlier making it possible to override from the default files. Fixes Varnish trac #830, #831 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 08:47:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 08:47:43 -0000 Subject: [Varnish] #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa In-Reply-To: <042.70dfaa156eefaf7b04de37f215b09c9a@varnish-cache.org> References: <042.70dfaa156eefaf7b04de37f215b09c9a@varnish-cache.org> Message-ID: <051.09fe82976583ee638f30623dc75d792e@varnish-cache.org> #831: Init script doesn't allow you to set DAEMON_OPTS for varnishncsa -------------------------+-------------------------------------------------- Reporter: wido | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Later Component: packaging | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in the Debian packaging in git: commit f0bb6a736ddaa6d0418ede93a7a8f8566dea2ab5 Author: Tollef Fog Heen Date: Tue Sep 20 10:40:58 2011 +0200 Make it possible to override DAEMON_OPTS for varnishlog, varnishncsa Move setting of DAEMON_OPTS earlier making it possible to override from the default files. Fixes Varnish trac #830, #831 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 08:48:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 08:48:15 -0000 Subject: [Varnish] #981: /etc/init.d/varnish status always returns 0 on debian/ubuntu In-Reply-To: <042.89611cd95c1e7de06abfc04c59bf8a89@varnish-cache.org> References: <042.89611cd95c1e7de06abfc04c59bf8a89@varnish-cache.org> Message-ID: <051.e84f9329c43bc40e8b9a2b810831074b@varnish-cache.org> #981: /etc/init.d/varnish status always returns 0 on debian/ubuntu --------------------------------+------------------------------------------- Reporter: kane | Type: defect Status: closed | Priority: normal Milestone: After Varnish 2.1 | Component: packaging Version: 2.1.5 | Severity: normal Resolution: fixed | Keywords: init.d debian ubuntu packaging --------------------------------+------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in the Debian packaging's git: commit 5c069f6773e005f30e8a349354c1cd584f6c7a9e Author: Tollef Fog Heen Date: Tue Sep 20 10:45:45 2011 +0200 Fix exit code of /etc/init.d/varnish status Make /etc/init.d/varnish status exit with a sensible status code rather than always being 0 Fixes Varnish trac: #981 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 08:54:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 08:54:57 -0000 Subject: [Varnish] #983: reload-vcl doesn't support all varnishd flags In-Reply-To: <042.c22e9fb98e5db4e0bb93550fd6ccdb71@varnish-cache.org> References: <042.c22e9fb98e5db4e0bb93550fd6ccdb71@varnish-cache.org> Message-ID: <051.423b24ed41a597bed6da0ff04f1e7aa3@varnish-cache.org> #983: reload-vcl doesn't support all varnishd flags -----------------------+---------------------------------------------------- Reporter: kane | Owner: ssm Type: defect | Status: closed Priority: lowest | Milestone: Component: packaging | Version: 3.0.0 Severity: trivial | Resolution: fixed Keywords: | -----------------------+---------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Old description: > Seems reload-vcl has a hardcoded list of parameters that varnishd takes, > but at least in 2.1.5 they're out of sync. So when running reload, the > following happens (non-fatal): > > $ sudo /etc/init.d/varnish reload > * Reloading HTTP accelerator varnishd > Illegal option -i > ...done. > > The patch is trivial and inline below: > > --- /usr/share/varnish/reload-vcl 2011-01-27 16:24:36.000000000 > +0000 > +++ /tmp/reload-vcl 2011-08-17 01:03:06.000000000 +0000 > @@ -87,7 +87,7 @@ > # Extract the -f and the -T option, and (try to) ensure that the > # management interface is on the form hostname:address. > OPTIND=1 > -while getopts a:b:dFf:g:h:l:n:P:p:S:s:T:t:u:Vw: flag $DAEMON_OPTS > +while getopts a:b:CdFf:g:h:i:l:M:n:P:p:S:s:T:t:u:Vw: flag $DAEMON_OPTS > do > case $flag in > f) New description: Seems reload-vcl has a hardcoded list of parameters that varnishd takes, but at least in 2.1.5 they're out of sync. So when running reload, the following happens (non-fatal): $ sudo /etc/init.d/varnish reload * Reloading HTTP accelerator varnishd Illegal option -i ...done. The patch is trivial and inline below: --- /usr/share/varnish/reload-vcl 2011-01-27 16:24:36.000000000 +0000 +++ /tmp/reload-vcl 2011-08-17 01:03:06.000000000 +0000 @@ -87,7 +87,7 @@ # Extract the -f and the -T option, and (try to) ensure that the # management interface is on the form hostname:address. OPTIND=1 -while getopts a:b:dFf:g:h:l:n:P:p:S:s:T:t:u:Vw: flag $DAEMON_OPTS +while getopts a:b:dFf:g:h:l:n:P:p:S:s:T:t:u:Vw: flag $DAEMON_OPTS do case $flag in f) -- Comment: Fixed in: commit 00a71725e497ed0be6d25165160c3fd076973d08 Author: Tollef Fog Heen Date: Tue Sep 20 10:54:26 2011 +0200 Add missing options to reload-vcl to allow -C, -i, -M. Fixes Varnish trac: #983 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 09:10:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 09:10:14 -0000 Subject: [Varnish] #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) In-Reply-To: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> References: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> Message-ID: <065.2919f8178a40a63051d2f308e029a8ec@varnish-cache.org> #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) --------------------------------+------------------------------------------- Reporter: christian.albrecht | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [e1fea86a22813af16533edcab374a1043fdb3593]) Increase http_req_size, http_resp_size to 8192 bytes Apache (and nginx) uses 8k, so use the same default size to avoid people being surprised by more 413 responses than necessary. Fixes: #1016 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 09:10:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 09:10:17 -0000 Subject: [Varnish] #976: Updated zope-plone.vcl to Varnish 3.x In-Reply-To: <051.49a41b0505ba0bd338cd348b06bc79ef@varnish-cache.org> References: <051.49a41b0505ba0bd338cd348b06bc79ef@varnish-cache.org> Message-ID: <060.0943eb1dae9dd0290a5fd759c7a08735@varnish-cache.org> #976: Updated zope-plone.vcl to Varnish 3.x ----------------------------+----------------------------------------------- Reporter: cleberjsantos | Type: enhancement Status: closed | Priority: normal Milestone: Later | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: update ----------------------------+----------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [8ff8091eb4239f2e257288d02a84b67241cb3ad4]) Update zope-plone.vcl to v3 syntax Thanks to cleberjsantos for initial patch which this is based on. Fixes: #976 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 09:34:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 09:34:49 -0000 Subject: [Varnish] #1023: If all idle clients stay idle, none of the idle connections are closed when they timeout. In-Reply-To: <045.39fa878ad93af23ad23dd0f71697689b@varnish-cache.org> References: <045.39fa878ad93af23ad23dd0f71697689b@varnish-cache.org> Message-ID: <054.dbd5c8849b287eb557ec9527888c1192@varnish-cache.org> #1023: If all idle clients stay idle, none of the idle connections are closed when they timeout. ----------------------+----------------------------------------------------- Reporter: drwilco | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [d5adf8877389d51455e2754d5fb21e24c9772e0e]) Fix poll waiter, so that we don't terminate the search for poll'ed fd's early in the case of a timeout. Fixes #1023 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 09:49:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 09:49:29 -0000 Subject: [Varnish] #1022: Mac OS X compilation error In-Reply-To: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> References: <044.cb1ae31d3a84ddf6b7b9a2b95c71d995@varnish-cache.org> Message-ID: <053.920e3fdd19bafca577f8a343f0a199a5@varnish-cache.org> #1022: Mac OS X compilation error ------------------------------+--------------------------------------------- Reporter: 191919 | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: blocker Resolution: fixed | Keywords: ------------------------------+--------------------------------------------- Comment(by andreacampi): Fair enough, I don't care that much either--just wanted to record it just in case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 20 20:46:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 20 Sep 2011 20:46:58 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <051.a4e58a8246a4026cba1fce9f807ba68f@varnish-cache.org> #1021: varnishtop -1 takes a long time to run --------------------+------------------------------------------------------- Reporter: yves | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Keywords: varnishlog --------------------+------------------------------------------------------- Comment(by scoof): Could you try with trunk or applying [e749a3ee4960ad05c3fc70901a472f2e75379b92], [2da67725c55a9aa1c7719048b5bb9642129f0dcf] and [223ff71a0ce19a7d33d3e06f800fa6e7b8a713e4] - they seem to have fixed it for me -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 21 11:43:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Sep 2011 11:43:06 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <041.5487abd822226eb0c5f8c76d815cb2c7@varnish-cache.org> References: <041.5487abd822226eb0c5f8c76d815cb2c7@varnish-cache.org> Message-ID: <050.7d2ea9ea156d55d601ce2c15cc6291cb@varnish-cache.org> #889: opensolaris build issue --------------------------+------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [c2e5ccb1325922975eeb2ee1dadaeb6c069e790e]) Look for ncurses/curses.h before curses.h Solaris puts the ncurses header in /usr/include/ncurses, and we need that to compile with -Werror. Fixes: #889 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 21 11:52:44 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Sep 2011 11:52:44 -0000 Subject: [Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris In-Reply-To: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> References: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> Message-ID: <053.f29e6fa6319a0a178034a4d563bb51e8@varnish-cache.org> #912: Vanish lacks the file_read privilege on recent OpenSolaris --------------------------+------------------------------------------------- Reporter: mamash | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: 2.1.5 Severity: major | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [e0ee2a2e69654a9df74aaf3dcadc9639659cf42b]) Add file_read to the privilege set we need on Solaris Fixes: #912 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 21 12:28:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Sep 2011 12:28:16 -0000 Subject: [Varnish] #994: Assert error in http_GetHdr(), cache_http.c In-Reply-To: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> References: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> Message-ID: <054.5647957f9a892f11c0153b690ce3bfa0@varnish-cache.org> #994: Assert error in http_GetHdr(), cache_http.c ----------------------+----------------------------------------------------- Reporter: pmialon | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: blocker Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Comment(by Tollef Fog Heen ): (In [ec3097a5d70b54fffe594cea7f3267ae7c56063b]) Reset the "built vary spec" (also) if we came back from the waiting list, otherwise it might turn into garbage. Fixes #994 Fixes #1001 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 21 12:28:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Sep 2011 12:28:16 -0000 Subject: [Varnish] #1001: Varnish 3.0.1 crashes in http_GetHdr In-Reply-To: <044.00b12aad07040946761903bc9a996310@varnish-cache.org> References: <044.00b12aad07040946761903bc9a996310@varnish-cache.org> Message-ID: <053.9484de6eb68876f849cca9f2a7a1e5c7@varnish-cache.org> #1001: Varnish 3.0.1 crashes in http_GetHdr ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.1 Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by Tollef Fog Heen ): (In [ec3097a5d70b54fffe594cea7f3267ae7c56063b]) Reset the "built vary spec" (also) if we came back from the waiting list, otherwise it might turn into garbage. Fixes #994 Fixes #1001 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 21 12:28:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Sep 2011 12:28:22 -0000 Subject: [Varnish] #1002: [PATCH] VCL doesn't like REAL comparisons. In-Reply-To: <045.259f64677bff8a462e3cc6171b0897cf@varnish-cache.org> References: <045.259f64677bff8a462e3cc6171b0897cf@varnish-cache.org> Message-ID: <054.4fc0f6edda7dfce1eee542f86eaca173@varnish-cache.org> #1002: [PATCH] VCL doesn't like REAL comparisons. ----------------------+----------------------------------------------------- Reporter: drwilco | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Comment(by Tollef Fog Heen ): (In [00101351cd05f444da422ddb770cc1cb11892287]) Allow relational comparisons on REAL type. Fixes #1002 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:04:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:04:20 -0000 Subject: [Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris In-Reply-To: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> References: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> Message-ID: <053.83214a6e0b5e6105c586a98fa9d619c7@varnish-cache.org> #912: Vanish lacks the file_read privilege on recent OpenSolaris --------------------------+------------------------------------------------- Reporter: mamash | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: 2.1.5 Severity: major | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Comment(by Tollef Fog Heen ): (In [00566769df8606de4bfeac6fac18986b93aaf168]) Add file_read to the privilege set we need on Solaris Fixes: #912 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:04:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:04:22 -0000 Subject: [Varnish] #889: opensolaris build issue In-Reply-To: <041.5487abd822226eb0c5f8c76d815cb2c7@varnish-cache.org> References: <041.5487abd822226eb0c5f8c76d815cb2c7@varnish-cache.org> Message-ID: <050.d1ceba73b7ee7b9f56dc9d1b720820b5@varnish-cache.org> #889: opensolaris build issue --------------------------+------------------------------------------------- Reporter: phk | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Comment(by Tollef Fog Heen ): (In [63ec044368d1a8a8a5b700c99e1c5ce4ea84bbbd]) Look for ncurses/curses.h before curses.h Solaris puts the ncurses header in /usr/include/ncurses, and we need that to compile with -Werror. Fixes: #889 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:04:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:04:54 -0000 Subject: [Varnish] #976: Updated zope-plone.vcl to Varnish 3.x In-Reply-To: <051.49a41b0505ba0bd338cd348b06bc79ef@varnish-cache.org> References: <051.49a41b0505ba0bd338cd348b06bc79ef@varnish-cache.org> Message-ID: <060.10255a8590edb6785f986af2253ea960@varnish-cache.org> #976: Updated zope-plone.vcl to Varnish 3.x ----------------------------+----------------------------------------------- Reporter: cleberjsantos | Type: enhancement Status: closed | Priority: normal Milestone: Later | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: update ----------------------------+----------------------------------------------- Comment(by Tollef Fog Heen ): (In [aab7c102985f497091f279562b28538d313cf034]) Update zope-plone.vcl to v3 syntax Thanks to cleberjsantos for initial patch which this is based on. Fixes: #976 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:11 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() In-Reply-To: <044.7522f73bc9b0434749db9996c97491e8@varnish-cache.org> References: <044.7522f73bc9b0434749db9996c97491e8@varnish-cache.org> Message-ID: <053.3536c72eb83cf2b100ffcb3680053f5b@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() ---------------------+------------------------------------------------------ Reporter: russki | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [192e6d06882d753212f81622faa43b1c6f975c26]) Commit the actual fix for #1014 and not just the test-case. Fixes #1014 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:20 -0000 Subject: [Varnish] #997: vcl(7) does not documents probe's expected_response or interval In-Reply-To: <043.0234fa8ffacb295d13c3e9d949e17a5b@varnish-cache.org> References: <043.0234fa8ffacb295d13c3e9d949e17a5b@varnish-cache.org> Message-ID: <052.c442ac53c4a7f8f65942bc9c418b6403@varnish-cache.org> #997: vcl(7) does not documents probe's expected_response or interval ---------------------+------------------------------------------------------ Reporter: fgsch | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [1a807636089475f0f0eaf50476fb3ded42bf355e]) Add .expected_response to probe documentation. Fix error message for .expected_response. Fixes #997 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:30 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:30 -0000 Subject: [Varnish] #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) In-Reply-To: <046.47a488f32ddf5ed310faf2c140cf208e@varnish-cache.org> References: <046.47a488f32ddf5ed310faf2c140cf208e@varnish-cache.org> Message-ID: <055.ff9ceba85af3a7086f1a4f0b5e53bfa7@varnish-cache.org> #1005: Varnish 503 FetchError c straight read_error: 0 0 (Success) -----------------------+---------------------------------------------------- Reporter: albertas | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by Tollef Fog Heen ): (In [513da1ed1ad1cfab1f2c28293e4372841eb35dc9]) Improve the FetchError VSL messages. Fixes #1005 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:18 -0000 Subject: [Varnish] #971: Broken DNS director In-Reply-To: <042.7193bdb45708359e86884cde11a7ddc1@varnish-cache.org> References: <042.7193bdb45708359e86884cde11a7ddc1@varnish-cache.org> Message-ID: <051.d545700081f77957bdfc861a63657110@varnish-cache.org> #971: Broken DNS director ----------------------+----------------------------------------------------- Reporter: rdvn | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by Tollef Fog Heen ): (In [9b1fea27154c30e314c859c58e2a1e0946de5c53]) Add type to connect_timeout References #971 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:06 -0000 Subject: [Varnish] #1011: --disable-jemalloc has changed to --without-jemalloc In-Reply-To: <041.b2bf8a2d8b2f22046a7f5650ac1a3604@varnish-cache.org> References: <041.b2bf8a2d8b2f22046a7f5650ac1a3604@varnish-cache.org> Message-ID: <050.aa00d989b6c6dc5a0cb511ffda2530fc@varnish-cache.org> #1011: --disable-jemalloc has changed to --without-jemalloc ---------------------+------------------------------------------------------ Reporter: pej | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [fc15a1cde13810cc87a69beb22f0ebd4e6b65944]) Updating configure line for ppc64, as --disabled-jemalloc has changed to --without-jemalloc Patch from P?l-Eivind Johnsen Fixes: #1011 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:10 -0000 Subject: [Varnish] #1014: Varnishd Panic Assert error in vfp_testgzip_end() In-Reply-To: <044.7522f73bc9b0434749db9996c97491e8@varnish-cache.org> References: <044.7522f73bc9b0434749db9996c97491e8@varnish-cache.org> Message-ID: <053.f6067678f9dbd536a58cda6c4334360c@varnish-cache.org> #1014: Varnishd Panic Assert error in vfp_testgzip_end() ---------------------+------------------------------------------------------ Reporter: russki | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [c59385938d80c6655fc31f774122d895c65d0c45]) Always call fetch- processor begin, also if C-L header is bogus. Fixes #1014 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:13 -0000 Subject: [Varnish] #993: 32-bit math somewhere in s_bodybytes In-Reply-To: <046.87661a65db1edf4eded622bf9ea785e4@varnish-cache.org> References: <046.87661a65db1edf4eded622bf9ea785e4@varnish-cache.org> Message-ID: <055.cc11343e5680c1f4c3eddb4440e77bb8@varnish-cache.org> #993: 32-bit math somewhere in s_bodybytes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by Tollef Fog Heen ): (In [b6fcb3de0f8fcdaedcf3151067d2aa3e8f59e575]) Avoid 32 bit variables in stats aggregation. Fixes #993 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:21 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> References: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> Message-ID: <055.633ebd5f42154de457e46c59341d9a66@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) -----------------------+---------------------------------------------------- Reporter: rzuidhof | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by Tollef Fog Heen ): (In [184ad943d98c64892734cca0144bed7198b5e688]) Restore old nuke_limit, as 10 seems to be too low Fixes #1012 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:05:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:05:16 -0000 Subject: [Varnish] #997: vcl(7) does not documents probe's expected_response or interval In-Reply-To: <043.0234fa8ffacb295d13c3e9d949e17a5b@varnish-cache.org> References: <043.0234fa8ffacb295d13c3e9d949e17a5b@varnish-cache.org> Message-ID: <052.9bf66e3bbd36862d1a57de87a50bd802@varnish-cache.org> #997: vcl(7) does not documents probe's expected_response or interval ---------------------+------------------------------------------------------ Reporter: fgsch | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [bb4163fb218445eeec60ac62b8ab70e1437aff40]) Tabulate probe properties and add all missing ones Really fixes #997 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 12:04:50 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 12:04:50 -0000 Subject: [Varnish] #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) In-Reply-To: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> References: <056.adeaef6b2a39507522e3da2385932a27@varnish-cache.org> Message-ID: <065.6159c41f7be3b36b3464bd5eb80fec8d@varnish-cache.org> #1016: Increase http_resp_hdr_len and http_req_hdr_len (again) --------------------------------+------------------------------------------- Reporter: christian.albrecht | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Comment(by Tollef Fog Heen ): (In [8a3745074a83a3dbfca9ff65f5bf22ef56fe220d]) Increase http_req_size, http_resp_size to 8192 bytes Apache (and nginx) uses 8k, so use the same default size to avoid people being surprised by more 413 responses than necessary. Fixes: #1016 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 18:37:54 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 18:37:54 -0000 Subject: [Varnish] #994: Assert error in http_GetHdr(), cache_http.c In-Reply-To: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> References: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> Message-ID: <054.63ed1a6def7e627a6e739afed4dd8004@varnish-cache.org> #994: Assert error in http_GetHdr(), cache_http.c ----------------------+----------------------------------------------------- Reporter: pmialon | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: blocker Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Comment(by dmp): I have a very similar problem - using Varnish 3.0.1 - same symptom (Assert error in http_GetHdr(), cache_http.c), and Vary header sent by the backend clearly responsible). I applied the patch from this ticket, but it doesn't fix it. I can reproduce the problem "reliably". Should I open a new ticket? Or provide more details here? Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 22 18:47:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Sep 2011 18:47:02 -0000 Subject: [Varnish] #994: Assert error in http_GetHdr(), cache_http.c In-Reply-To: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> References: <045.71b96b4371dbe05372be841d5da23e45@varnish-cache.org> Message-ID: <054.49c5a864c6f28658479fc28d3ac95d4d@varnish-cache.org> #994: Assert error in http_GetHdr(), cache_http.c ----------------------+----------------------------------------------------- Reporter: pmialon | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: blocker Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Comment(by dmp): Just tried latest from git and I can't reproduce the problem any longer. Please ignore my previous comment (I'll wait for 3.0.2). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 23 10:49:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 23 Sep 2011 10:49:45 -0000 Subject: [Varnish] #1015: varnishncsa frequently segfaults In-Reply-To: <044.7f34c08db42070969e1cca0520956dd6@varnish-cache.org> References: <044.7f34c08db42070969e1cca0520956dd6@varnish-cache.org> Message-ID: <053.a2486da83fb557f3b5529086008c35ad@varnish-cache.org> #1015: varnishncsa frequently segfaults --------------------+------------------------------------------------------- Reporter: russki | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by willthames): Bug is trivially reproducible using varnishncsa -F '%{Varnish:handling}x' I've created a patch for this bug (it seems to be because it looks for %{handling}x not %{Varnish:handling}x. I've also improved the error logging to help users resolve this issue The patch also improves the fix for #999 by allowing %>s as a format string (it's in lots of documentation) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 27 08:15:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Sep 2011 08:15:16 -0000 Subject: [Varnish] #1024: CLI connected to xxx.xxx.xxx.xxx:xxxx on STDERR Message-ID: <044.bb33e878fc0c60fcff326417119751e8@varnish-cache.org> #1024: CLI connected to xxx.xxx.xxx.xxx:xxxx on STDERR --------------------+------------------------------------------------------- Reporter: TrafeX | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishadm Version: 3.0.1 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Hello, Since version 3.0.0 varnishadm outputs the following message to STDERR: "CLI connected to xxx.xxx.xxx.xxx:xxxx" This looks to me like debug information, why is this outputted on STDERR? I would be nice if there's a way to turn this off. Regards, Tim de Pater -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 30 13:32:24 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Sep 2011 13:32:24 -0000 Subject: [Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris In-Reply-To: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> References: <044.46f714a5164bde9648092d83adfe21cb@varnish-cache.org> Message-ID: <053.77beb42ee3e9f8a85a1b075e025cd381@varnish-cache.org> #912: Vanish lacks the file_read privilege on recent OpenSolaris --------------------------+------------------------------------------------- Reporter: mamash | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: 2.1.5 Severity: major | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Comment(by Poul-Henning Kamp ): (In [f837fbca893cc09458482c5283456bf8990aeee6]) Split solaris sandboxing out to a separate source file, and apply patch received from Nils Goroll - [e0ee2a2e69654a9df74aaf3dcadc9639659cf42b] adds the file_read privilege needed for onnv_140 and newer (see #912), but we also need the file_write privilege for stevedore access. - If available, keep sys_resource in the permitted/limited set to allow cache_waiter_ports to raise the process.max-port-events resource control (feature to be added later). - When starting varnish with euid 0 on Solaris, privilege seperation prohibited preserving additional privileges (in excess of the basic set) in the child, because, for a non privilege aware process, setuid() resets the effective, inheritable and permitted sets to the basic set. To achieve interoperability between solaris privileges and setuid()/setgid(), we now make the varnish child privilege aware before calling setuid() by trying to add all privileges we will need plus proc_setid. - On solaris, check for proc_setid rather than checking the euid as a prerequisite for changing the uid/gid and only change the uid/gid if we need to (for a privilege aware process, [ers]uid 0 loose their magic powers). Note that setuid() will always set SNOCD on Solaris, which will prevent core dumps from being written, unless setuid core dumps are explicitly enabled using coreadm(1M). To avoid setuid() (and the SNOCD flag, consequently), start varnish as the user you intend to run the child as, but with additional privileges, e.g. using ppriv -e -s A=basic,net_privaddr,sys_resource varnishd ... - setppriv(PRIV_SET, ...) failed when the privileges to be applied were not available in the permitted set. We change the logic to only clear the privileges which are not needed by inverting the sets and removing all unneeded privileges using setppriv(PRIV_OFF, ...). So the child might end up with less privileges than given initially, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 30 15:43:01 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Sep 2011 15:43:01 -0000 Subject: [Varnish] #1025: varnishncsa gives continuous segfault. Message-ID: <054.5fafb649c6e723745a4efa31f34e6774@varnish-cache.org> #1025: varnishncsa gives continuous segfault. ------------------------------+--------------------------------------------- Reporter: jonathan.labanca | Type: defect Status: new | Priority: high Milestone: | Component: varnishncsa Version: 3.0.1 | Severity: major Keywords: | ------------------------------+--------------------------------------------- I was tested on several times by applying the latest patches available on the varnishncsa but in all cases a few seconds after starting the instance throws the same errors as those attached. If you need any additional reporting, please let me know. Sep 27 13:13:42 proxy1 kernel: varnishncsa[28683]: segfault at 0 ip 00007f9e34ba9f30 sp 00007fff3d6d6a48 error 4 in libc-2.7.so[7f9e34b2f000+153000] Sep 27 13:14:11 XXX kernel: varnishncsa[29561]: segfault at 0 ip 00007f9ab031bf30 sp 00007fffb8e48a48 error 4 in libc-2.7.so[7f9ab02a1000+153000] Sep 27 13:14:43 XXX kernel: varnishncsa[29632]: segfault at 0 ip 00007f58fc99df30 sp 00007fff054caa48 error 4 in libc-2.7.so[7f58fc923000+153000] Sep 27 13:15:43 XXX kernel: varnishncsa[29726]: segfault at 0 ip 00007f3691ab0f30 sp 00007fff9a5dda48 error 4 in libc-2.7.so[7f3691a36000+153000] Sep 27 13:16:11 XXX kernel: varnishncsa[29806]: segfault at 0 ip 00007fb76b0d2f30 sp 00007fff73bffa48 error 4 in libc-2.7.so[7fb76b058000+153000] -- Ticket URL: Varnish The Varnish HTTP Accelerator