From varnish-bugs at varnish-cache.org Mon Jun 2 10:12:36 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 10:12:36 -0000 Subject: [Varnish] #1516: vcl example fixup vary In-Reply-To: <041.7fb26af8baff66cc8070b6fcf8c5b93f@varnish-cache.org> References: <041.7fb26af8baff66cc8070b6fcf8c5b93f@varnish-cache.org> Message-ID: <056.29afbdc6e1a6d81b2dd8072ce554988e@varnish-cache.org> #1516: vcl example fixup vary ---------------------------+----------------------- Reporter: dbu | Owner: lkarsten Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 10:30:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 10:30:45 -0000 Subject: [Varnish] #1517: HTTPS Redirects In-Reply-To: <051.0f52524c4a4d7a95edfd419cba0e2b07@varnish-cache.org> References: <051.0f52524c4a4d7a95edfd419cba0e2b07@varnish-cache.org> Message-ID: <066.053978e8a1f4e58d75ebd5202afc578d@varnish-cache.org> #1517: HTTPS Redirects ---------------------------+---------------------------------- Reporter: shredtechular | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: documentation | Version: 4.0.0 Severity: normal | Resolution: invalid Keywords: | ---------------------------+---------------------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: Closing at the request of the reporter. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 10:32:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 10:32:24 -0000 Subject: [Varnish] #1327: Crash if http_max_hdr is not multiple of 4 In-Reply-To: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> References: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> Message-ID: <058.93602ebe3baad55273f17ce90d0a2926@varnish-cache.org> #1327: Crash if http_max_hdr is not multiple of 4 ----------------------+------------------------- Reporter: Dan42 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Comment (by perbu): It is worth noting that this bug is still present in the 3.0 series. The work-around is pretty obvious, always use multiples of 4 for http_max_hdr. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 11:14:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 11:14:45 -0000 Subject: [Varnish] #1327: Crash if http_max_hdr is not multiple of 4 In-Reply-To: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> References: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> Message-ID: <058.d97d77213d39fd75aa72afcfcd9f2b89@varnish-cache.org> #1327: Crash if http_max_hdr is not multiple of 4 ----------------------+----------------------------------------------- Reporter: Dan42 | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * resolution: worksforme => fixed Comment: In [1b6cc9d28eb3741292d8b87c033c08f1590dd166]: {{{ #!CommitTicketReference repository="" revision="1b6cc9d28eb3741292d8b87c033c08f1590dd166" Fix v-c.o bug 1327 (http_max_hdr not multiple of 4) also for 3.0 Round up the header space with PRNDUP in session space allocation to fix alignment issue. Fixes: #1327 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 12:50:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 12:50:53 -0000 Subject: [Varnish] #1512: Changes to bereq are lost between v_b_r and v_b_f In-Reply-To: <043.04a15d59ba73f8274523e0e9150e84a7@varnish-cache.org> References: <043.04a15d59ba73f8274523e0e9150e84a7@varnish-cache.org> Message-ID: <058.38a21ac54d06bc5698433f876c207b09@varnish-cache.org> #1512: Changes to bereq are lost between v_b_r and v_b_f --------------------+-------------------- Reporter: fgsch | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by phk): * owner: => phk Comment: We should make this parallel to client-side restart. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 12:51:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 12:51:57 -0000 Subject: [Varnish] #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon In-Reply-To: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> References: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> Message-ID: <058.e9e350918a3c6350b8fce92816c306e5@varnish-cache.org> #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon --------------------+-------------------- Reporter: fgsch | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by phk): * owner: => phk Comment: Abandon does that, the fetch object ceases to exist and there is no communication to vcl_synth{}. We should (probably) be able to return(error) in v_b_f and v_b_r for this case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 12:52:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 12:52:15 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.c34bd112134e8d20db1e23add2a1d35d@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 14:02:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 14:02:26 -0000 Subject: [Varnish] #1514: Documentation update In-Reply-To: <049.ba7f49e64c3a6f17f160c2febdc52f39@varnish-cache.org> References: <049.ba7f49e64c3a6f17f160c2febdc52f39@varnish-cache.org> Message-ID: <064.e34f1f2ac537159586d4755a3e5fb774@varnish-cache.org> #1514: Documentation update ---------------------------+----------------------------------------------- Reporter: neverexists | Owner: Martin Blix Grydeland Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ---------------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [aadf302e4b7d856070dbf92ab1e7a6571003812d]: {{{ #!CommitTicketReference repository="" revision="aadf302e4b7d856070dbf92ab1e7a6571003812d" Document the storage..* VCL variables. Fixes: #1514 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 14:02:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 14:02:34 -0000 Subject: [Varnish] #1514: Documentation update In-Reply-To: <049.ba7f49e64c3a6f17f160c2febdc52f39@varnish-cache.org> References: <049.ba7f49e64c3a6f17f160c2febdc52f39@varnish-cache.org> Message-ID: <064.3133ec1d982eaff129a22b19e51b0c7e@varnish-cache.org> #1514: Documentation update ---------------------------+----------------------------------------------- Reporter: neverexists | Owner: Martin Blix Grydeland Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ---------------------------+----------------------------------------------- Comment (by Martin Blix Grydeland ): In [73efe8191aa764e3084d2a2bd738a60d7af964bc]: {{{ #!CommitTicketReference repository="" revision="73efe8191aa764e3084d2a2bd738a60d7af964bc" Document the storage..* VCL variables. Fixes: #1514 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 2 20:31:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jun 2014 20:31:27 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.a36200f7f6b17898ac86d956e91f8377@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Description changed by phk: Old description: > Assert error in HTTP1_Write(), cache/cache_http1_proto.c line 518: > Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. > thread = (cache-worker) > ident = > Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x43a756: pan_backtrace+0x19 > 0x43aa66: pan_ic+0x1e8 > 0x435dd3: HTTP1_Write+0xa6 > 0x44275e: V1D_Deliver+0x630 > 0x43dad2: cnt_deliver+0x75d > 0x440e0a: CNT_Request+0x529 > 0x433915: HTTP1_Session+0x429 > 0x443d5f: ses_req_pool_task+0x166 > 0x44402a: ses_sess_pool_task+0x23b > 0x4445d6: SES_pool_accept_task+0x1f9 New description: {{{ Assert error in HTTP1_Write(), cache/cache_http1_proto.c line 518: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43a756: pan_backtrace+0x19 0x43aa66: pan_ic+0x1e8 0x435dd3: HTTP1_Write+0xa6 0x44275e: V1D_Deliver+0x630 0x43dad2: cnt_deliver+0x75d 0x440e0a: CNT_Request+0x529 0x433915: HTTP1_Session+0x429 0x443d5f: ses_req_pool_task+0x166 0x44402a: ses_sess_pool_task+0x23b 0x4445d6: SES_pool_accept_task+0x1f9 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 3 08:20:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Jun 2014 08:20:24 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.82e9953e3a39fd343d138dafaea2f1ae@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by phk): Looking at this, I don't think workspace_thread is the one you should tweak, try workspace_client instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 3 08:22:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Jun 2014 08:22:28 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.e8c0ff4645acae2b58522fa38df6e987@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by g.gerritsen): Replying to [comment:4 phk]: Ok, I will test with a bigger workspace_client (128k) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 3 09:19:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Jun 2014 09:19:26 -0000 Subject: [Varnish] #1516: vcl example fixup vary In-Reply-To: <041.7fb26af8baff66cc8070b6fcf8c5b93f@varnish-cache.org> References: <041.7fb26af8baff66cc8070b6fcf8c5b93f@varnish-cache.org> Message-ID: <056.22c9421a1423419f5f56c9d2dfd5ba76@varnish-cache.org> #1516: vcl example fixup vary ---------------------------+----------------------- Reporter: dbu | Owner: lkarsten Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | ---------------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: I've updated the page with an example for 4.0 now. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 6 12:28:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 Jun 2014 12:28:34 -0000 Subject: [Varnish] #1518: Varnish sends body on 304 when ESI is on. Message-ID: <046.6756ef55d866ca26eb620d2e4852d173@varnish-cache.org> #1518: Varnish sends body on 304 when ESI is on. ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- When conditionally requesting an ESI resource from Varnish, a 304 Not Modified response with a body is returned. Expected result: 304 response with empty response body, per the RFC. Verified on 4.0.0 and current git master (b356206). Test case attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 9 08:53:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jun 2014 08:53:52 -0000 Subject: [Varnish] #1519: round robin director does not support weight Message-ID: <043.17a4a524378f3ddac4efab7a9efe4bb8@varnish-cache.org> #1519: round robin director does not support weight --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- In V4 weight is not supported (fixed to 0.0). Documentation in vmod.vcc suggests it should be available. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 9 14:37:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jun 2014 14:37:41 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 Message-ID: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> #1520: m00011.vtc fails on x86_64 ----------------------+------------------------- Reporter: yoloseem | Type: defect Status: new | Priority: normal Milestone: | Component: varnishtest Version: 4.0.0 | Severity: normal Keywords: | ----------------------+------------------------- Varnish 4.0.0 does not compile on x86_6/OS X 10.9.3, the m00011.vtc test fails : {{{ $ varnishtest bin/varnishtest/tests/m00011.vtc **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std **** top 0.0 macro def vmod_debug=debug **** top 0.0 macro def vmod_directors=directors **** top 0.0 macro def pwd=/Users/yoloseem/Dropbox/works/varnish-4.0.0 **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/var/folders/x_/35t1c_0n12d9xs1t83tp4grw0000gn/T//vtc.87569.2123a94f * top 0.0 TEST bin/varnishtest/tests/m00011.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Test std.ip *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=58591 **** s1 0.0 macro def s1_sock=127.0.0.1 58591 * s1 0.0 Listen on 127.0.0.1 58591 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 58591 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /var/folders/x_/35t1c_0n12d9xs1t83tp4grw0000gn/T//vtc.87569.2123a94f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 58592' -P /var/folders/x_/35t1c_0n12d9xs1t83tp4grw0000gn/T//vtc.87569.2123a94f/v1/varnishd.pid *** v1 0.0 CMD: cd /Users/yoloseem/Dropbox/works/varnish-4.0.0 && varnishd -d -d -n /var/folders/x_/35t1c_0n12d9xs1t83tp4grw0000gn/T//vtc.87569.2123a94f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 58592' -P /var/folders/x_/35t1c_0n12d9xs1t83tp4grw0000gn/T//vtc.87569.2123a94f/v1/varnishd.pid *** v1 0.0 PID: 87574 *** v1 0.0 debug| Platform: Darwin,13.2.0,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 266 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Darwin,13.2.0,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.0 revision 2acedeb\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 8 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| zhlrbwasavvyeeeeymhleoinkzgkxjay\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth a6f9cb0852c99143ed36b8f2f9fcd611aa5063690564f88c3c10da2fc377fbe2\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Darwin,13.2.0,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.0 revision 2acedeb\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| vcl 4.0;\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "58591"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| import std;\n **** v1 0.1 CLI TX| sub vcl_deliver {\n **** v1 0.1 CLI TX| set resp.http.foo0 = std.ip("8.8.8.*", client.ip);\n **** v1 0.1 CLI TX| set resp.http.foo1 = std.ip("9.9.9.*", server.ip);\n **** v1 0.1 CLI TX| set resp.http.foo2 = std.ip("1.2.3.*", "127.0.0.2");\n **** v1 0.1 CLI TX| set resp.http.foo3 = std.ip("1.2.3.5", "127.0.0.3");\n **** v1 0.1 CLI TX| }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| Message from VCC-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from C-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from dlopen:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| VCL compiled. **** v1 0.2 CLI TX| vcl.use vcl1 *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| VCL 'vcl1' now active ** v1 0.2 Start **** v1 0.2 CLI TX| start *** v1 0.2 debug| child (87584) Started\n *** v1 0.2 CLI RX 200 *** v1 0.2 debug| Child (87584) said Not running as root, no priv- sep\n *** v1 0.2 wait-running **** v1 0.2 CLI TX| status *** v1 0.2 debug| Child (87584) said Child starts\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| Child in state running **** v1 0.2 CLI TX| debug.xid 999 *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| XID is 999 **** v1 0.2 CLI TX| debug.listen_address *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| 127.0.0.1 58597\n ** v1 0.2 Listen on 127.0.0.1 58597 **** v1 0.2 macro def v1_addr=127.0.0.1 **** v1 0.2 macro def v1_port=58597 **** v1 0.2 macro def v1_sock=127.0.0.1 58597 *** top 0.2 client ** c1 0.2 Starting client ** c1 0.2 Waiting for client *** c1 0.2 Connect to 127.0.0.1 58597 *** c1 0.2 connected fd 9 from 127.0.0.1 58598 to 127.0.0.1 58597 *** c1 0.2 txreq **** c1 0.2 txreq| GET /foo1 HTTP/1.1\r\n **** c1 0.2 txreq| \r\n *** c1 0.2 rxresp *** s1 0.3 accepted fd 10 *** s1 0.3 rxreq **** s1 0.3 rxhdr| GET /foo1 HTTP/1.1\r\n **** s1 0.3 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 0.3 rxhdr| Accept-Encoding: gzip\r\n **** s1 0.3 rxhdr| X-Varnish: 1002\r\n **** s1 0.3 rxhdr| Host: 127.0.0.1\r\n **** s1 0.3 rxhdr| \r\n **** s1 0.3 http[ 0] | GET **** s1 0.3 http[ 1] | /foo1 **** s1 0.3 http[ 2] | HTTP/1.1 **** s1 0.3 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 0.3 http[ 4] | Accept-Encoding: gzip **** s1 0.3 http[ 5] | X-Varnish: 1002 **** s1 0.3 http[ 6] | Host: 127.0.0.1 **** s1 0.3 bodylen = 0 *** s1 0.3 txresp **** s1 0.3 txresp| HTTP/1.1 200 Ok\r\n **** s1 0.3 txresp| Content-Length: 1\r\n **** s1 0.3 txresp| \r\n **** s1 0.3 txresp| 1 *** s1 0.3 shutting fd 10 ** s1 0.3 Ending ---- c1 0.3 HTTP rx EOF (fd:9 read: Undefined error: 0) * top 0.3 RESETTING after bin/varnishtest/tests/m00011.vtc ** s1 0.3 Waiting for server **** s1 0.3 macro undef s1_addr **** s1 0.3 macro undef s1_port **** s1 0.3 macro undef s1_sock **** v1 0.3 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.3 vsl| 1000 SessOpen c 127.0.0.1 58598 127.0.0.1:0 127.0.0.1 58597 1402324058.106455 6 **** v1 0.3 vsl| 1000 Link c req 1001 rxreq **** v1 0.3 vsl| 1002 Begin b bereq 1001 fetch **** v1 0.3 vsl| 1002 Timestamp b Start: 1402324058.107015 0.000000 0.000000 **** v1 0.3 vsl| 1002 BereqMethod b GET **** v1 0.3 vsl| 1002 BereqURL b /foo1 **** v1 0.3 vsl| 1002 BereqProtocol b HTTP/1.1 **** v1 0.3 vsl| 1002 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.3 vsl| 1002 BereqHeader b Accept-Encoding: gzip **** v1 0.3 vsl| 1002 BereqHeader b X-Varnish: 1002 **** v1 0.3 vsl| 1002 VCL_call b BACKEND_FETCH **** v1 0.3 vsl| 1002 VCL_return b fetch **** v1 0.3 vsl| 1002 BackendOpen b 7 s1(127.0.0.1,,58591) 127.0.0.1 58599 **** v1 0.3 vsl| 1002 Backend b 7 s1 s1(127.0.0.1,,58591) **** v1 0.3 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.3 vsl| 1002 Timestamp b Bereq: 1402324058.107317 0.000302 0.000302 **** v1 0.3 vsl| 1002 Timestamp b Beresp: 1402324058.107758 0.000743 0.000441 **** v1 0.3 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.3 vsl| 1002 BerespStatus b 200 **** v1 0.3 vsl| 1002 BerespResponse b Ok **** v1 0.3 vsl| 1002 BerespHeader b Content-Length: 1 **** v1 0.3 vsl| 1002 TTL b RFC 120 -1 -1 1402324058 1402324058 0 0 0 **** v1 0.3 vsl| 1002 VCL_call b BACKEND_RESPONSE **** v1 0.3 vsl| 1002 VCL_return b deliver **** v1 0.3 vsl| 1002 Storage b malloc s0 **** v1 0.3 vsl| 1002 ObjProtocol b HTTP/1.1 **** v1 0.3 vsl| 1002 ObjStatus b 200 **** v1 0.3 vsl| 1002 ObjResponse b Ok **** v1 0.3 vsl| 1002 Fetch_Body b 3 length stream **** v1 0.3 vsl| 1002 Timestamp b BerespBody: 1402324058.107860 0.000845 0.000102 **** v1 0.3 vsl| 1002 BackendReuse b 7 s1(127.0.0.1,,58591) **** v1 0.3 vsl| 0 ExpKill - EXP_Inbox p=0x7fea0bf00990 e=0.000000000 f=0x0 **** v1 0.3 vsl| 0 ExpKill - EXP_When p=0x7fea0bf00990 e=1402324188.106722116 f=0x1c10 **** v1 0.3 vsl| 1002 Length b 1 **** v1 0.3 vsl| 1002 BereqAcct b 107 0 107 38 1 39 **** v1 0.3 vsl| 1002 End b **** v1 0.3 vsl| 1001 Begin c req 1000 rxreq **** v1 0.3 vsl| 1001 Timestamp c Start: 1402324058.106722 0.000000 0.000000 **** v1 0.3 vsl| 1001 Timestamp c Req: 1402324058.106722 0.000000 0.000000 **** v1 0.3 vsl| 1001 ReqStart c 127.0.0.1 58598 **** v1 0.3 vsl| 1001 ReqMethod c GET **** v1 0.3 vsl| 1001 ReqURL c /foo1 **** v1 0.3 vsl| 1001 ReqProtocol c HTTP/1.1 **** v1 0.3 vsl| 1001 ReqHeader c X-Forwarded-For: 127.0.0.1 **** v1 0.3 vsl| 1001 VCL_call c RECV **** v1 0.3 vsl| 1001 VCL_return c hash **** v1 0.3 vsl| 1001 VCL_call c HASH **** v1 0.3 vsl| 1001 VCL_return c lookup **** v1 0.3 vsl| 1001 Debug c XXXX MISS **** v1 0.3 vsl| 1001 VCL_call c MISS **** v1 0.3 vsl| 1001 VCL_return c fetch **** v1 0.3 vsl| 1001 Link c bereq 1002 fetch **** v1 0.3 vsl| 1001 Timestamp c Fetch: 1402324058.107850 0.001128 0.001128 **** v1 0.3 vsl| 1001 Timestamp c Process: 1402324058.107860 0.001138 0.000010 **** v1 0.3 vsl| 1001 RespProtocol c HTTP/1.1 **** v1 0.3 vsl| 1001 RespStatus c 200 **** v1 0.3 vsl| 1001 RespResponse c Ok **** v1 0.3 vsl| 1001 RespHeader c Date: Mon, 09 Jun 2014 14:27:38 GMT **** v1 0.3 vsl| 1001 RespHeader c X-Varnish: 1001 **** v1 0.3 vsl| 1001 RespHeader c Age: 0 **** v1 0.3 vsl| 1001 RespHeader c Via: 1.1 varnish (v4) **** v1 0.3 vsl| 1001 VCL_call c DELIVER **** v1 0.3 vsl| 1001 RespHeader c foo0: 127.0.0.1 **** v1 0.3 vsl| 1001 RespHeader c foo1: 127.0.0.1 **** v1 0.3 vsl| 1001 RespHeader c foo2: 127.0.0.2 **** v1 0.3 vsl| 1001 RespHeader c foo3: 1.2.3.5 **** v1 0.3 vsl| 1001 VCL_return c deliver **** v1 0.3 vsl| 1001 RespHeader c Content-Length: 1 **** v1 0.3 vsl| 1001 Debug c RES_MODE 2 **** v1 0.3 vsl| 1001 RespHeader c Connection: keep-alive **** v1 0.3 vsl| 1001 RespHeader c Accept-Ranges: bytes **** v1 0.3 vsl| 1001 Timestamp c Resp: 1402324058.108992 0.002270 0.001132 **** v1 0.3 vsl| 1001 Debug c XXX REF 2 **** v1 0.3 vsl| 1001 ReqAcct c 22 0 22 235 1 236 **** v1 0.3 vsl| 1001 End c **** v1 0.3 vsl| 0 ReqAcct - 0 0 0 0 0 0 **** v1 0.3 vsl| 1000 SessClose c REM_CLOSE 0.003 **** v1 0.3 vsl| 1000 End c ** v1 1.3 Wait **** v1 1.3 vsl| 0 CLI - EOF on CLI connection, worker stops **** v1 2.3 STDOUT poll 0x11 ** v1 2.3 R 87574 Status: 0000 (u 0.062789 s 0.052513) * top 2.3 TEST bin/varnishtest/tests/m00011.vtc FAILED # top TEST bin/varnishtest/tests/m00011.vtc FAILED (2.313) exit=1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 9 15:57:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jun 2014 15:57:54 -0000 Subject: [Varnish] #1521: Varnish 4 VCL compilation failed on x86_64 Message-ID: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> #1521: Varnish 4 VCL compilation failed on x86_64 ----------------------+-------------------- Reporter: yoloseem | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.0 | Severity: normal Keywords: | ----------------------+-------------------- Varnish 4.0.0 failed to start with log "VCL compilation failed" on x86_64 platform/OS X 10.9.3. {{{ yoloseem:~/works/web $ sudo varnishd -F -t 0 -f config/varnish.vcl Message from C-compiler: ld: can't open output file for writing './vcl.PjejeYgI.so.ld_HJoDqU', errno=13 for architecture x86_64 clang: error: unable to remove file: Permission denied clang: error: linker command failed with exit code 1 (use -v to see invocation) Running C-compiler failed, exit 1 VCL compilation failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 09:42:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 09:42:52 -0000 Subject: [Varnish] #1521: Varnish 4 VCL compilation failed on x86_64 In-Reply-To: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> References: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> Message-ID: <061.591108b4deae665936c658a3d38ce994@varnish-cache.org> #1521: Varnish 4 VCL compilation failed on x86_64 ----------------------+-------------------- Reporter: yoloseem | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Can you please start varnishd under strace/truss/dtruss and get a system call listing. That should allow us to see where in the privdrop-sequence we take a wrong turn. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 09:43:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 09:43:04 -0000 Subject: [Varnish] #1521: Varnish 4 VCL compilation failed on x86_64 In-Reply-To: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> References: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> Message-ID: <061.32054c8306e25355770b4d09b12d6eb9@varnish-cache.org> #1521: Varnish 4 VCL compilation failed on x86_64 ----------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Changes (by lkarsten): * status: new => Need info -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 09:44:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 09:44:59 -0000 Subject: [Varnish] #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: In-Reply-To: <046.4f5b81be0598ee1826ee59e3c9b23187@varnish-cache.org> References: <046.4f5b81be0598ee1826ee59e3c9b23187@varnish-cache.org> Message-ID: <061.b032aa63b36d11632e327f4937ad3c40@varnish-cache.org> #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: ----------------------+------------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by lkarsten): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 10:08:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 10:08:23 -0000 Subject: [Varnish] #1518: Varnish sends body on 304 when ESI is on. In-Reply-To: <046.6756ef55d866ca26eb620d2e4852d173@varnish-cache.org> References: <046.6756ef55d866ca26eb620d2e4852d173@varnish-cache.org> Message-ID: <061.6329e4f81f5207e4dd46357575ba4280@varnish-cache.org> #1518: Varnish sends body on 304 when ESI is on. ----------------------+-------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 10:10:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 10:10:19 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.328e54376a827ce8568f506d377dcf74@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Changes (by lkarsten): * status: new => Need info Comment: We currently don't have build infrastructure for 64bit OSX. Our i386 slave runs the test suite fine, see jenkins.varnish-cache.org. OSX isn't a primary platform for us, but nevertheless it would be good to understand why this is happening. Can you confirm that this is happening every time you run this test set? Are the remaining tests passing? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 10:12:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 10:12:45 -0000 Subject: [Varnish] #1519: round robin director does not support weight In-Reply-To: <043.17a4a524378f3ddac4efab7a9efe4bb8@varnish-cache.org> References: <043.17a4a524378f3ddac4efab7a9efe4bb8@varnish-cache.org> Message-ID: <058.1a8c5673e937e9bf6201094d7f8afa87@varnish-cache.org> #1519: round robin director does not support weight --------------------+------------------------------------------ Reporter: fgsch | Owner: Dag Haavi Finstad Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------ Changes (by Dag Haavi Finstad ): * owner: => Dag Haavi Finstad * status: new => closed * resolution: => fixed Comment: In [8a1a59ab1547366bae942c087eef974aaba6fb5e]: {{{ #!CommitTicketReference repository="" revision="8a1a59ab1547366bae942c087eef974aaba6fb5e" Docfix an erroneous reference to r-r director having weight. Fixes: #1519 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 10:20:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 10:20:27 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true Message-ID: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ---------------------------------+---------------------- Reporter: Jay | Type: defect Status: new | Priority: high Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: major Keywords: | ---------------------------------+---------------------- I found an existing and solved ticket regarding line 417, but not line 416 Panic message: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.10.40,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4321f5: pan_ic+0xc5 0x4352ae: cnt_lookup+0x94e 0x435ba1: CNT_Request+0x831 0x42cccb: HTTP1_Session+0x7cb 0x439aa8: ses_req_pool_task+0x68 0x434679: Pool_Work_Thread+0xa9 0x44725e: wrk_thread_real+0xae 0x7fbbbd05b1db: /usr/app/glibc/current/lib/libpthread.so.0(+0x81db) [0x7fbbbd05b1db] 0x7fbbbcd90d4d: /usr/app/glibc/current/lib/libc.so.6(clone+0x6d) [0x7fbbbcd90d4d] req = 0x7fbba6597520 { sp = 0x7fbbac558c50, vxid = 1077334200, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fbbac558c50 { fd = 3312, vxid = 3592375, client = x.x.x.x 42129, step = S_STP_WORKING, }, worker = 0x7fbb74864c70 { ws = 0x7fbb74864e80 { -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 11:16:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 11:16:03 -0000 Subject: [Varnish] #1518: Varnish sends body on 304 when ESI is on. In-Reply-To: <046.6756ef55d866ca26eb620d2e4852d173@varnish-cache.org> References: <046.6756ef55d866ca26eb620d2e4852d173@varnish-cache.org> Message-ID: <061.b5c4d901e986331c95190bf5d22830da@varnish-cache.org> #1518: Varnish sends body on 304 when ESI is on. ----------------------+--------------------- Reporter: lkarsten | Owner: phk 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 [8061a7c804be67b2b93bf8d7b6de7f5988452c48]: {{{ #!CommitTicketReference repository="" revision="8061a7c804be67b2b93bf8d7b6de7f5988452c48" Rememeber to supress body if we do 304 conditional response. Fixes #1518 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 11:18:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 11:18:28 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.cb98a666e419af5302a081d0358766af@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: Keywords: | ----------------------+---------------------------------- Description changed by lkarsten: Old description: > I found an existing and solved ticket regarding line 417, but not line > 416 > > Panic message: Assert error in cnt_lookup(), cache/cache_req_fsm.c line > 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 > (Connection reset by peer) thread = (cache-worker) ident = > Linux,3.10.40,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: > 0x4321f5: pan_ic+0xc5 0x4352ae: cnt_lookup+0x94e 0x435ba1: > CNT_Request+0x831 0x42cccb: HTTP1_Session+0x7cb 0x439aa8: > ses_req_pool_task+0x68 0x434679: Pool_Work_Thread+0xa9 0x44725e: > wrk_thread_real+0xae 0x7fbbbd05b1db: > /usr/app/glibc/current/lib/libpthread.so.0(+0x81db) [0x7fbbbd05b1db] > 0x7fbbbcd90d4d: /usr/app/glibc/current/lib/libc.so.6(clone+0x6d) > [0x7fbbbcd90d4d] req = 0x7fbba6597520 { sp = 0x7fbbac558c50, vxid = > 1077334200, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = > 0, esi_level = 0 sp = 0x7fbbac558c50 { fd = 3312, vxid = 3592375, > client = x.x.x.x 42129, step = S_STP_WORKING, }, worker = > 0x7fbb74864c70 { ws = 0x7fbb74864e80 { New description: I found an existing and solved ticket regarding line 417, but not line 416 Panic message: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.10.40,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4321f5: pan_ic+0xc5 0x4352ae: cnt_lookup+0x94e 0x435ba1: CNT_Request+0x831 0x42cccb: HTTP1_Session+0x7cb 0x439aa8: ses_req_pool_task+0x68 0x434679: Pool_Work_Thread+0xa9 0x44725e: wrk_thread_real+0xae 0x7fbbbd05b1db: /usr/app/glibc/current/lib/libpthread.so.0(+0x81db) [0x7fbbbd05b1db] 0x7fbbbcd90d4d: /usr/app/glibc/current/lib/libc.so.6(clone+0x6d) [0x7fbbbcd90d4d] req = 0x7fbba6597520 { sp = 0x7fbbac558c50, vxid = 1077334200, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fbbac558c50 { fd = 3312, vxid = 3592375, client = x.x.x.x 42129, step = S_STP_WORKING, }, worker = 0x7fbb74864c70 { ws = 0x7fbb74864e80 { }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 10 11:18:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jun 2014 11:18:38 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.902785fd2435b8ebedc75bf536ac27c4@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: Keywords: | ----------------------+---------------------------------- Description changed by lkarsten: Old description: > I found an existing and solved ticket regarding line 417, but not line > 416 > > Panic message: Assert error in cnt_lookup(), cache/cache_req_fsm.c line > 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 > (Connection reset by peer) > thread = (cache-worker) > ident = Linux,3.10.40,x86_64,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x4321f5: pan_ic+0xc5 > 0x4352ae: cnt_lookup+0x94e > 0x435ba1: CNT_Request+0x831 > 0x42cccb: HTTP1_Session+0x7cb > 0x439aa8: ses_req_pool_task+0x68 > 0x434679: Pool_Work_Thread+0xa9 > 0x44725e: wrk_thread_real+0xae > 0x7fbbbd05b1db: /usr/app/glibc/current/lib/libpthread.so.0(+0x81db) > [0x7fbbbd05b1db] > 0x7fbbbcd90d4d: /usr/app/glibc/current/lib/libc.so.6(clone+0x6d) > [0x7fbbbcd90d4d] > req = 0x7fbba6597520 { > sp = 0x7fbbac558c50, vxid = 1077334200, > step = R_STP_LOOKUP, > req_body = R_BODY_NONE, > restarts = 0, esi_level = 0 > sp = 0x7fbbac558c50 { > fd = 3312, vxid = 3592375, > client = x.x.x.x 42129, > step = S_STP_WORKING, > }, > worker = 0x7fbb74864c70 { > ws = 0x7fbb74864e80 { > }}} New description: I found an existing and solved ticket regarding line 417, but not line 416 {{{ Panic message: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.10.40,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4321f5: pan_ic+0xc5 0x4352ae: cnt_lookup+0x94e 0x435ba1: CNT_Request+0x831 0x42cccb: HTTP1_Session+0x7cb 0x439aa8: ses_req_pool_task+0x68 0x434679: Pool_Work_Thread+0xa9 0x44725e: wrk_thread_real+0xae 0x7fbbbd05b1db: /usr/app/glibc/current/lib/libpthread.so.0(+0x81db) [0x7fbbbd05b1db] 0x7fbbbcd90d4d: /usr/app/glibc/current/lib/libc.so.6(clone+0x6d) [0x7fbbbcd90d4d] req = 0x7fbba6597520 { sp = 0x7fbbac558c50, vxid = 1077334200, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fbbac558c50 { fd = 3312, vxid = 3592375, client = x.x.x.x 42129, step = S_STP_WORKING, }, worker = 0x7fbb74864c70 { ws = 0x7fbb74864e80 { }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 11 02:41:05 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jun 2014 02:41:05 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.8904d87ec9e5f6948d079b897ea9603c@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Comment (by yoloseem): Yes. All test suites excepting m00011.vtc pass well and m00011.vtc always fails. Since the test contains below: {{{ varnishtest "Test std.ip" server s1 { rxreq txresp -body "1" } -start varnish v1 -vcl+backend { import ${vmod_std}; sub vcl_deliver { set resp.http.foo0 = std.ip("8.8.8.*", client.ip); set resp.http.foo1 = std.ip("9.9.9.*", server.ip); set resp.http.foo2 = std.ip("1.2.3.*", "127.0.0.2"); set resp.http.foo3 = std.ip("1.2.3.5", "127.0.0.3"); } } -start client c1 { txreq -url "/foo1" rxresp expect resp.http.foo0 == "127.0.0.1" expect resp.http.foo1 == "127.0.0.1" expect resp.http.foo2 == "127.0.0.2" expect resp.http.foo3 == "1.2.3.5" } -run }}} If I left only a line about foo3, then it passes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 11 02:47:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jun 2014 02:47:17 -0000 Subject: [Varnish] #1521: Varnish 4 VCL compilation failed on x86_64 In-Reply-To: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> References: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> Message-ID: <061.232b3410ed7653f04c22996b7d8f639d@varnish-cache.org> #1521: Varnish 4 VCL compilation failed on x86_64 ----------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+------------------------ Comment (by yoloseem): Attached dtruss output via below command: {{{ $ sudo dtruss varnishd -F -t 0 -f config/varnish.vcl &> varnish-dtruss }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 11 04:06:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jun 2014 04:06:43 -0000 Subject: [Varnish] #1523: r00878.vtc fails on x86_64/Ubuntu 14.04 Trusty Message-ID: <046.c17f70a91acf661f421ad5bc4dbe3377@varnish-cache.org> #1523: r00878.vtc fails on x86_64/Ubuntu 14.04 Trusty ----------------------+------------------------- Reporter: yoloseem | Type: defect Status: new | Priority: normal Milestone: | Component: varnishtest Version: 4.0.0 | Severity: normal Keywords: | ----------------------+------------------------- r00878.vtc fails on x86_64/Ubuntu 14.04 Trusty. It seems that libvmod_debug does not built. {{{ $ varnishtest bin/varnishtest/tests/r00878.vtc **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std **** top 0.0 macro def vmod_debug=debug **** top 0.0 macro def vmod_directors=directors **** top 0.0 macro def pwd=/home/ubuntu/varnish-4.0.0 **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/tmp/vtc.23730.37d04a9d * top 0.0 TEST bin/varnishtest/tests/r00878.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Loading vmods in subsequent VCLs *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=40892 **** s1 0.0 macro def s1_sock=127.0.0.1 40892 * s1 0.0 Listen on 127.0.0.1 40892 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 40892 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.23730.37d04a9d/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 41025' -P /tmp/vtc.23730.37d04a9d/v1/varnishd.pid *** v1 0.0 CMD: cd /home/ubuntu/varnish-4.0.0 && varnishd -d -d -n /tmp/vtc.23730.37d04a9d/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 41025' -P /tmp/vtc.23730.37d04a9d/v1/varnishd.pid *** v1 0.0 PID: 23736 *** v1 0.0 debug| Platform: Linux,3.13.0-24-generic,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 276 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Linux,3.13.0-24-generic,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.0 revision 2acedeb\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 9 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| wihyyiyblamosgmyuinrothemxszvhsr\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 33e580052c6109c3a5617d4702ef4db5377158b63f46f89a21c56a3cefd82441\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,3.13.0-24-generic,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.0 revision 2acedeb\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| vcl 4.0;\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "40892"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| import debug;\n **** v1 0.1 CLI TX| \tsub vcl_deliver {\n **** v1 0.1 CLI TX| \t\tset resp.http.who = debug.author(phk);\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.1 CLI RX 106 **** v1 0.1 CLI RX| Message from VCC-compiler:\n **** v1 0.1 CLI RX| Not running as root, no priv-sep\n **** v1 0.1 CLI RX| Could not load module debug\n **** v1 0.1 CLI RX| \t/usr/local/lib/varnish/vmods/libvmod_debug.so\n **** v1 0.1 CLI RX| \t/usr/local/lib/varnish/vmods/libvmod_debug.so: cannot open shared object file: No such file or directory\n **** v1 0.1 CLI RX| ('input' Line 5 Pos 16)\n **** v1 0.1 CLI RX| import debug;\n **** v1 0.1 CLI RX| ---------------#####-\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| VCL compilation failed ---- v1 0.1 FAIL VCL does not compile * top 0.1 RESETTING after bin/varnishtest/tests/r00878.vtc ** s1 0.1 Waiting for server **** s1 0.1 macro undef s1_addr **** s1 0.1 macro undef s1_port **** s1 0.1 macro undef s1_sock ** v1 1.1 Wait **** v1 1.1 STDOUT poll 0x10 ** v1 1.1 R 23736 Status: 0000 (u 0.010879 s 0.017671) * top 1.2 TEST bin/varnishtest/tests/r00878.vtc FAILED # top TEST bin/varnishtest/tests/r00878.vtc FAILED (1.213) exit=1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 11 09:36:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jun 2014 09:36:16 -0000 Subject: [Varnish] #1523: r00878.vtc fails on x86_64/Ubuntu 14.04 Trusty In-Reply-To: <046.c17f70a91acf661f421ad5bc4dbe3377@varnish-cache.org> References: <046.c17f70a91acf661f421ad5bc4dbe3377@varnish-cache.org> Message-ID: <061.70e83e1e9f0fb1d90d7c59869bdf21b9@varnish-cache.org> #1523: r00878.vtc fails on x86_64/Ubuntu 14.04 Trusty -------------------------+------------------------- Reporter: yoloseem | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I'm not 100% sure if we actually install vmod_debug, but you clearly don't have it where your varnishd expects it. If you run varnishtest with '-i' out of the source tree, this should just work. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 11 09:40:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jun 2014 09:40:53 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.e756f1ab19744b864fea70eba47d07f5@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Comment (by phk): Is this a pure 4.0.0 ? Can I get you try the current development version instead ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 12 07:48:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Jun 2014 07:48:15 -0000 Subject: [Varnish] #1524: Requests with chunked bodies can't be piped Message-ID: <043.7fda676301f29e9b477544f2d1110336@varnish-cache.org> #1524: Requests with chunked bodies can't be piped --------------------+--------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- Varnish expects request bodies to always have a Content-Length, which means that they'll fail http dissect and generate a 411 even before you get a chance to pipe the request. I would expect to at least be able to pipe the request. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 12 20:40:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Jun 2014 20:40:58 -0000 Subject: [Varnish] #1525: free() in VBO_DerefBusyObj causes child crash Message-ID: <044.d5889a74d0ac7c4cb6b2eb7d0991d0bb@varnish-cache.org> #1525: free() in VBO_DerefBusyObj causes child crash --------------------+---------------------- Reporter: joakim | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | --------------------+---------------------- I'm running Varnish 4.0.0-1~wheezy on Debian 7.5 where a child process occasionally crashes and empties/loses the cache (memory/malloc). I've included snippets of the crash messages from /var/log/messages. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 13 07:18:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jun 2014 07:18:30 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.1a0e2dad7da04685806292f02da8dcb9@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+------------------------ Reporter: yoloseem | Owner: Type: defect | Status: Need info Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+------------------------ Comment (by yoloseem): I downloaded master branch src(revision: baad5e714c31cb5dd5b15d8b87aa282b90edfc29) and built. make check result was same. Only m00011.vtc fails. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 13 18:55:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jun 2014 18:55:47 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object Message-ID: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+---------------------- Reporter: raymondjiii | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.5 | Severity: normal Keywords: | -------------------------+---------------------- To reproduce: Make a request for a URL that will result in a 403 and that is cached: In my example I use: http://ec2-107-22-134-13.compute-1.amazonaws.com/svc/crosswords/v2/puzzle/daily-2014-04-22.puz?XWD=BASIC This is saved in cache for 20 minutes within my VCL. Then I can make a PURGE request for the same URL and the response from the PURGE req is the same as for a GET request - the 403: HTTP Response Code: 403 HTTP/1.1 403 Forbidden Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.4.27 Content-Type: application/json; charset=UTF-8 Content-Length: 56 Accept-Ranges: bytes Date: Fri, 13 Jun 2014 18:43:04 GMT X-Varnish: 1056486494 Age: 0 Via: 1.1 varnish Connection: close X-Cache: MISS {"status":"ERROR","errors":["Not allowed"],"results":[]} If the object is NOT in the cache (I restart Varnish) and issue a PURGE request I get the normal PURGE miss response (using the same php curl code to test): HTTP Response Code: 200 HTTP/1.1 200 Purged - Miss Server: Varnish Content-Length: 20 Accept-Ranges: bytes Date: Fri, 13 Jun 2014 18:44:31 GMT X-Varnish: 1615046569 Age: 0 Via: 1.1 varnish Connection: close X-Cache: MISS

