From varnish-bugs at varnish-cache.org Mon Dec 1 08:07:36 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 08:07:36 -0000 Subject: [Varnish] #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.cc6e08f31ba150d860a165412f5700bc@varnish-cache.org> #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): I have attached a vtc exposing the issue. Side note: it took me some time to spot the fact that this really is the right trigger tue to `sigsegv_handler=on` beging set by `varnishtest` by default - which, in this case, hides the panic for reasons which I have not yet understood. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 08:08:37 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 08:08:37 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. (was: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true.) In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.a039167d8ffff79567c2130c0a3782c2@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 08:10:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 08:10:18 -0000 Subject: [Varnish] #1639: sigsegv_handler can hide panic Message-ID: <043.974becac8432bbf63f8ef8d19918851a@varnish-cache.org> #1639: sigsegv_handler can hide panic ----------------------+------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- see #1638 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 08:55:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 08:55:06 -0000 Subject: [Varnish] #1639: sigsegv_handler can hide panic In-Reply-To: <043.974becac8432bbf63f8ef8d19918851a@varnish-cache.org> References: <043.974becac8432bbf63f8ef8d19918851a@varnish-cache.org> Message-ID: <058.c248c576a0dfdb55bb5a58f94a07d3ce@varnish-cache.org> #1639: sigsegv_handler can hide panic ----------------------+------------------------------------------ Reporter: slink | Owner: Nils Goroll Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+------------------------------------------ Changes (by Nils Goroll ): * status: new => closed * owner: => Nils Goroll * resolution: => fixed Comment: In [6fbf247c9b12b991c030a1e4f4942818e4c0927d]: {{{ #!CommitTicketReference repository="" revision="6fbf247c9b12b991c030a1e4f4942818e4c0927d" Restore the default SIGSEGV handler during pan_ic Leaving it enabled could hide panics. Fixes #1639 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 09:47:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 09:47:12 -0000 Subject: [Varnish] #1640: FetchError c Could not get storage Message-ID: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> #1640: FetchError c Could not get storage -------------------------+-------------------- Reporter: neverexists | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.5 | Severity: normal Keywords: | -------------------------+-------------------- With varnish-3.0.5 i setup some files (like pdf) to not be saved to cache with hit_for_pass and serve them directly to the client. Sometimes i have "FetchError c Could not get storage" error when Varnish can't free enought space from storage backend. The question is : Why Varnish try to save the object in the cache even if i set it with hit_for_pass to don't do that ? Log: 17 Hash c /test.pdf 17 Hash c www.mytest.com 17 VCL_return c hash 17 VCL_call c pass pass 17 Backend c 30 mytest mytest 17 TTL c 830726718 RFC 0 -1 -1 1417425694 0 1417425693 280299600 0 17 VCL_call c fetch 17 TTL c 830726718 VCL 604800 -1 -1 1417425694 -0 17 TTL c 830726718 VCL 604800 86400 -1 1417425694 -0 17 VCL_return c hit_for_pass 17 ObjProtocol c HTTP/1.1 17 ObjResponse c OK 17 ObjHeader c Date: Mon, 01 Dec 2014 09:21:33 GMT 17 ObjHeader c Server: Apache/2.2.22 (Linux/SUSE) 17 ObjHeader c X-Powered-By: PHP/5.3.15 17 ObjHeader c Last-Modified: Mon, 01 Dec 2014 09:21:33 GMT 17 ObjHeader c ETag: "1417425693" 17 ObjHeader c Content-Length: 5866600 17 ObjHeader c Content-Type: application/pdf 17 FetchError c Could not get storage 17 VCL_call c error Thanks for the support -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 09:59:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 09:59:02 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.3e82d2fac02a54fd74270b025f384715@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 10:02:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 10:02:34 -0000 Subject: [Varnish] #1640: FetchError c Could not get storage In-Reply-To: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> References: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> Message-ID: <064.2cb3577f848d3662007b8f8d9b241d3d@varnish-cache.org> #1640: FetchError c Could not get storage -------------------------+---------------------- Reporter: neverexists | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => invalid Comment: This is not a bug. Please use the varnish-misc at varnish-cache.org email list for questions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 10:11:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 10:11:01 -0000 Subject: [Varnish] #1640: FetchError c Could not get storage In-Reply-To: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> References: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> Message-ID: <064.66f75797379bcaac9e8d828f8bc5b421@varnish-cache.org> #1640: FetchError c Could not get storage -------------------------+---------------------- Reporter: neverexists | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Comment (by neverexists): Replying to [comment:1 lkarsten]: > This is not a bug. Please use the varnish-misc at varnish-cache.org email list for questions. I send the question also to varnish-misc at varnish-cache.org but if i tell Varnish to hit_for_pass and so to not cache and Varnish try to save the object in the cache it seems a bug to me . Or i'm missing something ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 12:11:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 12:11:13 -0000 Subject: [Varnish] #1637: Assert error in VFP_Fetch_Body() In-Reply-To: <045.21ddee12af57707010d10fb844941331@varnish-cache.org> References: <045.21ddee12af57707010d10fb844941331@varnish-cache.org> Message-ID: <060.3732f76ebebc33bb5d0ac87f3c365c00@varnish-cache.org> #1637: Assert error in VFP_Fetch_Body() --------------------------+-------------------- Reporter: llavaud | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: major | Resolution: Keywords: Assert error | --------------------------+-------------------- Changes (by daghf): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 12:19:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 12:19:22 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.b8e58b14ea49c81c20c8f535db100abb@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+-------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: lurker | ----------------------+-------------------- Comment (by lkarsten): Discussed during bugwash today. Did you reduce ban_lurker_sleep? We'll need to set up something to reproduce this to figure out what is happening. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 12:28:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 12:28:38 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.5f06f4e846a25235588fc91348f20855@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+-------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: lurker | ----------------------+-------------------- Comment (by Sesse): Yes, I've tried reducing ban_lurker_sleep. From the original bug report: ?Making the ban lurker wake up more often does not seem to help anything; the ban count still goes up and never seems to go down (at all).? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 13:05:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 13:05:49 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() Message-ID: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: major Keywords: assert error | --------------------------+---------------------- Hello, I am using varnish trunk on a debian wheezy server. The varnish child regularly died with the following error log: Dec 1 14:00:22 webcache14 varnishd[951953]: Child (951972) Panic message: Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 373: Condition((bo->do_esi) == 0) not true. thread = (cache-worker) version = varnish-trunk revision fb25963 ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x434424: pan_ic+0x134 0x423186: vbf_stp_startfetch+0x936 0x423c7a: vbf_fetch_thread+0xaba 0x436c37: Pool_Work_Thread+0x357 0x449ac3: WRK_Thread+0x103 0x4359bb: pool_thread+0x2b 0x7f7272012b50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f7272012b50] 0x7f7271d5c7bd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f7271d5c7bd] busyobj = 0x7f5955ab8020 { ws = 0x7f5955ab80e0 { id = "bo", {s,f,r,e} = {0x7f5955ab9fa0,+8456,(nil),+254072}, }, refcnt = 2 retries = 1 failed = 0 state = 1 is_do_esi is_do_gzip is_do_stream bodystatus = 2 (chunked), }, http[bereq] = { ws = 0x7f5955ab80e0[bo] "GET", "/myuri/", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3", "Referer: http://myhost/myuri/", "Host: myhost", "Surrogate-Capability: abc=ESI/1.0", "X-Forwarded-For: 2.6.130.156, 2.6.130.156", "Cookie: xtvrn=$522534$; xtan=-; xtant=1; testcookie=123; A2DCAPPV2=114546%3A1417438853%3A88849054; A2DCAPPVBD2=114546%3A1417438853%3A88849054; ", "X-Varnish: 163843", "X-Varnish: 393217", }, http[beresp] = { ws = 0x7f5955ab80e0[bo] "HTTP/1.1", "200", "OK", "Date: Mon, 01 Dec 2014 13:00:21 GMT", "Server: Apache", -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 13:07:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 13:07:45 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() In-Reply-To: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> References: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> Message-ID: <060.bb2e8f028e8c19a3e7b46a072d6fc524@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+-------------------- Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+-------------------- Comment (by llavaud): Hello, I am using varnish trunk on a debian wheezy server. The varnish child regularly died with the following error log: {{{ Dec 1 14:00:22 webcache14 varnishd[951953]: Child (951972) Panic message: Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 373: Condition((bo->do_esi) == 0) not true. thread = (cache-worker) version = varnish-trunk revision fb25963 ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x434424: pan_ic+0x134 0x423186: vbf_stp_startfetch+0x936 0x423c7a: vbf_fetch_thread+0xaba 0x436c37: Pool_Work_Thread+0x357 0x449ac3: WRK_Thread+0x103 0x4359bb: pool_thread+0x2b 0x7f7272012b50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f7272012b50] 0x7f7271d5c7bd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f7271d5c7bd] busyobj = 0x7f5955ab8020 { ws = 0x7f5955ab80e0 { id = "bo", {s,f,r,e} = {0x7f5955ab9fa0,+8456,(nil),+254072}, }, refcnt = 2 retries = 1 failed = 0 state = 1 is_do_esi is_do_gzip is_do_stream bodystatus = 2 (chunked), }, http[bereq] = { ws = 0x7f5955ab80e0[bo] "GET", "/myuri/", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3", "Referer: http://myhost/myuri/", "Host: myhost", "Surrogate-Capability: abc=ESI/1.0", "X-Forwarded-For: 2.6.130.156, 2.6.130.156", "Cookie: xtvrn=$522534$; xtan=-; xtant=1; testcookie=123; A2DCAPPV2=114546%3A1417438853%3A88849054; A2DCAPPVBD2=114546%3A1417438853%3A88849054; ", "X-Varnish: 163843", "X-Varnish: 393217", }, http[beresp] = { ws = 0x7f5955ab80e0[bo] "HTTP/1.1", "200", "OK", "Date: Mon, 01 Dec 2014 13:00:21 GMT", "Server: Apache",}}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 16:26:36 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 16:26:36 -0000 Subject: [Varnish] #1642: Assert error in VGZ_Ibuf() Message-ID: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> #1642: Assert error in VGZ_Ibuf() --------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: major Keywords: assert error | --------------------------+---------------------- {{{ Dec 1 16:59:01 webcache02 varnishd[31301]: Child (25643) Panic message: Assert error in VGZ_Ibuf(), cache/cache_gzip.c line 161: Condition((vg->vz.avail_in) == 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker) version = varnish-trunk revision fb25963 ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x434424: pan_ic+0x134 0x426724: VGZ_Ibuf+0x74 0x427ceb: VDP_gunzip+0x13b 0x41a616: VDP_bytes+0x66 0x41be33: ESI_Deliver+0x293 0x41ac15: VDP_DeliverObj+0x135 0x44dc65: V1D_Deliver+0x275 0x437ea6: cnt_deliver+0x296 0x438489: CNT_Request+0x119 0x44f47b: HTTP1_Session+0x77b req = 0x7fb4444de020 { sp = 0x7fb4455942a0, vxid = 131327, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fb4455942a0 { fd = 17, vxid = 131326, client = 91.223.84.10 42579, step = S_STP_WORKING, }, worker = 0x7fb445c14c30 { stack = {0x7fb445c15000 -> 0x7fb445c09000} ws = 0x7fb445c14e40 { id = "wrk", {s,f,r,e} = {0x7fb445c14420,0x7fb445c14420,(nil),+2040}, }, VCL::method = DELIVER, VCL::return = deliver, VCL::methods = {RECV, PASS, HASH, MISS, HIT, DELIVER, BACKEND_FETCH, BACKEND_RESPONSE}, }, ws = 0x7fb4444de1d0 { id = "req", {s,f,r,e} = {0x7fb4444dfff0,+5448,+253992,+253992}, }, http[req] = { ws = 0x7fb4444de1d0[req] "GET", "/myuri", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3", "Referer: http://myhost/myuri", "Connection: keep-alive", "Via: 1.1 D7D03D48 (IWSS)", "Host }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 17:31:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 17:31:34 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() In-Reply-To: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> References: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> Message-ID: <060.fd0b1710f809a6b93dd5f653ede77966@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+-------------------- Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+-------------------- Comment (by slink): This looks a bit like #1638. We should probably collapse these two bugs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 17:32:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 17:32:19 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.1cebba67c36537a609cfaa138c90964e@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): #1641 looks similar. We should probably modify the test to cover this case as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 17:35:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 17:35:59 -0000 Subject: [Varnish] #1640: FetchError c Could not get storage In-Reply-To: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> References: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> Message-ID: <064.d76628949a6907e40a5f184112fe7936@varnish-cache.org> #1640: FetchError c Could not get storage -------------------------+---------------------- Reporter: neverexists | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Comment (by slink): Yes, read the documentation and understand what hit `hit_for_pass` means, please. Hint: consider return(pass) in recv for URLs which you know you dont want to cache. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 17:41:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 17:41:12 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() In-Reply-To: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> References: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> Message-ID: <060.1c3bc2c07145b15feda4a3176ba4f164@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+-------------------- Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+-------------------- Comment (by slink): Can you please confirm that your VCL contains a `return(retry)` in `vcl_backend_error` ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 1 19:55:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Dec 2014 19:55:18 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() In-Reply-To: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> References: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> Message-ID: <060.bbf980750970b11ec904dd788668b800@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: duplicate Keywords: assert error | --------------------------+------------------------ Changes (by slink): * status: new => closed * resolution: => duplicate Comment: continuing in #1638 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 09:15:05 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 09:15:05 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.f2c3da2f7a3d7ce620539bba0139fd1b@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by llavaud): Replying to [comment:5 slink]: > #1641 more or less has the same root cause. Will also address it here: > {{{ > Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 373: > Condition((bo->do_esi) == 0) not true. > }}} you asked me if i have a return (retry) in backend_response and the answer is no, i just have a return (deliver) at the end -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 09:17:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 09:17:59 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.899edc21d4f91d4129416b2cb25750c4@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): Replying to [comment:6 llavaud]: > you asked me if i have a return (retry) in backend_response and the answer is no, i just have a return (deliver) at the end Actually I asked if you have a `return (retry)` in backend_'''error''' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 09:19:58 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 09:19:58 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.700858de772a688c6ba17cfc4901b60b@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): I have attached the patch I sent to -dev yesterday, feel free to test. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 09:26:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 09:26:07 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.b0d2fb8dddae52bb14e6f3019cddad4e@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by llavaud): Replying to [comment:7 slink]: > Replying to [comment:6 llavaud]: > > you asked me if i have a return (retry) in backend_response and the answer is no, i just have a return (deliver) at the end > Actually I asked if you have a `return (retry)` in backend_'''error''' yes sorry i wanted to say backend_error and not response -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 10:38:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 10:38:24 -0000 Subject: [Varnish] #1640: FetchError c Could not get storage In-Reply-To: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> References: <049.5b9c98f24b9baaa56178c58e0428be62@varnish-cache.org> Message-ID: <064.d22f9ee197e726487f1723ee7ad892e7@varnish-cache.org> #1640: FetchError c Could not get storage -------------------------+---------------------- Reporter: neverexists | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Comment (by neverexists): I already use return(pass) in recv if (req.url == ..... return (pass); } in the attachment you see it 17 VCL_return c hash 17 VCL_call c pass pass than it trigger an VCL_return c hit_for_pass The problem is that 17 FetchError c Could not get storage The storage used by hit_for_pass is the transient storage and "By default Varnish would use an unlimited malloc backend for this." I don't have any log of memory killer or kernel log about malloc's failures so the "Could not get storage" seems a very strange behaviour. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 10:52:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 10:52:45 -0000 Subject: [Varnish] #1643: corrupt range response Message-ID: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> #1643: corrupt range response --------------------------------------+---------------------- Reporter: Jay | Type: defect Status: new | Priority: normal Milestone: Later | Component: varnishd Version: trunk | Severity: normal Keywords: byte-range request range | --------------------------------------+---------------------- A client sends a get-request on a 422kbyte audiofile with the following header: {{{ Range:bytes=0- Accept:*/* Accept-Encoding:identity;q=1, *;q=0 Accept-Language:en-US,en;q=0.8,nb;q=0.6 Cache-Control:no-cache Connection:keep-alive Pragma:no-cach }}} The response from varnish however caps the size of the file to 65536 bytes: {{{ Accept-Ranges:bytes Age:0 Cache-Control:public,no-cache Connection:keep-alive Content-Length:65536 Content-Range:bytes 0-65535/65536 Content-Type:audio/mpeg Date:Tue, 02 Dec 2014 08:27:40 GMT ETag:"0297684e1ad01:0" Last-Modified:Fri, 28 Nov 2014 08:01:30 GMT Server:Microsoft-IIS/8.5 Via:1.1 varnish-v4 X-Cache:MISS X-Powered-By:ASP.NET X-Varnish:82728786 }}} It doesn't happen if I skip using varnish. Varnish trunk from 19.11.2014 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 13:19:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 13:19:07 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.ca4b4ea671e5932ab7cba1e8c567abf1@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by llavaud): Replying to [comment:8 slink]: > I have attached the patch I sent to -dev yesterday, feel free to test. it seems to be ok with the patch, thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 2 17:51:39 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Dec 2014 17:51:39 -0000 Subject: [Varnish] #1644: VMOD gets incorrect values for cache_param->vre_limits.* Message-ID: <043.a394607fa94347f8161bbaff718dfef6@varnish-cache.org> #1644: VMOD gets incorrect values for cache_param->vre_limits.* -------------------+-------------------- Reporter: geoff | Type: defect Status: new | Priority: normal Milestone: | Component: vmod Version: trunk | Severity: normal Keywords: | -------------------+-------------------- Within a VMOD, I am getting the wrong values for the fields in cache_param->vre_limits -- I consistently see match=8 and match_recursion=0. I'll be attaching minimal VMOD code to demonstrate the problem -- it does nothing but return these two values. You can see in the vtc log that 8 was returned for match and 0 for match_recursion, although param.show shows that both params are set to the defaults (10000 for both). match=8 and match_recursion=0 are the same values I saw in my real-world use case, which you can see here: https://code.uplex.de/uplex-varnish/libvmod- re/blobs/master/src/vmod_re.c#line178 The VMOD does regex matches, and I'd like to call VRE_exec() with the same params that are used elsewhere for regexen in Varnish, so that the two relevant runtime parameters are valid for the VMOD as well. VRE_exec() is called with &cache_param->vre_limits everywhere else in Varnish, but in the VMOD I have to call it with NULL in that argument, because the two values turn our to be so low that every match fails. Is there some reason why cache_param cannot be properly accessed within a VMOD? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 3 15:14:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Dec 2014 15:14:57 -0000 Subject: [Varnish] #1645: apt-get source does not work for varnish on precise and trusty Message-ID: <049.39e406a6b89a08b089f4e61c37871c86@varnish-cache.org> #1645: apt-get source does not work for varnish on precise and trusty -------------------------+----------------------- Reporter: timhilliard | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: unknown | Severity: normal Keywords: | -------------------------+----------------------- It looks like the apt repo is missing the source packages for varnish 3.0 on both precise and trusty and the varnish 4.0 source packages on lucid, precise and trusty. {{{ $ apt-get source varnish=3.0.6-1~precise Reading package lists... Building dependency tree... Reading state information... E: Ignore unavailable version '3.0.6-1' of package 'varnish' E: Unable to find a source package for varnish }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 3 17:23:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Dec 2014 17:23:41 -0000 Subject: [Varnish] #1645: apt-get source does not work for varnish on precise and trusty In-Reply-To: <049.39e406a6b89a08b089f4e61c37871c86@varnish-cache.org> References: <049.39e406a6b89a08b089f4e61c37871c86@varnish-cache.org> Message-ID: <064.7217db87ec19043acd496fd5a180b57e@varnish-cache.org> #1645: apt-get source does not work for varnish on precise and trusty -------------------------+---------------------- Reporter: timhilliard | Owner: fgsch Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+---------------------- Changes (by fgsch): * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 3 17:24:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Dec 2014 17:24:35 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.52dac2e77e728ca6fe05d4dc03e4d527@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Changes (by fgsch): * status: new => needinfo Comment: Can you please include a full varnishlog capture (client and backend) for a miss and hit? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 4 16:08:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Dec 2014 16:08:50 -0000 Subject: [Varnish] #1642: Assert error in VGZ_Ibuf() In-Reply-To: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> References: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> Message-ID: <060.fb22c93f5f1b45fe89aa83b3f6f456f2@varnish-cache.org> #1642: Assert error in VGZ_Ibuf() --------------------------+-------------------- Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+-------------------- Comment (by llavaud): I have removed the following directive from my backend_response vcl: {{{ if (beresp.http.Content-Type ~ "text/(html|plain|xml|css|javascript)|application/(x-javascript|javascript|ecmascript|rss\+xml|json|xml|xml\+rss)") { set beresp.do_gzip = true; } }}} but the problem still occur -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 8 11:57:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Dec 2014 11:57:41 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.3ffab3c13a09fb0accc696440cbcab92@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by lkarsten): What is the result you are expecting? "Content-Range: 0-65535/432128" ? Does it work as expected if you disable streaming/cut-through forwarding for this request? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 8 12:19:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Dec 2014 12:19:46 -0000 Subject: [Varnish] #1642: Assert error in VGZ_Ibuf() In-Reply-To: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> References: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> Message-ID: <060.d10f0d706cd93435ba1adb1f0238e09f@varnish-cache.org> #1642: Assert error in VGZ_Ibuf() --------------------------+--------------------- Reporter: llavaud | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 8 12:36:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Dec 2014 12:36:16 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.f6ea96b019c7681fd3bc5220e0dafe7c@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by Jay): Since the client asked for all of the data, the response should probably be 0-432127/432128, yes. The problem disappears If I enable piping on the affected URL. I'll try to get some more logs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 8 14:11:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Dec 2014 14:11:23 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.8b44e94f5ce8f513b9172c2676f7f63d@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by fgsch): This should be only an issue on miss. "Range: bytes=0-" is a bit silly. You could try disable streaming in this case: {{{ if (bereq.http.range ~ "bytes=0-$") { set beresp.do_stream = false; } }}} I still would like to see a varnishlog capture if possible for both client and backend. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 10 13:58:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Dec 2014 13:58:00 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.a6181bb4f6fabe590aa5a5b6dce2cb87@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: fixed Keywords: | -----------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: I've updated the packaging files with changes from Debian downstream. Will be in 4.0.3, when that is released. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 10 14:05:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Dec 2014 14:05:13 -0000 Subject: [Varnish] #1593: addition of checkconfig in init scripts In-Reply-To: <041.5a1f245c3cb06544d523420137c3de93@varnish-cache.org> References: <041.5a1f245c3cb06544d523420137c3de93@varnish-cache.org> Message-ID: <056.272ff3c2083a5967f1a8d321c0c585ce@varnish-cache.org> #1593: addition of checkconfig in init scripts -------------------------+---------------------------------- Reporter: Tin | Owner: lkarsten Type: enhancement | Status: closed Priority: low | Milestone: Varnish 4.0 release Component: packaging | Version: unknown Severity: minor | Resolution: fixed Keywords: | -------------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: This is in place in the Debian packaging files now. Redhat packaging files already had it, as far as I can tell. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 10 14:07:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Dec 2014 14:07:57 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.e7b0c9032809975fb1a90e0c4da360a6@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Comment (by lkarsten): I'd love some input from ssm or tfheen on this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 11 13:34:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Dec 2014 13:34:17 -0000 Subject: [Varnish] #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 Message-ID: <046.faacb661f65c2a9d5c752e6df2f5668e@varnish-cache.org> #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Fryer found this assert last night. {{{ Last panic at: Thu, 11 Dec 2014 03:51:19 GMT Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84: Condition(*sz >= 0) not true. thread = (cache-worker) version = varnish-trunk revision 263bb06 ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43bc18: pan_backtrace+0x19 0x43bfd8: pan_ic+0x298 0x429212: VFP_GetStorage+0xf0 0x427736: vbf_stp_condfetch+0x344 0x428646: vbf_fetch_thread+0x437 0x43e475: Pool_Work_Thread+0x503 0x457397: WRK_Thread+0x34d 0x43e539: pool_thread+0xab 0x7fb1d9d4de9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7fb1d9d4de9a] 0x7fb1d9a7a3fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb1d9a7a3fd] busyobj = 0x7fb1a4080a60 { ws = 0x7fb1a4080b20 { id = "bo", {s,f,r,e} = {0x7fb1a40829e0,+672,(nil),+57464}, }, refcnt = 1 retries = 0 failed = 0 state = 2 is_do_stream bodystatus = 0 (none), }, http[bereq] = { ws = 0x7fb1a4080b20[bo] "GET", "/cacheabledata/set_imagehosting1/7/image207.jpg", "HTTP/1.1", "Host: fryer1.varnish-software.com:6081", "Accept: */*", "Accept-Encoding: gzip", "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4", "X-Forwarded-For: 194.31.39.161", "If-Modified-Since: Mon, 26 Aug 2013 14:08:42 GMT", "If-None-Match: "820c47-f638-4e4da4b318d2b"", "X-Varnish: 2261195", }, http[beresp] = { ws = 0x7fb1a4080b20[bo] "HTTP/1.1", "200", "OK", "Date: Thu, 11 Dec 2014 03:51:12 GMT", "Server: Apache/2.2.22 (Ubuntu)", "ETag: "820c47-f638-4e4da4b318d2b"", "Last-Modified: Mon, 26 Aug 2013 14:08:42 GMT", "Content-Length: 63032", "Content-Type: image/jpeg", }, objcore (FETCH) = 0x7fb1440ec0f0 { refcnt = 2 flags = 0x0 objhead = 0x7fb13c0f1570 stevedore = 0x1f63420 (malloc s0) } objcore (IMS) = 0x7fb13c0bbee0 { refcnt = 3 flags = 0x0 objhead = 0x7fb13c0f1570 stevedore = 0x1f63420 (malloc s0) } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 12 10:58:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Dec 2014 10:58:43 -0000 Subject: [Varnish] #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 In-Reply-To: <046.faacb661f65c2a9d5c752e6df2f5668e@varnish-cache.org> References: <046.faacb661f65c2a9d5c752e6df2f5668e@varnish-cache.org> Message-ID: <061.d74f7b25d56097f787a8f2741a016030@varnish-cache.org> #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): This looks to be caused by an attempt to do IMS update of an object that is still streaming. Attached test case triggers an assert in the same area, caused by the source object length changing during the copy operation. Though the test case doesn't trigger the exact same assertion as the problem report, I believe it's very much the same issue. The proper fix for this I assume is to stall an IMS update backend fetch operation until the object has been fully received (or failed). Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 13 03:12:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 13 Dec 2014 03:12:02 -0000 Subject: [Varnish] #1647: Varnish 4 crashes occasionally under stress test: Assert error in cnt_lookup() Message-ID: <041.e9d6d4012b20edd5534d3b4f45c91794@varnish-cache.org> #1647: Varnish 4 crashes occasionally under stress test: Assert error in cnt_lookup() -------------------+---------------------- Reporter: wjy | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.2 | Severity: major Keywords: | -------------------+---------------------- {{{ Assert error in cnt_lookup(), cache/cache_req_fsm.c line 429: Condition((oc->flags & ((1<<9)|(1<<2))) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-431.23.3.el6.x86_64,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed] 0x43b7fd: /usr/sbin/varnishd() [0x43b7fd] 0x440c22: /usr/sbin/varnishd() [0x440c22] 0x442db9: /usr/sbin/varnishd(CNT_Request+0x441) [0x442db9] 0x433dd0: /usr/sbin/varnishd(HTTP1_Session+0x429) [0x433dd0] 0x445e3f: /usr/sbin/varnishd() [0x445e3f] 0x446067: /usr/sbin/varnishd() [0x446067] 0x446613: /usr/sbin/varnishd(SES_pool_accept_task+0x1f9) [0x446613] 0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce) [0x43e44f] 0x456f84: /usr/sbin/varnishd() [0x456f84] req = 0x7ff3ff3ee020 { sp = 0x7ff410827560, vxid = 1074171954, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7ff410827560 { fd = 22, vxid = 430129, client = 127.0.0.1 49083, step = S_STP_WORKING, }, worker = 0x7ff42280cbf0 { ws = 0x7ff42280ce08 { id = "wrk", {s,f,r,e} = {0x7ff42280c3d0,0x7ff42280c3d0,(nil),+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7ff3ff3ee1b8 { id = "req", {s,f,r,e} = {0x7ff3ff3f0010,+432,(nil),+57360}, }, http[req] = { ws = 0x7ff3ff3ee1b8[req] "GET", "/link", "HTTP/1.0", "Connection: close", "User-Agent: ApacheBench/2.3", "Accept: */*", "host: hostname", "grace: none", "X-Obj-TTL: 0.000", }, vcl = { srcname = { "input", "Builtin", }, }, obj (REQ) = 0x7ff401bfe380 { vxid = 2147913770, http[obj] = { ws = (nil)[] "HTTP/1.1", "200", "OK", "Date: Sat, 13 Dec 2014 02:13:28 GMT", "Content-Type: text/html; charset=UTF-8", "Content-Encoding: gzip", "Cache-Control: public, max-age=600", }, len = 0, store = { }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 09:55:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 09:55:56 -0000 Subject: [Varnish] #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 In-Reply-To: <046.faacb661f65c2a9d5c752e6df2f5668e@varnish-cache.org> References: <046.faacb661f65c2a9d5c752e6df2f5668e@varnish-cache.org> Message-ID: <061.69b0066256f20fa27a347d4d6e445f0b@varnish-cache.org> #1646: Assert error in VFP_GetStorage(), cache/cache_fetch_proc.c line 84 ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [3dc48cec578ab1e9f99706b3508973f6b676b8e4]: {{{ #!CommitTicketReference repository="" revision="3dc48cec578ab1e9f99706b3508973f6b676b8e4" Continuously update our total object size estimate when cond-fetching a still-being-streamed object. Fixes #1646 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 10:12:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 10:12:31 -0000 Subject: [Varnish] #1642: Assert error in VGZ_Ibuf() In-Reply-To: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> References: <045.985190b764fa9780a1b24d2b8ab90094@varnish-cache.org> Message-ID: <060.4037325beaad25e88888c8e824a67ec2@varnish-cache.org> #1642: Assert error in VGZ_Ibuf() --------------------------+--------------------- Reporter: llavaud | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: assert error | --------------------------+--------------------- Comment (by martin): I have analyzed this ticket, and found the problem to stem from error returns from VDP_bytes being ignored in ESI_Deliver() on lines 308, 350, 421 and 423. When gunzip is in effect this causes problems. The problem starts in VDP_gunzip(). What happens is that when a VDP_bytes call from lower in the stack returns error (e.g. write error when client has gone away), the gunzip input buffer is left with bytes still present. On the next call with more input data to this layer in the VDP, the assertion is thrown because the buffer still has data in it. Normally this doesn't cause problems, as the normal delivery path will abort the delivery immediately upon VDP_bytes() returning error, and thus not call VDP_bytes() again. But ESI_deliver() doesn't behave the same way. Looking at ESI_deliver() the code is inconsistent with regards to the treatment of VDP_bytes() errors. Some places it is dealt with, others it isn't. The right behavior is an open question though. I see merit in making ESI_deliver() ignore delivery errors so that the side effects of delivery is applied (fetching uncached ESI includes). The right strategy here needs to be decided. Possible ways to solve this: 1) Latch VDP_bytes errors as a status on req->vdp_error. Whenever VDP_bytes() causes an error the flag is set, and all calls to VDP_bytes() when the flag is set immediately returns error without descending into the VDP stack. Also fix ESI_deliver() to always ignore VDP_bytes() errors to be consistent and get the ESI include side effects applied. 2) Fix ESI_deliver() to always check the return value from VDP_bytes(). 3) Change VDP_gunzip() to flush the input buffer on errors. Though I am afraid that this would mask delivery errors as gunzip errors because we then deliberately mess with the gzip stream. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 10:40:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 10:40:55 -0000 Subject: [Varnish] #1601: PRIV_{REQ, SESS} method invocations crash in vcl_backend_* In-Reply-To: <043.4159ad35442738d960b0976a1759d0e8@varnish-cache.org> References: <043.4159ad35442738d960b0976a1759d0e8@varnish-cache.org> Message-ID: <058.4f7fc4364bbbe2cdb56f045cbda16c9c@varnish-cache.org> #1601: PRIV_{REQ,SESS} method invocations crash in vcl_backend_* ----------------------+--------------------- Reporter: daghf | Owner: daghf Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by daghf): * status: new => closed * resolution: => fixed Comment: This was resolved with the introduction of PRIV_TASK. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 10:43:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 10:43:29 -0000 Subject: [Varnish] #1597: If user "nobody" is not in passwd varnishd will crash on initgroups In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.dfb9c19f83f51ff8c932ff7e7d8483ae@varnish-cache.org> #1597: If user "nobody" is not in passwd varnishd will crash on initgroups ----------------------+--------------------- Reporter: Jay | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [bfe5df840f28a01b0ca9f69d58e4911284b66ee9]: {{{ #!CommitTicketReference repository="" revision="bfe5df840f28a01b0ca9f69d58e4911284b66ee9" If we cannot find nobody/nogroup, lookup current process uid/gid. If that fails to, bail at ARGV_ERR level. Fixes #1597 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 12:48:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 12:48:52 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.4ac88492b6e38b709d04c95bcbe54693@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Comment (by ssm): The package installation will run "stop" in "prerm" of the old package, and "start" in the "postinst" of the new one. These are added by the "#DEBHELPER#" markers at package build times by "debhelper" in the debian/*.postinst and debian/*.prerm files. As long as we do this, the packages will follow Debian policy. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 17:12:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 17:12:28 -0000 Subject: [Varnish] #1648: Corrupt object in cache through IMS update on an object that fails during body fetch Message-ID: <044.996b72ce6ad80b6ca93dd0c20722dc84@varnish-cache.org> #1648: Corrupt object in cache through IMS update on an object that fails during body fetch --------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- When a fetch fails during body fetch, and that object is the source of an IMS revalidation, the condfetch code can fail to notice that the original fetch failed, and thus insert a partial fetch in the cache that later clients are served without error. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 17:13:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 17:13:11 -0000 Subject: [Varnish] #1649: Unusual crash Message-ID: <043.0eed86cd84363a4c83f40ce761f12eea@varnish-cache.org> #1649: Unusual crash ---------------------------------+-------------------- Reporter: ic134 | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: build Version: 4.0.2 | Severity: normal Keywords: | ---------------------------------+-------------------- Had varnish 4 running successfully for about a month then got: Dec 15 19:10:14 holly varnishd[52502]: Child (52512) died signal=11 Dec 15 19:10:15 holly varnishd[52502]: Child cleanup complete Dec 15 19:10:15 holly varnishd[52502]: child (25630) Started Dec 15 19:10:15 holly varnishd[52502]: Pushing vcls failed:#012Loading VMOD std from /usr/lib64/varnish/vmods/libvmod_std.so:#012dlopen() failed: /usr/lib64/varnish/vmods/libvmod_std.so: undefined symbol: WS_MarkOverflow#012Check child process permissions.#012VCL "boot" Failed to initialize Dec 15 19:10:15 holly varnishd[52502]: Stopping Child Dec 15 19:10:16 holly varnishd[52502]: Child (25630) died status=1 Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child starts Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child dies Dec 15 19:10:16 holly varnishd[52502]: Child cleanup complete Couldn't find references that looked specific. Grateful for ideas/ways to find more. Thanks, Ian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 20:55:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 20:55:22 -0000 Subject: [Varnish] #1649: Unusual crash In-Reply-To: <043.0eed86cd84363a4c83f40ce761f12eea@varnish-cache.org> References: <043.0eed86cd84363a4c83f40ce761f12eea@varnish-cache.org> Message-ID: <058.483513ae0222a0070beb749797878728@varnish-cache.org> #1649: Unusual crash --------------------+---------------------------------- Reporter: ic134 | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | --------------------+---------------------------------- Description changed by phk: Old description: > Had varnish 4 running successfully for about a month then got: > Dec 15 19:10:14 holly varnishd[52502]: Child (52512) died signal=11 > Dec 15 19:10:15 holly varnishd[52502]: Child cleanup complete > Dec 15 19:10:15 holly varnishd[52502]: child (25630) Started > Dec 15 19:10:15 holly varnishd[52502]: Pushing vcls failed:#012Loading > VMOD std from /usr/lib64/varnish/vmods/libvmod_std.so:#012dlopen() > failed: /usr/lib64/varnish/vmods/libvmod_std.so: undefined symbol: > WS_MarkOverflow#012Check child process permissions.#012VCL "boot" Failed > to initialize > Dec 15 19:10:15 holly varnishd[52502]: Stopping Child > Dec 15 19:10:16 holly varnishd[52502]: Child (25630) died status=1 > Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child starts > Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child dies > Dec 15 19:10:16 holly varnishd[52502]: Child cleanup complete > > Couldn't find references that looked specific. > Grateful for ideas/ways to find more. > Thanks, > Ian New description: Had varnish 4 running successfully for about a month then got: {{{ Dec 15 19:10:14 holly varnishd[52502]: Child (52512) died signal=11 Dec 15 19:10:15 holly varnishd[52502]: Child cleanup complete Dec 15 19:10:15 holly varnishd[52502]: child (25630) Started Dec 15 19:10:15 holly varnishd[52502]: Pushing vcls failed: Loading VMOD std from /usr/lib64/varnish/vmods/libvmod_std.so: dlopen() failed: /usr/lib64/varnish/vmods/libvmod_std.so: undefined symbol: WS_MarkOverflow Check child process permissions. VCL "boot" Failed to initialize Dec 15 19:10:15 holly varnishd[52502]: Stopping Child Dec 15 19:10:16 holly varnishd[52502]: Child (25630) died status=1 Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child starts Dec 15 19:10:16 holly varnishd[52502]: Child (25630) said Child dies Dec 15 19:10:16 holly varnishd[52502]: Child cleanup complete }}} Couldn't find references that looked specific. Grateful for ideas/ways to find more. Thanks, Ian -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 20:57:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 20:57:25 -0000 Subject: [Varnish] #1649: Unusual crash In-Reply-To: <043.0eed86cd84363a4c83f40ce761f12eea@varnish-cache.org> References: <043.0eed86cd84363a4c83f40ce761f12eea@varnish-cache.org> Message-ID: <058.40353c40761a289a098924a0f07c5d20@varnish-cache.org> #1649: Unusual crash --------------------+---------------------------------- Reporter: ic134 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.2 Severity: normal | Resolution: worksforme Keywords: | --------------------+---------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: That looks a lot like a version problem between the vmod you are loading and the varnishd you are loading it into. Please double-check that they are compatible, and reopen the ticket if you are sure they are. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 21:36:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 21:36:46 -0000 Subject: [Varnish] #1641: Assert error in vbf_stp_startfetch() In-Reply-To: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> References: <045.6003a667979ac910bd18c9af0365c470@varnish-cache.org> Message-ID: <060.d4f0567c6ab51c44c5a27eec0168bff0@varnish-cache.org> #1641: Assert error in vbf_stp_startfetch() --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: assert error | --------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * resolution: duplicate => fixed Comment: In [d057bf951796de1acc0359613ebb50e4fc891a0f]: {{{ #!CommitTicketReference repository="" revision="d057bf951796de1acc0359613ebb50e4fc891a0f" Nils patch for retrying partial fetches, with minor changes by me. Fixes #1638 Fixes #1641 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 16 21:36:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Dec 2014 21:36:46 -0000 Subject: [Varnish] #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.2147454708778f340267daa337d33471@varnish-cache.org> #1638: 82b29b1 retry of short server read : Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+--------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: assigned => closed * resolution: => fixed Comment: In [d057bf951796de1acc0359613ebb50e4fc891a0f]: {{{ #!CommitTicketReference repository="" revision="d057bf951796de1acc0359613ebb50e4fc891a0f" Nils patch for retrying partial fetches, with minor changes by me. Fixes #1638 Fixes #1641 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 17 12:50:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Dec 2014 12:50:27 -0000 Subject: [Varnish] #1648: Corrupt object in cache through IMS update on an object that fails during body fetch In-Reply-To: <044.996b72ce6ad80b6ca93dd0c20722dc84@varnish-cache.org> References: <044.996b72ce6ad80b6ca93dd0c20722dc84@varnish-cache.org> Message-ID: <059.5e33cd3efe77cd3ec2f636c7b7bc64ca@varnish-cache.org> #1648: Corrupt object in cache through IMS update on an object that fails during body fetch --------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [dba9daad80db5cfefa43890fc463fbd42f4ee825]: {{{ #!CommitTicketReference repository="" revision="dba9daad80db5cfefa43890fc463fbd42f4ee825" Handle template object failures during condfetch Fixes: #1648 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 17 12:50:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Dec 2014 12:50:27 -0000 Subject: [Varnish] #1647: Varnish 4 crashes occasionally under stress test: Assert error in cnt_lookup() In-Reply-To: <041.e9d6d4012b20edd5534d3b4f45c91794@varnish-cache.org> References: <041.e9d6d4012b20edd5534d3b4f45c91794@varnish-cache.org> Message-ID: <056.13ac3b951ab1c6f516e86e2baba26010@varnish-cache.org> #1647: Varnish 4 crashes occasionally under stress test: Assert error in cnt_lookup() ----------------------+----------------------------------------------- Reporter: wjy | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [298ffb63d3fb0c3e4a683acba0d9639d6901a655]: {{{ #!CommitTicketReference repository="" revision="298ffb63d3fb0c3e4a683acba0d9639d6901a655" Relax an assertion for the IMS update candidate object The streaming fetch of an object can fail between lookup time and when we actually use it. Relax this assertion. Fixes: #1647 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 17 14:52:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Dec 2014 14:52:57 -0000 Subject: [Varnish] #1650: X-Forwarded-For looses the first ip in list Message-ID: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> #1650: X-Forwarded-For looses the first ip in list --------------------------+-------------------- Reporter: KlavsKlavsen | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.2 | Severity: normal Keywords: | --------------------------+-------------------- Just converted varnish 3 setup, to varnish 4, and the X-Forwarded-For header consistently gets the first ip removed, when more than 1 ip is on the ingoing request. X-Forwarded-For: 80.89.204.138, 10.233.1.34 then shows up as this on the backend: X-Forwarded-For: 10.233.113.96, 10.230.1.34 we ran varnish 4, next to the varnish 3 boxes, and the request via them, became: X-Forwarded-For: 10.233.113.96, 80.89.204.138, 10.230.1.34 which is because we have this in our varnish 3 vcl_recv: if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; } (and vcl_recv ends with return(lookup) to bypass x-forwarded-for handling in varnish 3). I tried reproducing this on test but could not :( - and I had to pull it out of production again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 17 15:06:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Dec 2014 15:06:14 -0000 Subject: [Varnish] #1378: varnishncsa does not escape log items In-Reply-To: <046.c965e13022034e658e261f1b7ddb7f49@varnish-cache.org> References: <046.c965e13022034e658e261f1b7ddb7f49@varnish-cache.org> Message-ID: <061.579dc74fa9185adab9f6ea4d4cb4ecea@varnish-cache.org> #1378: varnishncsa does not escape log items -------------------------+--------------------- Reporter: simonvik | Owner: aondio Type: defect | Status: closed Priority: low | Milestone: Component: varnishncsa | Version: 3.0.4 Severity: minor | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by arianna-aondio ): * status: new => closed * resolution: => fixed Comment: In [d68863d0d983685a286347824046f791bba58c55]: {{{ #!CommitTicketReference repository="" revision="d68863d0d983685a286347824046f791bba58c55" Varnishncsa escapes non-printable chars. Fixes: #1378 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 18 23:44:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Dec 2014 23:44:23 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.179d7877078a6b15f2fe36c53aaefba0@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by fgsch): Replying to [comment:4 fgsch]: > This should be only an issue on miss. > "Range: bytes=0-" is a bit silly. You could try disable streaming in this case: > [..] Actually thinking back you could remove the range altogether without disabling streaming: {{{ if (bereq.http.range ~ "bytes=0-$") { unset bereq.http.range; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 19 10:15:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Dec 2014 10:15:48 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.c648eef8555166f2fde57519377fe545@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by Jay): Great. Thanks. The HTTP request comes from IE/Chrome/Firefox and the audio html-tag or perhaps javascript (a lot of objects on the page so getting a varnishlog is difficult). It is a silly range-request, but it seems to be widely used by client software. It also seem to be valid according to RFC. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 22 12:15:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Dec 2014 12:15:13 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.f75b41dc71ab26d922b2ed7cc6712e3b@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by slink): Jay, can you tell us why the client is sending this Range request in the first place? I'd presume this is to * test if the server actually does support range requests or * ensure that the client gets a content-length equivalent (as a 200 could be a chunked response) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 22 12:29:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Dec 2014 12:29:50 -0000 Subject: [Varnish] #1650: X-Forwarded-For looses the first ip in list In-Reply-To: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> References: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> Message-ID: <065.4f8491baa51837fac74a3527c2929b92@varnish-cache.org> #1650: X-Forwarded-For looses the first ip in list --------------------------+-------------------- Reporter: KlavsKlavsen | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | --------------------------+-------------------- Comment (by slink): I don't think we can help you without a testcase or at least your VCL. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 22 12:30:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Dec 2014 12:30:08 -0000 Subject: [Varnish] #1650: X-Forwarded-For looses the first ip in list In-Reply-To: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> References: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> Message-ID: <065.25100b8ccc44a98ff0f7e8eedf2638df@varnish-cache.org> #1650: X-Forwarded-For looses the first ip in list --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Changes (by slink): * status: new => needinfo -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 22 12:31:32 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Dec 2014 12:31:32 -0000 Subject: [Varnish] #1650: X-Forwarded-For looses the first ip in list In-Reply-To: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> References: <050.2763cd420782dfaf2b4b47bc82076d98@varnish-cache.org> Message-ID: <065.aba388329faee1d425a9d23a4ce6ee1d@varnish-cache.org> #1650: X-Forwarded-For looses the first ip in list --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Comment (by KlavsKlavsen): actually gave vcl in irc.. can't find pastie right now. unfortunately sick and on christmas vacation. will test further end return with debug info after christmas. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 22 22:01:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Dec 2014 22:01:28 -0000 Subject: [Varnish] #1643: corrupt range response In-Reply-To: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> References: <041.113f5e6ae1e1582a5da6631379ba3e37@varnish-cache.org> Message-ID: <056.3e28607234bc8e740051c582a0182dbb@varnish-cache.org> #1643: corrupt range response --------------------------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: byte-range request range | --------------------------------------+----------------------- Comment (by Jay): It is a part of a page using the builtin audio/html5-player in multiple browsers. Either the browser is doing it directly or it is some sort of javascript handling the request. The reason behind the range-request is not know. Perhaps if the size of the file was larger, the player would have split the file fetching into multiple request. The author of the code could have just dropped the header if fetching the entire file at once, but is seems to be a valid request anyway. Per RFC 2616, section 14.35.1 Byte Ranges If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity- body in bytes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 24 23:18:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Dec 2014 23:18:46 -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.023af72be525bb4c086f1750e20f954e@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+----------------------- Reporter: yoloseem | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Changes (by lkarsten): * status: closed => reopened * resolution: worksforme => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 24 23:25:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Dec 2014 23:25:10 -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.da2c172acc3a5c27d98f11ae546196eb@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+----------------------- Reporter: yoloseem | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Comment (by lkarsten): Saw this when building 4.0.2 (from 4.0 branch in git) on OSX. Observed: any kind of invalid first argument to std.ip() makes the child process go away. Expected: child would not die, fallback value will be used/returned. The value of fallback does not seem to influence this, as the error appears with both 127.0.0.1 and client.ip as the second argument. {{{ **** 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 from "/Users/lkarsten/work/varnish- cache-git/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/Users/lkarsten/work /varnish-cache-git/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/Users/lkarsten/work/varnish-cache- git/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/Users/lkarsten/work/varnish-cache- git/bin/varnishtest **** top 0.0 macro def topbuild=/Users/lkarsten/work/varnish-cache-git **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43234.1ac78804 * top 0.0 TEST 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=54884 **** s1 0.0 macro def s1_sock=127.0.0.1 54884 * s1 0.0 Listen on 127.0.0.1 54884 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 54884 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43234.1ac78804/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -a '127.0.0.1:0' -M '127.0.0.1 54885' -P /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43234.1ac78804/v1/varnishd.pid *** v1 0.0 CMD: cd /Users/lkarsten/work/varnish-cache- git/bin/varnishtest && varnishd -d -d -n /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43234.1ac78804/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -a '127.0.0.1:0' -M '127.0.0.1 54885' -P /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43234.1ac78804/v1/varnishd.pid *** v1 0.0 PID: 43252 *** v1 0.0 debug| Platform: Darwin,13.4.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.4.0,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.2 revision 887c70e\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| yhexxyfagdoinavcifjqeqfuvddicupd\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 97fe19ec05bc2b6b46342cd8c1596dfbdd7a72c52842e248ef202d595ff91534\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.4.0,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.2 revision 887c70e\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 = "54884"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \timport std from "/Users/lkarsten/work/varnish- cache-git/lib/libvmod_std/.libs/libvmod_std.so";\n **** v1 0.1 CLI TX| \tsub vcl_deliver {\n **** v1 0.1 CLI TX| \t\t# works\n **** v1 0.1 CLI TX| \t\tset resp.http.bar = std.ip("1.2.3.5", client.ip);\n **** v1 0.1 CLI TX| \t\t# child crashes.\n **** v1 0.1 CLI TX| \t\tset resp.http.foo = std.ip("1.2.3.*", client.ip);\n **** v1 0.1 CLI TX| \t}\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 (43275) Started\n *** v1 0.2 CLI RX 200 *** v1 0.2 wait-running *** v1 0.2 debug| Child (43275) said Not running as root, no priv- sep\n **** v1 0.2 CLI TX| status *** v1 0.2 debug| Child (43275) 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 54890\n ** v1 0.2 Listen on 127.0.0.1 54890 **** v1 0.2 macro def v1_addr=127.0.0.1 **** v1 0.2 macro def v1_port=54890 **** v1 0.2 macro def v1_sock=127.0.0.1 54890 *** top 0.2 client ** c1 0.2 Starting client ** c1 0.2 Waiting for client *** c1 0.2 Connect to 127.0.0.1 54890 *** c1 0.2 connected fd 9 from 127.0.0.1 54891 to 127.0.0.1 54890 *** 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 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 54891 127.0.0.1:0 127.0.0.1 54890 1419463280.974417 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: 1419463280.974853 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,,54884) 127.0.0.1 54892 **** v1 0.3 vsl| 1002 Backend b 7 s1 s1(127.0.0.1,,54884) **** v1 0.3 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.3 vsl| 1002 Timestamp b Bereq: 1419463280.975133 0.000280 0.000280 **** v1 0.3 vsl| 1002 Timestamp b Beresp: 1419463280.975551 0.000698 0.000418 **** v1 0.3 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.3 vsl| 1002 BerespStatus b 200 **** v1 0.3 vsl| 1002 BerespReason b OK **** v1 0.3 vsl| 1002 BerespHeader b Content-Length: 1 **** v1 0.3 vsl| 1002 BerespHeader b Date: Wed, 24 Dec 2014 23:21:20 GMT **** v1 0.3 vsl| 1002 TTL b RFC 120 -1 -1 1419463281 1419463281 1419463280 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 ObjReason b OK **** v1 0.3 vsl| 1002 ObjHeader b Content-Length: 1 **** v1 0.3 vsl| 1002 ObjHeader b Date: Wed, 24 Dec 2014 23:21:20 GMT **** v1 0.3 vsl| 1002 Fetch_Body b 3 length stream **** v1 0.3 vsl| 1002 BackendReuse b 7 s1(127.0.0.1,,54884) **** v1 0.3 vsl| 1002 Timestamp b BerespBody: 1419463280.975811 0.000958 0.000260 **** 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| 0 ExpKill - EXP_Inbox p=0x7fa4f0405040 e=0.000000000 f=0x0 **** v1 0.3 vsl| 0 ExpKill - EXP_When p=0x7fa4f0405040 e=1419463410.975550890 f=0x1c10 **** v1 1.3 CLI TX| backend.list *** v1 1.3 CLI RX 200 **** v1 1.3 CLI RX| Backend name Refs Admin Probe\n **** v1 1.3 CLI RX| s1(127.0.0.1,,54884) 1 probe Healthy (no probe) ** v1 1.3 Wait **** v1 1.3 vsl| 0 CLI - Rd backend.list **** v1 1.3 vsl| 0 CLI - Wr 200 122 Backend name Refs Admin Probe s1(127.0.0.1,,54884) 1 probe Healthy (no probe) **** v1 1.3 vsl| 0 CLI - EOF on CLI connection, worker stops **** v1 2.3 STDOUT poll 0x11 ** v1 2.3 R 43252 Status: 0000 (u 0.071918 s 0.049559) * top 2.3 TEST tests/m00011.vtc FAILED # top TEST tests/m00011.vtc FAILED (2.328) exit=1 }}} with m00011.vtc reduced to: {{{ varnishtest "Test std.ip" server s1 { rxreq txresp -body "1" } -start varnish v1 -vcl+backend { import ${vmod_std}; sub vcl_deliver { # works set resp.http.bar = std.ip("1.2.3.5", client.ip); # child crashes. set resp.http.foo = std.ip("1.2.3.*", client.ip); } } -start client c1 { txreq -url "/foo1" rxresp expect resp.bodylen == 1 } -run }}} gitref is 887c70e. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 24 23:35:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Dec 2014 23:35:47 -0000 Subject: [Varnish] #1651: c00061.vtc fails on OSX (connect_timeout not working?) Message-ID: <046.7d1748fdc6815cc56b19486f05c00d04@varnish-cache.org> #1651: c00061.vtc fails on OSX (connect_timeout not working?) ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Keywords: ----------------------+------------------- c00061.vtc fails on OSX Maverick. Observed: Test case fails after 32 seconds, after timing out 2 bgfetches (taking 12.3s!?). The second retry (third request) does not complete before varnishtest fails the test. Expected result: each bgfetch should fail after 1s (there is no webserver on ${bad_ip}), and the test should finish after 3-4 seconds. Reducing setting first_byte_timeout to 1s gives the expected test case result. It appears that setting connect_timeout does not take effect. {{{ **** 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 from "/Users/lkarsten/work/varnish- cache-git/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/Users/lkarsten/work /varnish-cache-git/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/Users/lkarsten/work/varnish-cache- git/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/Users/lkarsten/work/varnish-cache- git/bin/varnishtest **** top 0.0 macro def topbuild=/Users/lkarsten/work/varnish-cache-git **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43347.231af40c * top 0.0 TEST tests/c00061.vtc starting *** top 0.0 varnishtest * top 0.0 TEST retry in vcl_backend_error *** top 0.0 varnish ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43347.231af40c/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -a '127.0.0.1:0' -M '127.0.0.1 54917' -P /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43347.231af40c/v1/varnishd.pid *** v1 0.0 CMD: cd /Users/lkarsten/work/varnish-cache- git/bin/varnishtest && varnishd -d -d -n /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43347.231af40c/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -p thread_pool_min=10 -a '127.0.0.1:0' -M '127.0.0.1 54917' -P /var/folders/tp/lfqnnc595hj9rxwxkzvgtn7h0000gn/T//vtc.43347.231af40c/v1/varnishd.pid *** v1 0.0 PID: 43365 *** v1 0.0 debug| Platform: Darwin,13.4.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.4.0,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.2 revision 887c70e\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 = 7 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| booxicntojvhjlvzhilyblqesfjftbsx\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth ffd5c78e323a49d9720aba58ce53cba2ba45b4158b0a92b191c3d94eaf850504\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.4.0,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.2 revision 887c70e\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| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tbackend b1 { .host = "192.0.2.255"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_backend_error {\n **** v1 0.1 CLI TX| \t\treturn (retry);\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_synth {\n **** v1 0.1 CLI TX| \t\tset resp.status = 504;\n **** v1 0.1 CLI TX| \t}\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 (43388) Started\n *** v1 0.2 CLI RX 200 *** v1 0.2 debug| Child (43388) 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 (43388) 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 54922\n ** v1 0.2 Listen on 127.0.0.1 54922 **** v1 0.2 macro def v1_addr=127.0.0.1 **** v1 0.2 macro def v1_port=54922 **** v1 0.2 macro def v1_sock=127.0.0.1 54922 *** top 0.2 varnish **** v1 0.2 CLI TX| param.set debug +syncvsl *** v1 0.2 CLI RX 200 ** v1 0.2 CLI 200 *** top 0.2 varnish **** v1 0.2 CLI TX| param.set connect_timeout 1 *** v1 0.2 CLI RX 200 ** v1 0.2 CLI 200 *** top 0.2 varnish **** v1 0.2 CLI TX| param.set max_retries 2 *** v1 0.2 CLI RX 200 ** v1 0.2 CLI 200 *** top 0.2 client ** c1 0.2 Starting client ** c1 0.2 Waiting for client *** c1 0.2 Connect to 127.0.0.1 54922 *** c1 0.2 connected fd 8 from 127.0.0.1 54923 to 127.0.0.1 54922 *** c1 0.2 txreq **** c1 0.2 txreq| GET / HTTP/1.1\r\n **** c1 0.2 txreq| \r\n *** c1 0.2 rxresp **** v1 0.3 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.3 vsl| 1000 SessOpen c 127.0.0.1 54923 127.0.0.1:0 127.0.0.1 54922 1419463614.447459 6 **** v1 0.3 vsl| 1001 Begin c req 1000 rxreq **** v1 0.3 vsl| 1000 Link c req 1001 rxreq **** v1 0.3 vsl| 1001 Timestamp c Start: 1419463614.447641 0.000000 0.000000 **** v1 0.3 vsl| 1001 Timestamp c Req: 1419463614.447641 0.000000 0.000000 **** v1 0.3 vsl| 1001 ReqStart c 127.0.0.1 54923 **** v1 0.3 vsl| 1001 ReqMethod c GET **** v1 0.3 vsl| 1001 ReqURL c / **** 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| 1002 Begin b bereq 1001 fetch **** v1 0.3 vsl| 1001 Link c bereq 1002 fetch **** v1 0.3 vsl| 1002 Timestamp b Start: 1419463614.447857 0.000000 0.000000 **** v1 0.3 vsl| 1002 BereqMethod b GET **** v1 0.3 vsl| 1002 BereqURL b / **** 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.4 vsl| 1002 BackendOpen b 7 b1(192.0.2.255,,80) 192.168.1.9 54924 **** v1 0.4 vsl| 1002 Backend b 7 b1 b1(192.0.2.255,,80) **** v1 0.4 vsl| 1002 BereqHeader b Host: 192.0.2.255 **** v1 0.4 vsl| 1002 Timestamp b Bereq: 1419463614.491671 0.043814 0.043814 **** v1 3.2 vsl| 0 CLI - Rd ping **** v1 3.2 vsl| 0 CLI - Wr 200 19 PONG 1419463617 1.0 **** v1 6.2 vsl| 0 CLI - Rd ping **** v1 6.2 vsl| 0 CLI - Wr 200 19 PONG 1419463620 1.0 **** v1 9.2 vsl| 0 CLI - Rd ping **** v1 9.2 vsl| 0 CLI - Wr 200 19 PONG 1419463623 1.0 **** v1 12.2 vsl| 0 CLI - Rd ping **** v1 12.2 vsl| 0 CLI - Wr 200 19 PONG 1419463626 1.0 **** v1 12.5 vsl| 1002 FetchError b http first read error: EOF **** v1 12.5 vsl| 1002 BackendClose b 7 b1(192.0.2.255,,80) **** v1 12.5 vsl| 1002 Timestamp b Beresp: 1419463626.594923 12.147066 12.103252 **** v1 12.5 vsl| 1002 Timestamp b Error: 1419463626.594941 12.147084 0.000018 **** v1 12.5 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 12.5 vsl| 1002 BerespStatus b 503 **** v1 12.5 vsl| 1002 BerespReason b Service Unavailable **** v1 12.5 vsl| 1002 BerespReason b Backend fetch failed **** v1 12.5 vsl| 1002 BerespHeader b Date: Wed, 24 Dec 2014 23:27:06 GMT **** v1 12.5 vsl| 1002 BerespHeader b Server: Varnish **** v1 12.5 vsl| 1002 VCL_call b BACKEND_ERROR **** v1 12.5 vsl| 1002 VCL_return b retry **** v1 12.5 vsl| 1002 Timestamp b Retry: 1419463626.595129 12.147272 0.000188 **** v1 12.5 vsl| 1002 Link b bereq 1003 retry **** v1 12.5 vsl| 1002 End b **** v1 12.5 vsl| 1003 Begin b bereq 1002 retry **** v1 12.5 vsl| 1003 Timestamp b Start: 1419463626.595129 12.147272 0.000000 **** v1 12.5 vsl| 1003 BereqHeader b X-Varnish: 1003 **** v1 12.5 vsl| 1003 VCL_call b BACKEND_FETCH **** v1 12.5 vsl| 1003 VCL_return b fetch **** v1 12.5 vsl| 1003 BackendOpen b 7 b1(192.0.2.255,,80) 192.168.1.9 54926 **** v1 12.5 vsl| 1003 Backend b 7 b1 b1(192.0.2.255,,80) **** v1 12.5 vsl| 1003 Timestamp b Bereq: 1419463626.635396 12.187539 0.040267 **** v1 15.2 vsl| 0 CLI - Rd ping **** v1 15.2 vsl| 0 CLI - Wr 200 19 PONG 1419463629 1.0 **** v1 18.2 vsl| 0 CLI - Rd ping **** v1 18.2 vsl| 0 CLI - Wr 200 19 PONG 1419463632 1.0 **** v1 21.2 vsl| 0 CLI - Rd ping **** v1 21.2 vsl| 0 CLI - Wr 200 19 PONG 1419463635 1.0 **** v1 24.2 vsl| 0 CLI - Rd ping **** v1 24.2 vsl| 0 CLI - Wr 200 19 PONG 1419463638 1.0 **** v1 24.6 vsl| 1003 FetchError b http first read error: EOF **** v1 24.6 vsl| 1003 BackendClose b 7 b1(192.0.2.255,,80) **** v1 24.6 vsl| 1003 Timestamp b Beresp: 1419463638.778148 24.330291 12.142752 **** v1 24.6 vsl| 1003 Timestamp b Error: 1419463638.778157 24.330300 0.000009 **** v1 24.6 vsl| 1003 BerespProtocol b HTTP/1.1 **** v1 24.6 vsl| 1003 BerespStatus b 503 **** v1 24.6 vsl| 1003 BerespReason b Service Unavailable **** v1 24.6 vsl| 1003 BerespReason b Backend fetch failed **** v1 24.6 vsl| 1003 BerespHeader b Date: Wed, 24 Dec 2014 23:27:18 GMT **** v1 24.6 vsl| 1003 BerespHeader b Server: Varnish **** v1 24.6 vsl| 1003 VCL_call b BACKEND_ERROR **** v1 24.6 vsl| 1003 VCL_return b retry **** v1 24.6 vsl| 1003 Timestamp b Retry: 1419463638.778260 24.330403 0.000103 **** v1 24.6 vsl| 1003 Link b bereq 1004 retry **** v1 24.6 vsl| 1003 End b **** v1 24.6 vsl| 1004 Begin b bereq 1003 retry **** v1 24.6 vsl| 1004 Timestamp b Start: 1419463638.778260 24.330403 0.000000 **** v1 24.6 vsl| 1004 BereqHeader b X-Varnish: 1004 **** v1 24.6 vsl| 1004 VCL_call b BACKEND_FETCH **** v1 24.6 vsl| 1004 VCL_return b fetch **** v1 24.7 vsl| 1004 BackendOpen b 7 b1(192.0.2.255,,80) 192.168.1.9 54927 **** v1 24.7 vsl| 1004 Backend b 7 b1 b1(192.0.2.255,,80) **** v1 24.7 vsl| 1004 Timestamp b Bereq: 1419463638.819947 24.372090 0.041687 **** v1 27.2 vsl| 0 CLI - Rd ping **** v1 27.2 vsl| 0 CLI - Wr 200 19 PONG 1419463641 1.0 ---- c1 30.2 HTTP rx timeout (fd:8 30000 ms) * top 30.2 RESETTING after tests/c00061.vtc **** v1 30.2 vsl| 0 CLI - Rd ping **** v1 30.2 vsl| 0 CLI - Wr 200 19 PONG 1419463644 1.0 **** v1 31.2 CLI TX| backend.list *** v1 31.2 CLI RX 200 **** v1 31.2 CLI RX| Backend name Refs Admin Probe\n **** v1 31.2 CLI RX| b1(192.0.2.255,,80) 2 probe Healthy (no probe) ** v1 31.2 Wait **** v1 31.2 vsl| 0 CLI - Rd backend.list **** v1 31.2 vsl| 0 CLI - Wr 200 122 Backend name Refs Admin Probe b1(192.0.2.255,,80) 2 probe Healthy (no probe) **** v1 31.2 vsl| 0 CLI - EOF on CLI connection, worker stops **** v1 32.2 STDOUT poll 0x11 ** v1 32.2 R 43365 Status: 0000 (u 0.083265 s 0.075232) * top 32.3 TEST tests/c00061.vtc FAILED # top TEST tests/c00061.vtc FAILED (32.324) exit=1 }}} After modification: {{{ lkarsten at jungel:~/work/varnish-cache-git/bin/varnishtest$ ./varnishtest -i tests/c00061.vtc # top TEST tests/c00061.vtc passed (4.597) lkarsten at jungel:~/work/varnish-cache-git/bin/varnishtest$ git df tests/c00061.vtc diff --git a/bin/varnishtest/tests/c00061.vtc b/bin/varnishtest/tests/c00061.vtc index ef2ae76..4599c27 100644 --- a/bin/varnishtest/tests/c00061.vtc +++ b/bin/varnishtest/tests/c00061.vtc @@ -15,6 +15,7 @@ varnish v1 -vcl { varnish v1 -cliok "param.set debug +syncvsl" varnish v1 -cliok "param.set connect_timeout 1" +varnish v1 -cliok "param.set first_byte_timeout 1" varnish v1 -cliok "param.set max_retries 2" client c1 { }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 27 11:38:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 27 Dec 2014 11:38:49 -0000 Subject: [Varnish] #1651: c00061.vtc fails on OSX (connect_timeout not working?) In-Reply-To: <046.7d1748fdc6815cc56b19486f05c00d04@varnish-cache.org> References: <046.7d1748fdc6815cc56b19486f05c00d04@varnish-cache.org> Message-ID: <061.4c7f53f9ecf1900be643ab6fe897ba0b@varnish-cache.org> #1651: c00061.vtc fails on OSX (connect_timeout not working?) ----------------------+------------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by lkarsten): * status: new => closed * resolution: => worksforme Comment: I'm not able to reproduce this any longer. Not sure what provoked this to fail in the first place. Closing for now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 27 12:48:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 27 Dec 2014 12:48:33 -0000 Subject: [Varnish] #1652: Vary: * should be handled in core Message-ID: <043.35197030f92fde6a194655a060a20e5d@varnish-cache.org> #1652: Vary: * should be handled in core ----------------------+------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Currently, all of the Vary Handling happens in core code, except for {{{Vary: *}}}, which is handled in {{{builtin.vcl}}} and creates a hitpass object. Core code treats {{{*}}} like any other header name. For consistency, {{{Vary: *}}} should be handled in Core code also. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 29 12:04:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Dec 2014 12:04:00 -0000 Subject: [Varnish] #1520: m00011.vtc fails on OSX x86_64 (was: m00011.vtc fails on x86_64) In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.52130028821227379ce18d50653dd61a@varnish-cache.org> #1520: m00011.vtc fails on OSX x86_64 -------------------------+----------------------- Reporter: yoloseem | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishtest | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Changes (by lkarsten): * version: 4.0.0 => 4.0.2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 30 13:50:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Dec 2014 13:50:08 -0000 Subject: [Varnish] #1653: Make numbers in varnishstat human-readable Message-ID: <047.f46732d5f2705010f7f9e468bfaca1d8@varnish-cache.org> #1653: Make numbers in varnishstat human-readable -----------------------+------------------------- Reporter: Centurion | Type: enhancement Status: new | Priority: low Milestone: | Component: varnishstat Version: 4.0.0 | Severity: normal Keywords: | -----------------------+------------------------- I know it is still popular in 2015 to put numbers in console display, without caring about readability, but let us face it:[[br]] [[br]] if you have 128GB in use for varnish and take a quick look at varnishstat, you simply cannot tell anything without putting your thumb on the screen and counting the number of digits.[[br]][[br]] SMA.s0.g_bytes 2834700632755 [[br]] can you tell the amount of RAM used? I guess not.[[br]] The display of information in this way is (at least for real people) useless. In Europe we have a thing called 'thousands-separator', this would read as: SMA.s0.g_bytes 2.834.700.632.755 and BAM! - you see it at a glance. Please implement this, thank you. (I assume in US the separator would be ',' instead of '.', anything is better than nothing) Besides of this, great work (:[[br]] Best,[[br]] Centurion -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 31 00:28:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 31 Dec 2014 00:28:53 -0000 Subject: [Varnish] #1653: Make numbers in varnishstat human-readable In-Reply-To: <047.f46732d5f2705010f7f9e468bfaca1d8@varnish-cache.org> References: <047.f46732d5f2705010f7f9e468bfaca1d8@varnish-cache.org> Message-ID: <062.fe3b22bb40677ca820ef006987c8c26b@varnish-cache.org> #1653: Make numbers in varnishstat human-readable -------------------------+-------------------- Reporter: Centurion | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: varnishstat | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): I agree but this should be restricted to the interactive interface. If you do varnishstat -1 you should still get the raw numbers. Rather than adding the delimiter I think it'd be better to just iterate through different units. E.g. 2768262336 K, 2703381 M, 2640 G, 2.57 T. I see if I can come up with a diff for this. -- Ticket URL: Varnish The Varnish HTTP Accelerator