Purged - Miss

-- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 13 19:25:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jun 2014 19:25:09 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.fef688a7781c52695b5cd1e2b38ff8c5@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+-------------------- Reporter: raymondjiii | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by raymondjiii): I have found that vcl_fetch() is being called on a PURGE request for an object that is a 403. If I remove the following from vcl_fetch() then things are fine: ... else if (beresp.ttl <= 0s || beresp.http.Vary == "*") { # Mark as "Hit-For-Pass" for the next 2 minutes set beresp.ttl = 120s; return(hit_for_pass); } So with the above a 403 object that is purged is called vcl_fetch with the above code removed a PURGE request does not call vcl_fetch() on a PURGE miss or hit. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 13 22:13:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Jun 2014 22:13:38 -0000 Subject: [Varnish] #1525: free() in VBO_DerefBusyObj causes child crash In-Reply-To: <044.d5889a74d0ac7c4cb6b2eb7d0991d0bb@varnish-cache.org> References: <044.d5889a74d0ac7c4cb6b2eb7d0991d0bb@varnish-cache.org> Message-ID: <059.8becb9f171ed8bc25d4b882f8af1a98d@varnish-cache.org> #1525: free() in VBO_DerefBusyObj causes child crash ----------------------+-------------------- Reporter: joakim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by joakim): Some extra system information. {{{ # varnishd -V varnishd (varnish-4.0.0 revision 2acedeb) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS # uname -a Linux cache01 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux # free -m total used free shared buffers cached Mem: 258453 24400 234052 0 288 1258 -/+ buffers/cache: 22853 235600 Swap: 7628 0 7628 # head /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz stepping : 7 microcode : 0x70d cpu MHz : 1200.000 cache size : 15360 KB physical id : 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jun 14 23:18:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 14 Jun 2014 23:18:59 -0000 Subject: [Varnish] #1527: Assert error in hcb_insert(), hash/hash_critbit.c line 226: Condition(noh == NULL) not true. Message-ID: <044.291983e897d6be23b7193869c25cc93a@varnish-cache.org> #1527: Assert error in hcb_insert(), hash/hash_critbit.c line 226: Condition(noh == NULL) not true. --------------------+---------------------- Reporter: joakim | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | --------------------+---------------------- Running Debian package varnish 4.0.0-2~wheezy^1^ on Debian Wheezy (7.5). banner: {{{ Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit varnish-4.0.0 revision e814326 }}} panic: {{{ Last panic at: Sat, 14 Jun 2014 22:35:49 GMT Assert error in hcb_insert(), hash/hash_critbit.c line 226: Condition(noh == NULL) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433b45: /usr/sbin/varnishd() [0x433b45] 0x44d28a: /usr/sbin/varnishd() [0x44d28a] 0x44d497: /usr/sbin/varnishd() [0x44d497] 0x428912: /usr/sbin/varnishd(HSH_Lookup+0x592) [0x428912] 0x436398: /usr/sbin/varnishd() [0x436398] 0x437531: /usr/sbin/varnishd(CNT_Request+0x841) [0x437531] 0x42e5eb: /usr/sbin/varnishd(HTTP1_Session+0x7cb) [0x42e5eb] 0x43b468: /usr/sbin/varnishd() [0x43b468] 0x43c4f0: /usr/sbin/varnishd(SES_pool_accept_task+0x2b0) [0x43c4f0] 0x435ff9: /usr/sbin/varnishd(Pool_Work_Thread+0xa9) [0x435ff9] req = 0x7fe77717b020 { sp = 0x7fe776ec0020, vxid = 1074432999, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fe776ec0020 { fd = 268, vxid = 691174, client = 123.645.345.987 39187, step = S_STP_WORKING, }, worker = 0x7fe77195ec50 { ws = 0x7fe77195ee60 { id = "wrk", {s,f,r,e} = {0x7fe77195e450,0x7fe77195e450,(nil),+2048}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x7fe77717b1b0 { id = "req", {s,f,r,e} = {0x7fe77717cff0,+544,+254000,+254000}, }, http[req] = { ws = 0x7fe77717b1b0[req] "GET", "/thumbnails/0003/f975d19b7388c38a92fef77de0a137.jpg", "HTTP/1.1", "User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)", "Accept: */*", "Range: bytes=0-8999", "Referer: http://example.com/v/2043082", "Host: img.example.com", "Connection: keep-alive", "X-Forwarded-For: 123.645.345.987", }, vcl = { srcname = { "input", "Builtin", "example-acl.vcl", "example-backend.vcl", "example-synth.vcl", }, }, }, }}} ^1^ Compiled from http://anonscm.debian.org/gitweb/?p=pkg-varnish/pkg- varnish.git;a=shortlog as the deb hasn't shown up in the varnish repo yet. :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jun 15 07:42:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 15 Jun 2014 07:42:08 -0000 Subject: [Varnish] #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. Message-ID: <044.3e68bc8a0e5fc204d4fc9ff752773849@varnish-cache.org> #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. --------------------+---------------------- Reporter: joakim | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | --------------------+---------------------- Same setup as in #1527 and looks to be the same error as in #1188. No vmods except std and directors though. {{{ Last panic at: Sun, 15 Jun 2014 04:33:05 GMT Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433b45: /usr/sbin/varnishd() [0x433b45] 0x44d0dc: /usr/sbin/varnishd() [0x44d0dc] 0x44d3e7: /usr/sbin/varnishd() [0x44d3e7] 0x428912: /usr/sbin/varnishd(HSH_Lookup+0x592) [0x428912] 0x436398: /usr/sbin/varnishd() [0x436398] 0x437531: /usr/sbin/varnishd(CNT_Request+0x841) [0x437531] 0x42e5eb: /usr/sbin/varnishd(HTTP1_Session+0x7cb) [0x42e5eb] 0x43b468: /usr/sbin/varnishd() [0x43b468] 0x43c4f0: /usr/sbin/varnishd(SES_pool_accept_task+0x2b0) [0x43c4f0] 0x435ff9: /usr/sbin/varnishd(Pool_Work_Thread+0xa9) [0x435ff9] req = 0x7f4d149b0020 { sp = 0x7f4a4b76a020, vxid = 1074987845, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f4a4b76a020 { fd = 44, vxid = 1246020, client = 123.456.789.0 49775, step = S_STP_WORKING, }, worker = 0x7f4cfa3aec50 { ws = 0x7f4cfa3aee60 { id = "wrk", {s,f,r,e} = {0x7f4cfa3adc50,0x7f4cfa3adc50,(nil),+4096}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x7f4d149b01b0 { id = "req", {s,f,r,e} = {0x7f4d149b1ff0,+632,+254000,+254000}, }, http[req] = { ws = 0x7f4d149b01b0[req] "GET", "/7cbe260c-9825-4f65-b0ed-6b45ddeb6db2/large/segment000072.ts", "HTTP/1.1", "Host: archive.example.com", "X-Playback-Session-Id: D30C8186-0B2C-45BD-9D95-4A04ABFD1E2E", "Accept: */*", "Connection: keep-alive", "User-Agent: AppleCoreMedia/1.0.0.11D201 (iPad; U; CPU OS 7_1_1 like Mac OS X; en_us)", "X-Forwarded-For: 123.456.789.0", }, vcl = { srcname = { "input", "Builtin", "example-acl.vcl", "example-backend.vcl", "example-synth.vcl", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jun 15 07:48:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 15 Jun 2014 07:48:43 -0000 Subject: [Varnish] #1529: Assert error in hcb_insert(), hash/hash_critbit.c line 260: Condition(y->critbit != y2->critbit) not true. Message-ID: <044.e1fc375fbdd7bda441b03cdaac67318b@varnish-cache.org> #1529: Assert error in hcb_insert(), hash/hash_critbit.c line 260: Condition(y->critbit != y2->critbit) not true. --------------------+---------------------- Reporter: joakim | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | --------------------+---------------------- Again, same setup as in #1527 and #1528. Couldn't find any previous references to this error. {{{ Last panic at: Sun, 15 Jun 2014 04:33:05 GMT Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433b45: /usr/sbin/varnishd() [0x433b45] 0x44d0dc: /usr/sbin/varnishd() [0x44d0dc] 0x44d3e7: /usr/sbin/varnishd() [0x44d3e7] 0x428912: /usr/sbin/varnishd(HSH_Lookup+0x592) [0x428912] 0x436398: /usr/sbin/varnishd() [0x436398] 0x437531: /usr/sbin/varnishd(CNT_Request+0x841) [0x437531] 0x42e5eb: /usr/sbin/varnishd(HTTP1_Session+0x7cb) [0x42e5eb] 0x43b468: /usr/sbin/varnishd() [0x43b468] 0x43c4f0: /usr/sbin/varnishd(SES_pool_accept_task+0x2b0) [0x43c4f0] 0x435ff9: /usr/sbin/varnishd(Pool_Work_Thread+0xa9) [0x435ff9] req = 0x7f4d149b0020 { sp = 0x7f4a4b76a020, vxid = 1074987845, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f4a4b76a020 { fd = 44, vxid = 1246020, client = 123.456.789.0 49775, step = S_STP_WORKING, }, worker = 0x7f4cfa3aec50 { ws = 0x7f4cfa3aee60 { id = "wrk", {s,f,r,e} = {0x7f4cfa3adc50,0x7f4cfa3adc50,(nil),+4096}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x7f4d149b01b0 { id = "req", {s,f,r,e} = {0x7f4d149b1ff0,+632,+254000,+254000}, }, http[req] = { ws = 0x7f4d149b01b0[req] "GET", "/7cbe260c-9825-4f65-b0ed-6b45ddeb6db2/large/segment000072.ts", "HTTP/1.1", "Host: archive.example.com", "X-Playback-Session-Id: D30C8186-0B2C-45BD-9D95-4A04ABFD1E2E", "Accept: */*", "Connection: keep-alive", "User-Agent: AppleCoreMedia/1.0.0.11D201 (iPad; U; CPU OS 7_1_1 like Mac OS X; en_us)", "X-Forwarded-For: 123.456.789.0", }, vcl = { srcname = { "input", "Builtin", "example-acl.vcl", "example-backend.vcl", "example-synth.vcl", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 09:53:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 09:53:11 -0000 Subject: [Varnish] #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. In-Reply-To: <044.3e68bc8a0e5fc204d4fc9ff752773849@varnish-cache.org> References: <044.3e68bc8a0e5fc204d4fc9ff752773849@varnish-cache.org> Message-ID: <059.4246c763ef1d0abd199204a52ac94260@varnish-cache.org> #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. ----------------------+-------------------- Reporter: joakim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Hi, could you share some information about the circumstances when these errors are occuring? E.g.: - What is the load when it happens - Mean time between failures - Any known sequence of steps to reproduce? Also please share a bit about the build you are using. One of the bug reports suggests glibc malloc implementation instead of the preferred jemalloc. Is that intentional? Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 09:56:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 09:56:45 -0000 Subject: [Varnish] #1507: varnishstat is missing cache hit ratio In-Reply-To: <041.dd00f17339d5a9cb13ffc84055c90494@varnish-cache.org> References: <041.dd00f17339d5a9cb13ffc84055c90494@varnish-cache.org> Message-ID: <056.52e3d59afc8fc556e6d8371f4168753a@varnish-cache.org> #1507: varnishstat is missing cache hit ratio -------------------------+-------------------- Reporter: Tin | Owner: fgsch Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: varnishstat | -------------------------+-------------------- Changes (by fgsch): * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 11:55:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 11:55:58 -0000 Subject: [Varnish] #1408: idle_send_timeout not valid in an included vcl file In-Reply-To: <049.77d63141d9bdb0a1635d67399b99efa7@varnish-cache.org> References: <049.77d63141d9bdb0a1635d67399b99efa7@varnish-cache.org> Message-ID: <064.8ec6aa387f27c38ecc17fa57d40df847@varnish-cache.org> #1408: idle_send_timeout not valid in an included vcl file -------------------------------+---------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: idle_send_timeout | -------------------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => invalid Comment: Timeout. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 12:00:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 12:00:20 -0000 Subject: [Varnish] #1459: Undefined references in documentation In-Reply-To: <046.c258283d118d15bda2cfb8813f1d2132@varnish-cache.org> References: <046.c258283d118d15bda2cfb8813f1d2132@varnish-cache.org> Message-ID: <061.de1a9f67942b34433004b379107f6f64@varnish-cache.org> #1459: Undefined references in documentation ---------------------------+---------------------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: closed Priority: low | Milestone: Varnish 4.0 release Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: In master these errors are hard errors, and as such have been fixed before 4.0.0. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 12:04:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 12:04:30 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. In-Reply-To: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> References: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> Message-ID: <058.aad688375b122ec1750315b35c644a89@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. ----------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: gzip | ----------------------+-------------------- Comment (by geoff): cache_gzip.c hasn't changed since December 2013. I'll try to work up a VTC test to demonstrate the failure. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 12:30:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 12:30:28 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. In-Reply-To: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> References: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> Message-ID: <058.e8ee436b9db5669b7d7d32609046757b@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. ----------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: gzip | ----------------------+-------------------- Comment (by geoff): Just realized that there's no reliable way to reproduce this, since the failure came from compression -- preparing a response with a gzipped body. Very likely it was a low memory situation -- zlib couldn't get enough memory to compress. To my knowledge it hasn't happened again at the site since the incident reported on November 2013. I still think that Varnish should recover more gracefully when that happens, by sending a 503 error rather than crashing with an assertion. I wouldn't mind working up a patch, but how would we test it? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 12:48:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 12:48:58 -0000 Subject: [Varnish] #1530: re-check expire ims obj Message-ID: <043.165ea63c77ef36d77ba9b9ef6a5d1e69@varnish-cache.org> #1530: re-check expire ims obj --------------------+------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- as discussed at [wiki:VDD14Q2]: please re-visit the code which expires candidate objects for refresh: * any successful fetch should expire the "ims obj" * which implies that any unsuccessful fetch should not -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 12:49:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 12:49:14 -0000 Subject: [Varnish] #1530: re-check expire ims obj In-Reply-To: <043.165ea63c77ef36d77ba9b9ef6a5d1e69@varnish-cache.org> References: <043.165ea63c77ef36d77ba9b9ef6a5d1e69@varnish-cache.org> Message-ID: <058.6777d553a4c5c3ba3aaba430618de4f0@varnish-cache.org> #1530: re-check expire ims obj ----------------------+-------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by slink): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 17 13:12:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jun 2014 13:12:48 -0000 Subject: [Varnish] #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. In-Reply-To: <044.3e68bc8a0e5fc204d4fc9ff752773849@varnish-cache.org> References: <044.3e68bc8a0e5fc204d4fc9ff752773849@varnish-cache.org> Message-ID: <059.3a8ee0b04486187ff715caf473df17ca@varnish-cache.org> #1528: Assert error in hcb_insert(), hash/hash_critbit.c line 216: Condition((y)->magic == 0x125c4bd2) not true. ----------------------+-------------------- Reporter: joakim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by joakim): Ticket #1527 is using the build provided by repo.varnish-cache.org^1^ and, yeah, it seems to be using glibc malloc. Tickets #1527, #1528 and #1529 are using the deb created by running dpkg-buildpackage -b on the master branch in this git repo: http://anonscm.debian.org/gitweb/?p=pkg-varnish /pkg-varnish.git;a=shortlog and it is using jemalloc. - Low load generally (avg ~2.5 with ~500-700 connections on a 24 core Xeon E5 machine). - A few hours between failures, sometimes longer sometimes shorter. Longest uptime I've seen is just under a day. - Haven't really been able to see any patterns, though expunging of expired objects usually go on when it does crash. The machines have been running Varnish 3.0.5 for a long time without a hick-up on the same hardware. I'll sanitize my VCLs and attach them too when I get the chance. --- ^1^ http://repo.varnish- cache.org/debian/pool/varnish-4.0/v/varnish/varnish_4.0.0-1~wheezy_amd64.deb -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 19 13:37:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Jun 2014 13:37:44 -0000 Subject: [Varnish] #1472: Varnish 4.0.0 packages for el6 are not signed In-Reply-To: <044.b98708cf1481f1c020f64c48202670a8@varnish-cache.org> References: <044.b98708cf1481f1c020f64c48202670a8@varnish-cache.org> Message-ID: <059.81107d4c7e263c536b48a871766766b0@varnish-cache.org> #1472: Varnish 4.0.0 packages for el6 are not signed ------------------------------+---------------------------------- Reporter: mortsa | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0 release Component: packaging | Version: 4.0.0-beta1 Severity: major | Resolution: fixed Keywords: gpg rpm security | ------------------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: I've made the necessary changes to varnish-release and varnish RPM packaging setup now. The RPM packages for the upcoming Varnish Cache 4.0.1 release will be signed. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 07:36:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 07:36:52 -0000 Subject: [Varnish] #1530: re-check expire ims obj In-Reply-To: <043.165ea63c77ef36d77ba9b9ef6a5d1e69@varnish-cache.org> References: <043.165ea63c77ef36d77ba9b9ef6a5d1e69@varnish-cache.org> Message-ID: <058.d574b0812f6fa4b79bef1bb6947f1f08@varnish-cache.org> #1530: re-check expire ims obj ----------------------+--------------------- Reporter: slink | Owner: phk 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 [b61c2305462c9428225a9531e664907db408fd7f]: {{{ #!CommitTicketReference repository="" revision="b61c2305462c9428225a9531e664907db408fd7f" Always expire the ims-candidate object on a successful fetch Fixes #1530 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 09:54:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 09:54:01 -0000 Subject: [Varnish] #1524: Requests with chunked bodies can't be piped In-Reply-To: <043.7fda676301f29e9b477544f2d1110336@varnish-cache.org> References: <043.7fda676301f29e9b477544f2d1110336@varnish-cache.org> Message-ID: <058.22d510b39727eabd7cb852c8e5ba68d4@varnish-cache.org> #1524: Requests with chunked bodies can't be piped --------------------+---------------------------------------- Reporter: scoof | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [b4b628fa01591d50b2ce09e570ecd5470477cc65]: {{{ #!CommitTicketReference repository="" revision="b4b628fa01591d50b2ce09e570ecd5470477cc65" Implement proper handling of chunked encoding of req.body. Fixes #1524 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 10:25:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 10:25:45 -0000 Subject: [Varnish] #1509: libedit dependency missing on EL6 In-Reply-To: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> References: <043.ef41acfdc4c1f81de0db468ced9d2b56@varnish-cache.org> Message-ID: <058.44c3eb1e05a93457e282ad26f6d5ad72@varnish-cache.org> #1509: libedit dependency missing on EL6 -----------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 4.0.0 Severity: major | Resolution: fixed Keywords: | -----------------------+----------------------- Changes (by Lasse Karstensen ): * status: new => closed * resolution: => fixed Comment: In [df2446b0f6b7be06f775244746ae16ad6b2e50dd]: {{{ #!CommitTicketReference repository="" revision="df2446b0f6b7be06f775244746ae16ad6b2e50dd" Add libedit dependency. Fixes: #1509 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 10:30:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 10:30:33 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.d104727ec3d7ba4607f9a24253df5562@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: As far as I can see, there are no indications that this is a varnish bug, but rather a problem with your VCL. Please use the varnish-misc mailing list or IRC to get help, and remember to provide varnishlog output as well as your VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 10:49:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 10:49:45 -0000 Subject: [Varnish] #1531: editline does not clean command line Message-ID: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> #1531: editline does not clean command line ------------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Keywords: ------------------------+------------------- When using varnishadm to send commands to varnishd, varnishadm doesn't clean the prompt after a command. The previous command is still visible in the terminal after the prompt returns. Expected result: varnishadm would restore the prompt to a clean state (=="varnish > ") after each command that is run. {{{ lkarsten at sierra:~$ varnishadm 200 ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,3.13.0-29-generic,x86_64,-smalloc,-smalloc,-hcritbit varnish-4.0.1-rc1 revision 0e9bd49 Type 'help' for command list. Type 'quit' to close CLI session. varnish> help 200 help [command] ping [timestamp] [.. cut ..] backend.list backend.set_health matcher state ban [&& ]... ban.list varnish> helpbackend.list varnish> backend.list 200 Backend name Refs Admin Probe default(127.0.0.1,,8085) 1 probe Healthy 4/4 varnish> backend.listquit varnish> quit 500 Closing CLI connection }}} The internal buffer is emptied, because pressing enter again makes varnishadm return as no command was given. TERM is xterm-color, ssh from urxvt to a ubuntu 14.04/trusty server. {{{ lkarsten at sierra:~$ ldd /opt/varnish/bin/varnishadm linux-vdso.so.1 => (0x00007fffd898c000) libvarnishapi.so.1 => /opt/varnish/lib/libvarnishapi.so.1 (0x00007fb015796000) libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fb015557000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb015250000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb015032000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb014c6c000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb014a2d000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb014825000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb0145fc000) /lib64/ld-linux-x86-64.so.2 (0x00007fb0159cc000) lkarsten at sierra:~$ lkarsten at sierra:~$ dpkg -l | grep libedit ii libedit-dev:amd64 3.1-20130712-2 amd64 BSD editline and history libraries (development files) ii libedit2:amd64 3.1-20130712-2 amd64 BSD editline and history libraries }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 10:50:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 10:50:10 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line (was: editline does not clean command line) In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.8d6c08cb6afa3322704366e8f97a5f8c@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 13:32:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 13:32:54 -0000 Subject: [Varnish] #1269: varnishncsa does not show pipe'ed requests In-Reply-To: <047.74c03b61e1ee686de1e8904dfd87ef9a@varnish-cache.org> References: <047.74c03b61e1ee686de1e8904dfd87ef9a@varnish-cache.org> Message-ID: <062.f4c691a590ecad532a7585659bc37ac7@varnish-cache.org> #1269: varnishncsa does not show pipe'ed requests -------------------------+----------------------- Reporter: prymitive | Owner: lkarsten Type: defect | Status: closed Priority: low | Milestone: Component: varnishncsa | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: | -------------------------+----------------------- Changes (by Andreas Plesner ): * status: new => closed * resolution: => fixed Comment: In [0b1fa10ab261b6c0301d5b20fd13193a739bd978]: {{{ #!CommitTicketReference repository="" revision="0b1fa10ab261b6c0301d5b20fd13193a739bd978" Add varnishncsa logging of pipe requests Fixes #1269 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 13:55:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 13:55:04 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.931bc01b91a7ffdee57e579f8cbfd8ac@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by raymondjiii): How is this not a Varnish bug??? It does not matter what I have in my VCL, regardless of what I have in my VCL a PURGE request should NEVER return what is in the cache which is exactly what this is doing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 13:57:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 13:57:26 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.4d68fd8605308af9ce06a6b2db671c6c@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by scoof): Varnish doesn't even support HTTP PURGE until you add it to the VCL, so it's very much a VCL issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 14:03:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 14:03:11 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.d222ffeac25f11e617b5f052f4ed91ff@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by raymondjiii): Removing the two lines in my VCL have nothing to do with the PURGE vcl flow. That vcl subroutine should not be called. My purge support in my vcl is basic text book example handling vcl_hit and vcl_miss. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 14:11:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 14:11:14 -0000 Subject: [Varnish] #1526: PURGE does not work on a 403 cached object In-Reply-To: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> References: <049.4867d1066732f8611bb1d6077476b205@varnish-cache.org> Message-ID: <064.3794ec9270630d26922bbb4339338efc@varnish-cache.org> #1526: PURGE does not work on a 403 cached object -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by scoof): I still suggest you use the mailing list to confirm that this really is a bug. There's no indication in this ticket that it is. If you're certain that it is a bug, attach the vcl and varnishlog showing the bug. vcl_fetch will be called for a PURGE request in a default configuration, so you're going to have to show us what VCL you believe isn't working, as well as copies of varnishlog output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 23:33:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 23:33:28 -0000 Subject: [Varnish] #1532: Incorrectly rounding when using reals Message-ID: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> #1532: Incorrectly rounding when using reals --------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- As per subject. See attached file for test and patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 23 23:34:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jun 2014 23:34:49 -0000 Subject: [Varnish] #1532: Incorrectly rounding when using reals In-Reply-To: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> References: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> Message-ID: <058.598a90e477ea450bc5403ffb82789128@varnish-cache.org> #1532: Incorrectly rounding when using reals ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * version: unknown => trunk * component: build => varnishd Old description: > As per subject. See attached file for test and patch. New description: As per subject. See attached file for test and fix. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 07:54:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 07:54:30 -0000 Subject: [Varnish] #1533: vmod_querysort fails to build on centos 6.5 Message-ID: <049.0f6199403f9a72228c6ae785602743de@varnish-cache.org> #1533: vmod_querysort fails to build on centos 6.5 -------------------------+-------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: normal Milestone: | Component: vmod Version: trunk | Severity: normal Keywords: | -------------------------+-------------------- repository at commit 14da1840453b4076ac8b46448c9092a491037d5a {{{ python2.6 ../../lib/libvcc/vmodtool.py --strict ../../lib/libvmod_std/vmod.vcc CC vmod_std.lo CC vmod_std_conversions.lo CC vmod_std_fileread.lo CC vmod_std_querysort.lo cc1: warnings being treated as errors vmod_std_querysort.c: In function ?vmod_querysort?: vmod_std_querysort.c:63: error: ?param? may be used uninitialized in this function make[3]: *** [vmod_std_querysort.lo] Error 1 }}} it does compile in centos 7 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 08:27:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 08:27:33 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.8bd4b00b0dbe77d07cfd6527473df14c@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+-------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by g.gerritsen): ticket can be closed, works fine with the increased workspace -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 10:59:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 10:59:58 -0000 Subject: [Varnish] #1533: vmod_querysort fails to build on centos 6.5 In-Reply-To: <049.0f6199403f9a72228c6ae785602743de@varnish-cache.org> References: <049.0f6199403f9a72228c6ae785602743de@varnish-cache.org> Message-ID: <064.bc0b728c8e71dc639e0dfd8c4bdee60e@varnish-cache.org> #1533: vmod_querysort fails to build on centos 6.5 -------------------------+--------------------- Reporter: g.gerritsen | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: vmod | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by daghf): * status: new => closed * resolution: => fixed Comment: This has since been fixed in commit 6547a456e793a4437f0004654c3fdf9ca09e3559. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 11:14:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 11:14:46 -0000 Subject: [Varnish] #1534: is groff really required for varnish 4+ ? Message-ID: <049.1ec3b1ed6de1bca9c9bcd13d03edaaa2@varnish-cache.org> #1534: is groff really required for varnish 4+ ? -------------------------+--------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: low Milestone: | Component: build Version: trunk | Severity: trivial Keywords: | -------------------------+--------------------- according to the varnish.spec file groff is required, however I have been able to create builds (make dist) without groff installed at all. (just checking) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 11:36:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 11:36:17 -0000 Subject: [Varnish] #1535: sphinx-build 0.6.6 incompatibilities (centos 6.5) Message-ID: <049.30f178036ed49f3e180450203778ca42@varnish-cache.org> #1535: sphinx-build 0.6.6 incompatibilities (centos 6.5) -------------------------+-------------------- Reporter: g.gerritsen | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------- make dist on centos 6.5 fails with {{{ make[4]: Entering directory `/home/build/var6/doc/sphinx' sphinx-build -W -N -n -b html -d build/doctrees -D latex_paper_size=a4 . build/html Sphinx v0.6.6 Usage: /usr/bin/sphinx-build [options] sourcedir outdir [filenames...] Options: -b -- builder to use; default is html -a -- write all files; default is to only write new and changed files -E -- don't use a saved environment, always read all files -t -- include "only" blocks with -d -- path for the cached environment and doctree files (default: outdir/.doctrees) -c -- path where configuration file (conf.py) is located (default: same as sourcedir) -C -- use no config file at all, only -D options -D -- override a setting in configuration -A -- pass a value into the templates, for HTML builder -N -- do not do colored output -q -- no output on stdout, just warnings on stderr -Q -- no output at all, not even warnings -w -- write warnings (and errors) to given file -W -- turn warnings into errors -P -- run Pdb on exception Modi: * without -a and without filenames, write new and changed files. * with -a, write all files. * with filenames, write these. }}} -n (nitpick mode) is not available, when I remove -n from the Makefile I get the following warning {{{ reading sources... [ 99%] whats-new/index reading sources... [100%] whats-new/upgrading Warning, treated as error: /home/build/var6/doc/sphinx/include/vmod_directors.rst:4: (WARNING/2) Explicit markup ends without a blank line; unexpected unindent. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 12:32:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 12:32:27 -0000 Subject: [Varnish] #1535: sphinx-build 0.6.6 incompatibilities (centos 6.5) In-Reply-To: <049.30f178036ed49f3e180450203778ca42@varnish-cache.org> References: <049.30f178036ed49f3e180450203778ca42@varnish-cache.org> Message-ID: <064.d131ba423c28ff919a08f071f02c051e@varnish-cache.org> #1535: sphinx-build 0.6.6 incompatibilities (centos 6.5) -------------------------+----------------------- Reporter: g.gerritsen | Owner: lkarsten Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten * status: new => assigned Comment: Confirmed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 24 21:14:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jun 2014 21:14:40 -0000 Subject: [Varnish] #1536: 4.0.1 delivers instead of fetch Message-ID: <054.8bbdb691fb2e0cb7ec38ca285b78d3e8@varnish-cache.org> #1536: 4.0.1 delivers instead of fetch ------------------------------+---------------------- Reporter: little_butterfly | Type: defect Status: new | Priority: normal Milestone: Later | Component: varnishd Version: 4.0.1 | Severity: normal Keywords: must-revalidate | ------------------------------+---------------------- Hi Just tried Varnish 4.0.1 (git HEAD as of today). PUT requests with chunked encoding works now! :-) great! What I cannot get to work is that some items are cached that should not be. Specifically, when the backend returns "must-revalidate", I would expect Varnish to do a fetch (and the backend to sometimes respond with 304 and no body, sometimes with an updated document). But Varnish seems to just serve old content from the cache, which breaks my app. Log: {{{ * << Request >> 14 - Begin req 13 rxreq - Timestamp Start: 1403641419.835198 0.000000 0.000000 - Timestamp Req: 1403641419.835198 0.000000 0.000000 - ReqStart 127.0.0.1 47671 - ReqMethod GET - ReqURL /dc/binding-from-12345678 - ReqProtocol HTTP/1.1 - ReqHeader Cache-Control: max-age=0 - ReqHeader Host: localhost - ReqHeader Connection: keep-alive - ReqHeader X-Forwarded-For: 127.0.0.1 - VCL_call RECV - VCL_return hash - VCL_call HASH - VCL_return lookup - Hit 2147483655 - VCL_call HIT - VCL_return deliver - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Server: CouchDB/1.6.0 (Erlang OTP/R15B01) - RespHeader ETag: "5-eaabf6a34aafb6faa42ae5ec41ca71ab" - RespHeader Date: Tue, 24 Jun 2014 20:22:42 GMT - RespHeader Content-Type: text/plain; charset=utf-8 - RespHeader cache-control: max-age=0, must-revalidate - RespHeader X-Varnish: 14 7 - RespHeader Age: 57 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - VCL_return deliver - Timestamp Process: 1403641419.836180 0.000982 0.000982 - RespHeader Content-Length: 999 - Debug "RES_MODE 2" - RespHeader Connection: keep-alive - RespHeader Accept-Ranges: bytes - Timestamp Resp: 1403641419.836666 0.001468 0.000486 - Debug "XXX REF 2" - ReqAcct 122 0 122 341 999 1340 - End }}} Note these: - VCL_call HIT - VCL_return deliver And this one: - RespHeader cache-control: max-age=0, must-revalidate Seems to contradict each other. Am I doing something wrong, or is Varnish not up to spec here? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 25 08:08:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Jun 2014 08:08:56 -0000 Subject: [Varnish] #1537: Varnish .deb for wheezy is not compiled against/does not depend on jemalloc Message-ID: <044.e095537cfdf43d97bf18575d45c24ffd@varnish-cache.org> #1537: Varnish .deb for wheezy is not compiled against/does not depend on jemalloc --------------------+----------------------- Reporter: joakim | Type: defect Status: new | Priority: high Milestone: | Component: packaging Version: 4.0.1 | Severity: normal Keywords: | --------------------+----------------------- The official Varnish package for Debian (Wheezy) uses glibc malloc: Package: varnish Source: varnish (4.0.1-1) Version: 4.0.1-1~wheezy Installed-Size: 1458 Maintainer: Varnish Package Maintainers Architecture: amd64 Depends: libc6 (>= 2.3.2), libedit2 (>= 2.11-20080614-1), libncurses5 (>= 5.5-5~), libpcre3 (>= 8.10), libtinfo5, libvarnishapi1 (= 4.0.1-1~wheezy), gcc (>= 3.3), libc6-dev | libc6.1-dev | libc-dev, adduser Suggests: varnish-doc Description-en: state of the art, high-performance web accelerator Varnish Cache is a state of the art web accelerator written with performance and flexibility in mind. . Varnish Cache stores web pages in memory so web servers don't have to create the same web page over and over again. Varnish serves pages much faster than any application server; giving the website a significant speed up. . Some of the features include: * A modern design * VCL - a very flexible configuration language * Load balancing with health checking of backends * Partial support for ESI - Edge Side Includes * URL rewriting * Graceful handling of "dead" backends Homepage: http://varnish-cache.org/ Section: varnish-4.0/web Priority: optional Filename: pool/varnish-4.0/v/varnish/varnish_4.0.1-1~wheezy_amd64.deb Size: 614688 MD5sum: dcaf1afc470b8cccede395f8b33fa2b2 SHA1: 33613807e535bff567ab09aa26d7b1b6421c788c SHA256: 41416da0a365c332bb0aaf756f0c3be88a7f2b5dd34902437d15599b7a4f66b2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 25 12:06:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Jun 2014 12:06:43 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.88d7c2d36a58030b08820fd15539e2e4@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by shing6326): Hi I got the same error, and the child we be killed, thanks. Last panic at: Tue, 24 Jun 2014 16:12:18 GMT Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: Condition((oc->exp_flags & (1<<7)) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x430b95: /usr/sbin/varnishd() [0x430b95] 0x434730: /usr/sbin/varnishd() [0x434730] 0x435f61: /usr/sbin/varnishd(CNT_Request+0x271) [0x435f61] 0x42b823: /usr/sbin/varnishd(HTTP1_Session+0x5b3) [0x42b823] 0x439a28: /usr/sbin/varnishd() [0x439a28] 0x433694: /usr/sbin/varnishd(Pool_Work_Thread+0x354) [0x433694] 0x445b98: /usr/sbin/varnishd() [0x445b98] 0x3ac08079d1: /lib64/libpthread.so.0() [0x3ac08079d1] 0x3ac04e8b5d: /lib64/libc.so.6(clone+0x6d) [0x3ac04e8b5d] req = 0x7f6e69417020 { sp = 0x7f6e6528b360, vxid = 1077908340, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f6e6528b360 { fd = 2752, vxid = 953328, client = x.x.x.x 49566, step = S_STP_WORKING, }, worker = 0x7f6e6a931c10 { ws = 0x7f6e6a931e28 { id = "wrk", {s,f,r,e} = {0x7f6e6a931400,0x7f6e6a931400,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7f6e694171b0 { id = "req", {s,f,r,e} = {0x7f6e69419008,+624,(nil),+57368}, }, http[req] = { ws = 0x7f6e694171b0[req] "GET", "/ls/feeds/match_timelinedelta/4768754", "HTTP/1.1", "Host: xxx.net", "If-Modified-Since: Tue, 24 Jun 2014 16:11:39 GMT", "If-None-Match: "f57e9046523e2085132dcf09dd58e678619bf32d"", "Referer: http://xxx.com/webview/Other/zensis- match_tracker.html?matchid=4768754", "Accept: */*", "Accept-Language: en-gb", "Connection: keep-alive", "Origin: http://xxx.com", "User-Agent: Mozilla/5.0 (iPad; CPU OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D201", "X-Forwarded-For: x.x.x.x", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7f6e5b5a4f00 { vxid = 2149946340, http[obj] = { ws = 0x7f6e69c17268[] "HTTP/1.1", "200", "OK", "Server: nginx/1.2.1", "Content-Type: application/json; charset=UTF-8", "X-Powered-By: PHP/5.4.4-14+deb7u11", "Etag: "b091fc9cd06016c778943f1fdef768ff3142030f"", "Cache-Control: public,max-age=2", "Expires: Tue, 24 Jun 2014 16:11:47 GMT", "Last-Modified: Tue, 24 Jun 2014 16:11:45 GMT", "Access-Control-Allow-Origin: *", "Access-Control-Allow-Methods: GET", "Access-Control-Allow-Headers: origin, x-requested-with, content- type, accept", "Access-Control-Max-Age: 86400", "X-Fn-Web: zrh5-fnweb05.ch.xxxx", "Content-Encoding: gzip", "X-Srv: zrh4-fn-varnish1.ch.xxxx", "X-Sbe: z5fn5", "X-Varnish: 1336090026 1336089570", "Via: 1.1 varnish", "X-Varnish-IP: x.x.x.x", "X-Varnish: 1124896824 1124895106", "Via: 1.1 varnish", "Date: Tue, 24 Jun 2014 16:11:54 GMT", "X-Varnish: 27317393", "Via: 1.1 varnish (v4)", "X-Varnish: 1124896180 1124895106", "Via: 1.1 varnish", "X-Varnish: 2576278", "Via: 1.1 varnish (v4)", }, len = 972, store = { 972 { 1f 8b 08 00 00 00 00 00 00 03 95 55 db 6e e3 36 |...........U.n.6| 10 fd 95 82 cf 4a 4b 51 57 eb ad 6f 5b f4 a5 28 |.....JKQW..o[..(| 36 40 8b cd 22 a0 25 2a e6 ae 4c ba 14 95 d4 35 |6 at ..".%*..L....5| f2 ef 3d 43 4a b2 13 68 7b 01 02 87 97 e1 cc 39 |..=CJ..h{......9| [908 more] }, }, }, }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 25 13:55:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Jun 2014 13:55:58 -0000 Subject: [Varnish] #1529: Assert error in hcb_insert(), hash/hash_critbit.c line 260: Condition(y->critbit != y2->critbit) not true. In-Reply-To: <044.e1fc375fbdd7bda441b03cdaac67318b@varnish-cache.org> References: <044.e1fc375fbdd7bda441b03cdaac67318b@varnish-cache.org> Message-ID: <059.1b6a763590400dd66cde70eb3d55b491@varnish-cache.org> #1529: Assert error in hcb_insert(), hash/hash_critbit.c line 260: Condition(y->critbit != y2->critbit) not true. ----------------------+-------------------- Reporter: joakim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by joakim): Bah, noticed I'd pasted the wrong panic output in this ticket. However, the panic is still present in varnish master as of commit a9d746324385f55f080e7a6fc9e400c412cac40f Panic message: {{{ Last panic at: Wed, 25 Jun 2014 13:41:38 GMT Assert error in hcb_insert(), hash/hash_critbit.c line 260: Condition(y->critbit != y2->critbit) not true. thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x434585: /usr/sbin/varnishd() [0x434585] 0x44e3e8: /usr/sbin/varnishd() [0x44e3e8] 0x44e6f7: /usr/sbin/varnishd() [0x44e6f7] 0x428b72: /usr/sbin/varnishd(HSH_Lookup+0x572) [0x428b72] 0x4378d8: /usr/sbin/varnishd() [0x4378d8] 0x438f09: /usr/sbin/varnishd(CNT_Request+0x519) [0x438f09] 0x42ea3b: /usr/sbin/varnishd(HTTP1_Session+0x7cb) [0x42ea3b] 0x43cb08: /usr/sbin/varnishd() [0x43cb08] 0x437470: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x437470] 0x449fbd: /usr/sbin/varnishd() [0x449fbd] req = 0x7faac5129020 { sp = 0x7fccc6c106a0, vxid = 1080330745, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fccc6c106a0 { fd = 110, vxid = 6588912, client = 94.234.170.173 4653, step = S_STP_WORKING, }, worker = 0x7fccae43ec40 { ws = 0x7fccae43ee58 { id = "wrk", {s,f,r,e} = {0x7fccae43e440,0x7fccae43e440,(nil),+2048}, }, VCL::method = 0x0, VCL::return = lookup, }, ws = 0x7faac51291b8 { id = "req", {s,f,r,e} = {0x7faac512b010,+864,+57360,+57360}, }, http[req] = { ws = 0x7faac51291b8[req] "GET", "/1f68ddf2-6856-4f33-9f31-ea4f7e442f51/large/segment000087.ts", "HTTP/1.1", "Host: archive.example.com", "X-Playback-Session-Id: 74938B44-9611-4FCD-836B-22D0D88EF0CA", "Accept: */*", "Connection: keep-alive", "User-Agent: AppleCoreMedia/1.0.0.11D167 (iPhone; U; CPU OS 7_1 like Mac OS X; sv_se)", "X-Forwarded-For: 123.456.789.0", }, vcl = { srcname = { "input", "Builtin", "example-acl.vcl", "example-backend.vcl", "example-synth.vcl", }, }, }, }}} Still don't know how to reproduce except just running Varnish and waiting for a couple of hours. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 25 18:15:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Jun 2014 18:15:35 -0000 Subject: [Varnish] #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match Message-ID: <046.4c2cb40392bce428250c0ea1ab787adc@varnish-cache.org> #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match ----------------------+-------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.1 | Severity: normal Keywords: | ----------------------+-------------------- In 4.0.1, "VMOD ABI version requirements are relaxed" doesn't seem to be working as intended. The vcc_ParseImport() function in lib/libvcc/vcc_vmod.c is still checking for an exact string match between vmd->abi and VMOD_ABI_Version. {{{ if (strcmp(vmd->abi, VMOD_ABI_Version) != 0) { VSB_printf(tl->sb, "Incompatible VMOD %.*s\n", PF(mod)); VSB_printf(tl->sb, "\tFile name: %s\n", fn); VSB_printf(tl->sb, "\tABI mismatch, expected <%s>, got <%s>\n", VMOD_ABI_Version, vmd->abi); vcc_ErrWhere(tl, mod); return; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 26 02:01:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jun 2014 02:01:53 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.af159cb91734ead2938653c00d124262@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by shing6326): Sorry since I'm using varnish v4.0.1, so I think I better to create another ticket for the issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 26 02:14:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jun 2014 02:14:30 -0000 Subject: [Varnish] #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: Message-ID: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: ---------------------------------+---------------------- Reporter: shing6326 | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.1 | Severity: normal Keywords: | ---------------------------------+---------------------- Last panic at: Wed, 25 Jun 2014 17:27:33 GMT Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x431255: /usr/sbin/varnishd() [0x431255] 0x434df0: /usr/sbin/varnishd() [0x434df0] 0x436621: /usr/sbin/varnishd(CNT_Request+0x271) [0x436621] 0x42ba23: /usr/sbin/varnishd(HTTP1_Session+0x5b3) [0x42ba23] 0x43a138: /usr/sbin/varnishd() [0x43a138] 0x433d54: /usr/sbin/varnishd(Pool_Work_Thread+0x354) [0x433d54] 0x4462a8: /usr/sbin/varnishd() [0x4462a8] 0x3ac08079d1: /lib64/libpthread.so.0() [0x3ac08079d1] 0x3ac04e8b5d: /lib64/libc.so.6(clone+0x6d) [0x3ac04e8b5d] req = 0x7fcc880e9020 { sp = 0x7fcc7f92a9a0, vxid = 1158170269, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fcc7f92a9a0 { fd = 1586, vxid = 87960717, client = 61.15.234.154 49440, step = S_STP_WORKING, }, worker = 0x7fcc74bdac10 { ws = 0x7fcc74bdae28 { id = "wrk", {s,f,r,e} = {0x7fcc74bda400,0x7fcc74bda400,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7fcc880e91b8 { id = "req", {s,f,r,e} = {0x7fcc880eb010,+632,(nil),+57360}, }, http[req] = { ws = 0x7fcc880e91b8[req] "GET", "/ls/feeds/?/event_get", "HTTP/1.1", "Host: xxx.net", "Connection: keep-alive", "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36", "Origin: http://xxx.com", "Accept: */*", "Referer: http://xxx.com/live/43/", "Accept-Language: en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4,zh- CN;q=0.2,ja;q=0.2", "If-None-Match: "d8edfda29fd0c8e1b9f472b6a18deb1fd33451ad"", "If-Modified-Since: Wed, 25 Jun 2014 17:26:38 GMT", "X-Forwarded-For: 61.15.234.154", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7fcc72c27800 { vxid = 2233786712, http[obj] = { ws = 0x7fcc84bed268[] "HTTP/1.1", "200", "OK", "Server: nginx/1.2.1", "Content-Type: application/json; charset=UTF-8", "X-Powered-By: PHP/5.4.4-14+deb7u11", "Etag: "4dc539cdc18409dac8fe9f0e0991d638083fbefa"", "Cache-Control: public,max-age=2", "Expires: Wed, 25 Jun 2014 17:26:56 GMT", "Last-Modified: Wed, 25 Jun 2014 17:26:49 GMT", "Access-Control-Allow-Origin: *", "Access-Control-Allow-Methods: GET", "Access-Control-Allow-Headers: origin, x-requested-with, content- type, accept", "Access-Control-Max-Age: 86400", "X-Fn-Web: xxx.com", "Content-Encoding: gzip", "X-Srv: yyy.com", "X-Sbe: z5fn7", "X-Varnish: 1459020872 1459019162", "Via: 1.1 varnish", "X-Varnish-IP: x.x.x.x", "X-Varnish: 586649592 586646228", "Via: 1.1 varnish", "Date: Wed, 25 Jun 2014 17:26:40 GMT", "X-Varnish: 8455419", "Via: 1.1 varnish (v4)", "X-Varnish: 2903666671 2903663776", "Via: 1.1 varnish", "X-Varnish: 35636137", "Via: 1.1 varnish (v4)", "X-Varnish: 586647830 586646228", "Via: 1.1 varnish", "X-Varnish: 34058632", "Via: 1.1 varnish (v4)", "X-Varnish: 1744788186", "Via: 1.1 varnish", "X-Varnish: 37206824", "Via: 1.1 varnish (v4)", }, len = 14044, store = { 14044 { 1f 8b 08 00 00 00 00 00 00 03 ed 5d 69 73 db c6 |...........]is..| b2 fd 2b 2c 7e 96 63 ec 8b be 49 8a 62 3b 96 62 |..+,~.c...I.b;.b| 97 68 27 37 ef 3a e5 82 48 50 e2 33 45 ea 71 b1 |.h'7.:..HP.3E.q.| af ed ca 7f 7f a7 7b 06 83 01 08 02 43 09 94 e4 |......{.....C...| [13980 more] }, }, }, }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 26 07:07:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jun 2014 07:07:58 -0000 Subject: [Varnish] #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: In-Reply-To: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> References: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> Message-ID: <062.23d96059fe21526cd38583138dcfb7a6@varnish-cache.org> #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: -----------------------+---------------------------------- Reporter: shing6326 | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------- Comment (by scoof): Looks like a dup of #1522 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 26 13:49:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jun 2014 13:49:07 -0000 Subject: [Varnish] #1540: Return pipe from vcl_backend_response Message-ID: <044.79d7e512784b50c1438639acd5f5652c@varnish-cache.org> #1540: Return pipe from vcl_backend_response --------------------+------------------------- Reporter: joakim | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | --------------------+------------------------- Would it be possible to enable return (pipe) from vcl_backend_response. At the moment large, uncacheable, files can eat up all the memory on a machine by using transient storage when delivering to a client. In Varnish 3.0 it was possible to check the Content-Length and set a req header in vcl_fetch, then return (restart) and in vcl_recv do a return (pipe) if the req header is set. In Varnish 4.0 this doesn't seem possible due to the split nature of a request. When restarting in vcl_deliver the object is still being fetched into transient storage by the backend worker while a new pipe session is started for the restarted request. It would be nice to be able to switch to pipe mode immediately in vcl_backend_response to avoid out of memory conditions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 26 21:51:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jun 2014 21:51:56 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.46000a5bffa70a4f6ef97d1a4c235bae@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): GNU readline works as expected. The readline emulation in libedit looks incomplete. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 27 17:42:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Jun 2014 17:42:40 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.439dbb8270c0e8844135010798517f37@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): A bit more of digging reveals this bug depends on the libedit2 version. Works fine with 2.11-20080614-3ubuntu2, fails with 3.1-20130712-2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jun 29 00:00:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 29 Jun 2014 00:00:33 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.229b2534123d6f52d3555a09f1d92259@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): Workaround attached. Tested with gnu readline and libedit 3.1. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 04:17:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 04:17:03 -0000 Subject: [Varnish] #1541: Permission problem on Mac OS X Message-ID: <049.4fcba81c7503676e58bc58a3e808ec19@varnish-cache.org> #1541: Permission problem on Mac OS X ---------------------------------+---------------------- Reporter: huguesalary | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: | ---------------------------------+---------------------- Hi there, I just switched to varnish 4 from varnish 3.0.5, on Mac OS X 10.9.2. After a few trial-error I finally got a VCL that varnish 4 likes. However, I now get this error when trying to start varnish: {{{ $ sudo varnishd -a 127.0.0.1:80 -T 127.0.0.1 -s malloc,256M -p http_req_hdr_len=32768 -f /usr/local/etc/varnish/magento.vcl Message from C-compiler: ld: can't open output file for writing './vcl.Qw7naIoS.so.ld_FCIJx5', errno=13 for architecture x86_64 clang: error: unable to remove file: Permission denied clang: error: linker command failed with exit code 1 (use -v to see invocation) Running C-compiler failed, exit 1 VCL compilation failed }}} The directory created by varnishd has the following permissions after creation: drwxr-xr-x 2 root admin 68 Jun 29 21:14 Hugues-Alarys-MacBook- Pro-2.local Doing a chmod 777 on the directory containing the compiled VCL allows varnishd to start. My guess is that when varnishd starts, it switches from root to nobody, and nobody doesn't have the right permissions for that directory. Not sure what changed between 3.0.5 and 4.0. Maybe the VCL compilation is not carried by root anymore but by nobody? For security reasons? I haven't checked if this bug is present in 4.0.1 that has been release a few days ago. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 10:43:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 10:43:38 -0000 Subject: [Varnish] #1534: is groff really required for varnish 4+ ? In-Reply-To: <049.1ec3b1ed6de1bca9c9bcd13d03edaaa2@varnish-cache.org> References: <049.1ec3b1ed6de1bca9c9bcd13d03edaaa2@varnish-cache.org> Message-ID: <064.24eb4c69bbc7c911cad95d42262e8f39@varnish-cache.org> #1534: is groff really required for varnish 4+ ? -------------------------+----------------------- Reporter: g.gerritsen | Owner: lkarsten Type: defect | Status: new Priority: low | Milestone: Component: build | Version: trunk Severity: trivial | Resolution: Keywords: | -------------------------+----------------------- Changes (by martin): * owner: => lkarsten Comment: Packaging related -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 10:44:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 10:44:29 -0000 Subject: [Varnish] #1515: Asset error in HTTP1_Write In-Reply-To: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> References: <049.7f5626ef4cfe29e37098f0afeb4551e1@varnish-cache.org> Message-ID: <064.06c4c6da66c9ca4c74495cfab7879298@varnish-cache.org> #1515: Asset error in HTTP1_Write -------------------------+--------------------- Reporter: g.gerritsen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: We're in the process of adding better diagnostics and handling to workspaces. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 10:55:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 10:55:45 -0000 Subject: [Varnish] #1532: Incorrect representation when using reals (was: Incorrectly rounding when using reals) In-Reply-To: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> References: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> Message-ID: <058.df58d210ba229a9c6286c08369968159@varnish-cache.org> #1532: Incorrect representation when using reals ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 11:20:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 11:20:33 -0000 Subject: [Varnish] #1536: 4.0.1 delivers instead of fetch In-Reply-To: <054.8bbdb691fb2e0cb7ec38ca285b78d3e8@varnish-cache.org> References: <054.8bbdb691fb2e0cb7ec38ca285b78d3e8@varnish-cache.org> Message-ID: <069.ebf862dbebc68e8aa2f3c8aab4e6fc95@varnish-cache.org> #1536: 4.0.1 delivers instead of fetch ------------------------------+---------------------- Reporter: little_butterfly | Owner: Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: invalid Keywords: must-revalidate | ------------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: Hi, Varnish doesn't take any specific action with regard to must-revalidate attributes in the Cache-Control headers. So the behavior you are seeing is the expected result, where the default grace (10s) is kicking in to answer the client immediately instead of waiting for the backend fetch to complete before answering the client. You could explicitly set grace to 0s when there's a must-revalidate attribute present in your vcl_backend_response method to change this behavior (or do return(pass); in vcl_recv for matched URL's). Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 11:43:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 11:43:57 -0000 Subject: [Varnish] #1540: Return pipe from vcl_backend_response In-Reply-To: <044.79d7e512784b50c1438639acd5f5652c@varnish-cache.org> References: <044.79d7e512784b50c1438639acd5f5652c@varnish-cache.org> Message-ID: <059.2b242a99f0c3c39d7f772aa186499f07@varnish-cache.org> #1540: Return pipe from vcl_backend_response -------------------------+---------------------- Reporter: joakim | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: At the moment this isn't possible to achieve, but we would like to add some feature for streaming passes to limit the space used for the streaming buffer. As we do not use the bug tracker for feature requests, I have moved this to the future_ wiki pages. https://www.varnish- cache.org/trac/wiki/Future_Feature#Limitedstreamingpassbuffersize Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 11:53:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 11:53:01 -0000 Subject: [Varnish] #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: In-Reply-To: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> References: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> Message-ID: <062.5d52ae45387f29d318118bb7a190e5e7@varnish-cache.org> #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: -----------------------+---------------------------------- Reporter: shing6326 | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------- Description changed by martin: Old description: > Last panic at: Wed, 25 Jun 2014 17:27:33 GMT > Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: > Condition((oc->exp_flags & (1<<7)) == 0) not true. > errno = 104 (Connection reset by peer) > thread = (cache-worker) > ident = > Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x431255: /usr/sbin/varnishd() [0x431255] > 0x434df0: /usr/sbin/varnishd() [0x434df0] > 0x436621: /usr/sbin/varnishd(CNT_Request+0x271) [0x436621] > 0x42ba23: /usr/sbin/varnishd(HTTP1_Session+0x5b3) [0x42ba23] > 0x43a138: /usr/sbin/varnishd() [0x43a138] > 0x433d54: /usr/sbin/varnishd(Pool_Work_Thread+0x354) [0x433d54] > 0x4462a8: /usr/sbin/varnishd() [0x4462a8] > 0x3ac08079d1: /lib64/libpthread.so.0() [0x3ac08079d1] > 0x3ac04e8b5d: /lib64/libc.so.6(clone+0x6d) [0x3ac04e8b5d] > req = 0x7fcc880e9020 { > sp = 0x7fcc7f92a9a0, vxid = 1158170269, step = R_STP_LOOKUP, > req_body = R_BODY_NONE, > restarts = 0, esi_level = 0 > sp = 0x7fcc7f92a9a0 { > fd = 1586, vxid = 87960717, > client = 61.15.234.154 49440, > step = S_STP_WORKING, > }, > worker = 0x7fcc74bdac10 { > ws = 0x7fcc74bdae28 { > id = "wrk", > {s,f,r,e} = {0x7fcc74bda400,0x7fcc74bda400,(nil),+2048}, > }, > VCL::method = 0x0, > VCL::return = deliver, > }, > ws = 0x7fcc880e91b8 { > id = "req", > {s,f,r,e} = {0x7fcc880eb010,+632,(nil),+57360}, > }, > http[req] = { > ws = 0x7fcc880e91b8[req] > "GET", > "/ls/feeds/?/event_get", > "HTTP/1.1", > "Host: xxx.net", > "Connection: keep-alive", > "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 > Safari/537.36", > "Origin: http://xxx.com", > "Accept: */*", > "Referer: http://xxx.com/live/43/", > "Accept-Language: en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4,zh- > CN;q=0.2,ja;q=0.2", > "If-None-Match: "d8edfda29fd0c8e1b9f472b6a18deb1fd33451ad"", > "If-Modified-Since: Wed, 25 Jun 2014 17:26:38 GMT", > "X-Forwarded-For: 61.15.234.154", > "Accept-Encoding: gzip", > }, > vcl = { > srcname = { > "input", > "Builtin", > }, > }, > obj (REQ) = 0x7fcc72c27800 { > vxid = 2233786712, > http[obj] = { > ws = 0x7fcc84bed268[] > "HTTP/1.1", > "200", > "OK", > "Server: nginx/1.2.1", > "Content-Type: application/json; charset=UTF-8", > "X-Powered-By: PHP/5.4.4-14+deb7u11", > "Etag: "4dc539cdc18409dac8fe9f0e0991d638083fbefa"", > "Cache-Control: public,max-age=2", > "Expires: Wed, 25 Jun 2014 17:26:56 GMT", > "Last-Modified: Wed, 25 Jun 2014 17:26:49 GMT", > "Access-Control-Allow-Origin: *", > "Access-Control-Allow-Methods: GET", > "Access-Control-Allow-Headers: origin, x-requested-with, content- > type, accept", > "Access-Control-Max-Age: 86400", > "X-Fn-Web: xxx.com", > "Content-Encoding: gzip", > "X-Srv: yyy.com", > "X-Sbe: z5fn7", > "X-Varnish: 1459020872 1459019162", > "Via: 1.1 varnish", > "X-Varnish-IP: x.x.x.x", > "X-Varnish: 586649592 586646228", > "Via: 1.1 varnish", > "Date: Wed, 25 Jun 2014 17:26:40 GMT", > "X-Varnish: 8455419", > "Via: 1.1 varnish (v4)", > "X-Varnish: 2903666671 2903663776", > "Via: 1.1 varnish", > "X-Varnish: 35636137", > "Via: 1.1 varnish (v4)", > "X-Varnish: 586647830 586646228", > "Via: 1.1 varnish", > "X-Varnish: 34058632", > "Via: 1.1 varnish (v4)", > "X-Varnish: 1744788186", > "Via: 1.1 varnish", > "X-Varnish: 37206824", > "Via: 1.1 varnish (v4)", > }, > len = 14044, > store = { > 14044 { > 1f 8b 08 00 00 00 00 00 00 03 ed 5d 69 73 db c6 > |...........]is..| > b2 fd 2b 2c 7e 96 63 ec 8b be 49 8a 62 3b 96 62 > |..+,~.c...I.b;.b| > 97 68 27 37 ef 3a e5 82 48 50 e2 33 45 ea 71 b1 > |.h'7.:..HP.3E.q.| > af ed ca 7f 7f a7 7b 06 83 01 08 02 43 09 94 e4 > |......{.....C...| > [13980 more] > }, > }, > }, > }, New description: {{{ Last panic at: Wed, 25 Jun 2014 17:27:33 GMT Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: Condition((oc->exp_flags & (1<<7)) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) ident = Linux,2.6.32-431.17.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x431255: /usr/sbin/varnishd() [0x431255] 0x434df0: /usr/sbin/varnishd() [0x434df0] 0x436621: /usr/sbin/varnishd(CNT_Request+0x271) [0x436621] 0x42ba23: /usr/sbin/varnishd(HTTP1_Session+0x5b3) [0x42ba23] 0x43a138: /usr/sbin/varnishd() [0x43a138] 0x433d54: /usr/sbin/varnishd(Pool_Work_Thread+0x354) [0x433d54] 0x4462a8: /usr/sbin/varnishd() [0x4462a8] 0x3ac08079d1: /lib64/libpthread.so.0() [0x3ac08079d1] 0x3ac04e8b5d: /lib64/libc.so.6(clone+0x6d) [0x3ac04e8b5d] req = 0x7fcc880e9020 { sp = 0x7fcc7f92a9a0, vxid = 1158170269, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fcc7f92a9a0 { fd = 1586, vxid = 87960717, client = 61.15.234.154 49440, step = S_STP_WORKING, }, worker = 0x7fcc74bdac10 { ws = 0x7fcc74bdae28 { id = "wrk", {s,f,r,e} = {0x7fcc74bda400,0x7fcc74bda400,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7fcc880e91b8 { id = "req", {s,f,r,e} = {0x7fcc880eb010,+632,(nil),+57360}, }, http[req] = { ws = 0x7fcc880e91b8[req] "GET", "/ls/feeds/?/event_get", "HTTP/1.1", "Host: xxx.net", "Connection: keep-alive", "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36", "Origin: http://xxx.com", "Accept: */*", "Referer: http://xxx.com/live/43/", "Accept-Language: en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4,zh- CN;q=0.2,ja;q=0.2", "If-None-Match: "d8edfda29fd0c8e1b9f472b6a18deb1fd33451ad"", "If-Modified-Since: Wed, 25 Jun 2014 17:26:38 GMT", "X-Forwarded-For: 61.15.234.154", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7fcc72c27800 { vxid = 2233786712, http[obj] = { ws = 0x7fcc84bed268[] "HTTP/1.1", "200", "OK", "Server: nginx/1.2.1", "Content-Type: application/json; charset=UTF-8", "X-Powered-By: PHP/5.4.4-14+deb7u11", "Etag: "4dc539cdc18409dac8fe9f0e0991d638083fbefa"", "Cache-Control: public,max-age=2", "Expires: Wed, 25 Jun 2014 17:26:56 GMT", "Last-Modified: Wed, 25 Jun 2014 17:26:49 GMT", "Access-Control-Allow-Origin: *", "Access-Control-Allow-Methods: GET", "Access-Control-Allow-Headers: origin, x-requested-with, content- type, accept", "Access-Control-Max-Age: 86400", "X-Fn-Web: xxx.com", "Content-Encoding: gzip", "X-Srv: yyy.com", "X-Sbe: z5fn7", "X-Varnish: 1459020872 1459019162", "Via: 1.1 varnish", "X-Varnish-IP: x.x.x.x", "X-Varnish: 586649592 586646228", "Via: 1.1 varnish", "Date: Wed, 25 Jun 2014 17:26:40 GMT", "X-Varnish: 8455419", "Via: 1.1 varnish (v4)", "X-Varnish: 2903666671 2903663776", "Via: 1.1 varnish", "X-Varnish: 35636137", "Via: 1.1 varnish (v4)", "X-Varnish: 586647830 586646228", "Via: 1.1 varnish", "X-Varnish: 34058632", "Via: 1.1 varnish (v4)", "X-Varnish: 1744788186", "Via: 1.1 varnish", "X-Varnish: 37206824", "Via: 1.1 varnish (v4)", }, len = 14044, store = { 14044 { 1f 8b 08 00 00 00 00 00 00 03 ed 5d 69 73 db c6 |...........]is..| b2 fd 2b 2c 7e 96 63 ec 8b be 49 8a 62 3b 96 62 |..+,~.c...I.b;.b| 97 68 27 37 ef 3a e5 82 48 50 e2 33 45 ea 71 b1 |.h'7.:..HP.3E.q.| af ed ca 7f 7f a7 7b 06 83 01 08 02 43 09 94 e4 |......{.....C...| [13980 more] }, }, }, }, }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:03:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:03:51 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.d30c0382f97d3384002fff600984c8a3@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by lkarsten): Tested the patch now, and it solves the issue on my setup. Also ran it on an older EL5 system, where the bug doesn't exist, and no ill effects were seen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:13:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:13:17 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.4d0b68fef7ae69fe6bf71b3b3c4bf675@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+--------------------------------------------- Reporter: lkarsten | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * status: new => closed * owner: => Federico G. Schwindt * resolution: => fixed Comment: In [161b42bb9b407e0cb4a8e86c80465ffdbfadae4c]: {{{ #!CommitTicketReference repository="" revision="161b42bb9b407e0cb4a8e86c80465ffdbfadae4c" Workaround a problem in recent libedit versions Reinstall the readline handler when we are called in order to clear the input line. Tested in a variety of versions by scn and myself. Fixes #1531 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:16:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:16:23 -0000 Subject: [Varnish] #1537: Varnish .deb for wheezy is not compiled against/does not depend on jemalloc In-Reply-To: <044.e095537cfdf43d97bf18575d45c24ffd@varnish-cache.org> References: <044.e095537cfdf43d97bf18575d45c24ffd@varnish-cache.org> Message-ID: <059.8019b3899ac3ed24231a084f4ab17be0@varnish-cache.org> #1537: Varnish .deb for wheezy is not compiled against/does not depend on jemalloc -----------------------+----------------------- Reporter: joakim | Owner: lkarsten Type: defect | Status: new Priority: high | Milestone: Component: packaging | Version: 4.0.1 Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Changes (by fgsch): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:23:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:23:28 -0000 Subject: [Varnish] #1532: Incorrect representation when using reals In-Reply-To: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> References: <043.a249b8fcc6010c4373cabb40f415c46e@varnish-cache.org> Message-ID: <058.a043a67577301dc53a18f5affc0fbc0a@varnish-cache.org> #1532: Incorrect representation when using reals ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * status: new => closed * owner: => Federico G. Schwindt * resolution: => fixed Comment: In [5e1e35a5ff5f984e2a8a85c9b1d6b5e44b5caa07]: {{{ #!CommitTicketReference repository="" revision="5e1e35a5ff5f984e2a8a85c9b1d6b5e44b5caa07" Fix incorrect representation when using reals Fixes #1532 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:32:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:32:26 -0000 Subject: [Varnish] #1531: varnishadm libedit does not clean command line In-Reply-To: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> References: <046.51a6851cfde1284fd5dd42c1f2fa15d3@varnish-cache.org> Message-ID: <061.269fce6071cc2cf86677ea61cef0677a@varnish-cache.org> #1531: varnishadm libedit does not clean command line ------------------------+--------------------------------------------- Reporter: lkarsten | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------- Comment (by Federico G. Schwindt ): In [2c0f1ba2cba0e888ae089394fca5c4b8e0ddd528]: {{{ #!CommitTicketReference repository="" revision="2c0f1ba2cba0e888ae089394fca5c4b8e0ddd528" Workaround a problem in recent libedit versions Reinstall the readline handler when we are called in order to clear the input line. Tested in a variety of versions by scn and myself. Fixes #1531 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 12:56:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 12:56:11 -0000 Subject: [Varnish] #1541: Permission problem on Mac OS X In-Reply-To: <049.4fcba81c7503676e58bc58a3e808ec19@varnish-cache.org> References: <049.4fcba81c7503676e58bc58a3e808ec19@varnish-cache.org> Message-ID: <064.3317119ad42216fdfdd5485d2577ac16@varnish-cache.org> #1541: Permission problem on Mac OS X -------------------------+---------------------------------- Reporter: huguesalary | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: duplicate Keywords: | -------------------------+---------------------------------- Changes (by fgsch): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1521. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 30 17:24:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jun 2014 17:24:27 -0000 Subject: [Varnish] #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org> Message-ID: <065.0646d4d1b9b68f5705d9d68b407fe29c@varnish-cache.org> #1506: Make better use of Content-Length information: Avoid chunked responses, more control over Range handling --------------------------+---------------------------------- Reporter: DonMacAskill | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: critical | Resolution: Keywords: | --------------------------+---------------------------------- Changes (by slink): * status: assigned => new * owner: slink => phk Comment: see https://www.varnish-cache.org/lists/pipermail/varnish- dev/2014-June/007878.html -- Ticket URL: Varnish The Varnish HTTP Accelerator