From varnish-bugs at varnish-cache.org Mon Jan 2 11:15:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jan 2012 11:15:51 -0000 Subject: [Varnish] #1080: Enable use of PCRE JIT-compiled regexes In-Reply-To: <047.85a59227f1e1391c94d01f12266ef4b0@varnish-cache.org> References: <047.85a59227f1e1391c94d01f12266ef4b0@varnish-cache.org> Message-ID: <056.c016503a6b78b4ea33e838067f5ecbe9@varnish-cache.org> #1080: Enable use of PCRE JIT-compiled regexes -------------------------+-------------------------------------------------- Reporter: toofishes | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 2 11:20:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jan 2012 11:20:03 -0000 Subject: [Varnish] #1078: req.http.host and port. In-Reply-To: <049.3f50561f45c6702795ff3b80064038c3@varnish-cache.org> References: <049.3f50561f45c6702795ff3b80064038c3@varnish-cache.org> Message-ID: <058.ecd55b8ac0106090a1a1966a24dd8068@varnish-cache.org> #1078: req.http.host and port. --------------------------+------------------------------------------------- Reporter: TychoCelchu | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: wontfix | Keywords: --------------------------+------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => wontfix Comment: Req.http.host is provided by a client. Use server.port for Varnish' idea of what port is in use. Feel free to tinker with req.http.host yourself, but it shouldn't be done by magic on our end. If the port is in your way: set req.http.host = regsub(req.http.host,":.*$",""); or similar. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 2 11:20:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jan 2012 11:20:54 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.f3c75eefe8628849ae43ac712b43010d@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 2 12:40:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Jan 2012 12:40:16 -0000 Subject: [Varnish] #1076: Unable to ban on object http status In-Reply-To: <041.502fa3a290b14b0e8496aad415d3f2b1@varnish-cache.org> References: <041.502fa3a290b14b0e8496aad415d3f2b1@varnish-cache.org> Message-ID: <050.44bd4669377e636a9d39ccffb29269e9@varnish-cache.org> #1076: Unable to ban on object http status ---------------------+------------------------------------------------------ Reporter: mha | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [3d43f62b2e886ff115caa803eb45bccf72c806ce]) Add support for banning on http.status Fixes: #1076 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jan 6 13:56:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 06 Jan 2012 13:56:53 -0000 Subject: [Varnish] #1081: varnishtest fails when using error statement in vcl Message-ID: <046.de4440db7d1c97a12b8baabd618696ec@varnish-cache.org> #1081: varnishtest fails when using error statement in vcl -----------------------------------------+---------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishtest Version: 3.0.2 | Severity: normal Keywords: varnishtest error statement | -----------------------------------------+---------------------------------- Hi, I've found that using the error statement in the vcl part of varnishtest makes all subsequent tests fail. Please find attached : - ok.vtc - nok.vtc - output for nok.vtc Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 8 17:01:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 08 Jan 2012 17:01:55 -0000 Subject: [Varnish] #1082: Deadlock? Message-ID: <044.6b4b94b09356d8e31852997b7f4e1bd5@varnish-cache.org> #1082: Deadlock? --------------------+------------------------------------------------------- Reporter: philip | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Hi, I just rolled out varnish into production with the latest stable 3 release. After serving lots of requests and peaking at 600Mbps I got something that looked like a deadlook. The server was not responding to requests anymore. I routed all the requests away from the varnish cache to the backend. After no requests reaching the varnish server anymore I checked the system usage with "atop". The HDD was under heavy use: {{{ DSK | sda | busy 104% | read 4044 | write 6 | avio 2 ms | DSK | sdb | busy 104% | read 13604 | write 7 | avio 0 ms | NET | transport | tcpi 3321 | tcpo 6472 | udpi 0 | udpo 7 | NET | network | ipi 3333 | ipo 2291 | ipfrw 0 | deliv 3333 | NET | eth0 0% | pcki 3333 | pcko 6739 | si 172 Kbps | so 8029 Kbps | }}} This server *only* runs varnish. I have attached the /etc/default/varnish and /etc/varnish/default.vcl files. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 9 11:05:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jan 2012 11:05:35 -0000 Subject: [Varnish] #1082: Deadlock? In-Reply-To: <044.6b4b94b09356d8e31852997b7f4e1bd5@varnish-cache.org> References: <044.6b4b94b09356d8e31852997b7f4e1bd5@varnish-cache.org> Message-ID: <053.6fb6dbdbaabedf40d35e410e318a8ac2@varnish-cache.org> #1082: Deadlock? --------------------+------------------------------------------------------- Reporter: philip | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by kristian): Can you attach varnishstat -1 output, dmesg, syslog entries related to varnish, and any other information that might help? What OS/Version is used? What exactly does "not responding to requests anymore" mean? No TCP connection? TCP connection but no response beyond that? Only 503 errors? Partial responses? Very very slow responses? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 9 11:07:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jan 2012 11:07:01 -0000 Subject: [Varnish] #1081: varnishtest fails when using error statement in vcl In-Reply-To: <046.de4440db7d1c97a12b8baabd618696ec@varnish-cache.org> References: <046.de4440db7d1c97a12b8baabd618696ec@varnish-cache.org> Message-ID: <055.6d302b411640fe6431cd3c7542b393aa@varnish-cache.org> #1081: varnishtest fails when using error statement in vcl -------------------------+-------------------------------------------------- Reporter: tmagnien | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishtest Version: 3.0.2 | Severity: normal Resolution: worksforme | Keywords: varnishtest error statement -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: vcl_error closes the client connection, so you need to reopen it again in your testcase. Look at test v00011.vtc for example -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 9 13:26:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jan 2012 13:26:03 -0000 Subject: [Varnish] #1074: Varnishlog -m ReqEnd: does not work In-Reply-To: <046.0801bd86e031008944b9c9f6e5735ff1@varnish-cache.org> References: <046.0801bd86e031008944b9c9f6e5735ff1@varnish-cache.org> Message-ID: <055.2347c11ed3a686ce51acd78114da3a5a@varnish-cache.org> #1074: Varnishlog -m ReqEnd: does not work ------------------------+--------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => worksforme Comment: Works fine for me in git master -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 9 15:22:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Jan 2012 15:22:33 -0000 Subject: [Varnish] #545: synthetic screws national characters In-Reply-To: <042.f079c136e5318647aaa256424b358694@varnish-cache.org> References: <042.f079c136e5318647aaa256424b358694@varnish-cache.org> Message-ID: <051.765961f59d65fefb994136ddbfbaeab5@varnish-cache.org> #545: synthetic screws national characters ----------------------+----------------------------------------------------- Reporter: kolo | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: reopened => closed * resolution: => fixed Comment: (In [6bec2c8361f4bb87e84e7760d0970f3d96e9d07f]) Fix a buglet in handling non-ascii strings in VCL, now that we (I) have decided what the strategy is going to be for synthetic in the future. Fixes #545 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 10 10:40:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jan 2012 10:40:17 -0000 Subject: [Varnish] #1083: Persistent Varnish crashes since using bans and lurker Message-ID: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> #1083: Persistent Varnish crashes since using bans and lurker -------------------------+-------------------------------------------------- Reporter: rmohrbacher | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.2 | Severity: major Keywords: | -------------------------+-------------------------------------------------- We use a farm with three persistent Varnishes (-s persistent,/cms/varnish_cache/persistent/varnish_storage.bin,204800M"). This Varnishes runs since 3 months without any crashes (in the moment not in production, but stressed with several stress tests). Since some days, we use bans and the lurker process (lurker-friendly bans via: ban("obj.http.x-url ~ " + req.url); We have about 250 bans/hour. Now we have the big problem, that the varnishes crashes after some hours. Curios: all three Varnishes crashes in the same moment. And they runs on three different Servers! The follow part from syslog suggest, that there is an problem with an invalid ban: Jan 9 19:40:32 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) died signal=6 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) Panic message: Missing errorhandling code in smp_append_sign(), storage_persistent_subr.c line 128:#012 Condition((smp_chk_sign(ctx)) == 0) not true.thread = (cache-worker)#012ident = Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44a346: /usr/sbin/varnishd(smp_append_sign+0x126) [0x44a346]#012 0x447b6d: /usr/sbin/varnishd(SMP_NewBan+0x3d) [0x447b6d]#012 0x4125c7: /usr/sbin/varnishd(BAN_Insert+0x1a7) [0x4125c7]#012 0x433bd5: /usr/sbin/varnishd(VRT_ban_string+0xc5) [0x433bd5]#012 0x7f91f39fa4be: ./vcl.PNU3fGhs.so(+0x24be) [0x7f91f39fa4be]#012 0x433863: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x433863]#012 0x417c22: /usr/sbin/varnishd(CNT_Session+0xb62) [0x417c22]#012 0x42efb8: /usr/sbin/varnishd() [0x42efb8]#012 0x42e19b: /usr/sbin/varnishd() [0x42e19b]#012sp = 0x7f91ed4ab008 {#012 fd = 15, id = 15, xid = 683670119,#012 client = 172.27.70.103 36115,#012 step = STP_RECV,#012 handling = deliver,#012 restarts = 0, esi_level = 0#012 flags = #012 bodystatus = 4#012 ws = 0x7f91ed4ab080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f91ed4abc90,+56,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7f91ed4ab080[sess]#012 "PURGE",#012 "105867846",#012 "HTTP/1.0",#012 },#012 worker = 0x7f91ef1faa80 {#012 ws = 0x7f91ef1facc0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7f91ef1e8a30,+32,(nil),+65536},#012 },#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012},#012 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: child (6907) Started Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Pushing vcls failed:#012CLI communication error (hdr) Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) died signal=6 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) Panic message: Assert error in smp_open(), storage_persistent.c line 320:#012 Condition((smp_valid_silo(sc)) == 0) not true.#012thread = (cache-main)#012ident = Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,no_waiter#012Backtrace:#012 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44756a: /usr/sbin/varnishd() [0x44756a]#012 0x444d57: /usr/sbin/varnishd(STV_open+0x27) [0x444d57]#012 0x42b525: /usr/sbin/varnishd(child_main+0xc5) [0x42b525]#012 0x43d5ec: /usr/sbin/varnishd() [0x43d5ec]#012 0x43de7c: /usr/sbin/varnishd() [0x43de7c]#012 0x7f92015684c7: /usr/lib64/varnish/libvarnish.so(+0x94c7) [0x7f92015684c7]#012 0x7f9201568b58: /usr/lib64/varnish/libvarnish.so(vev_schedule+0x88) [0x7f9201568b58]#012 0x43d7c2: /usr/sbin/varnishd(MGT_Run+0x132) [0x43d7c2]#012 0x44cacb: /usr/sbin/varnishd(main+0xd1b) [0x44cacb]#012 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said Child starts Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said CHK(0x7f91ffd26120 BAN 1 0x7f34723f4000 BAN 1) = 4 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 10 19:52:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jan 2012 19:52:06 -0000 Subject: [Varnish] #1084: VRT_synth_page in vcl_fetch Message-ID: <045.dd9ab447cdf614a5304ecbab409b377d@varnish-cache.org> #1084: VRT_synth_page in vcl_fetch ---------------------------------------+------------------------------------ Reporter: diecast | Type: defect Status: new | Priority: high Milestone: Varnish 3.0 dev | Component: varnishd Version: 3.0.2 | Severity: major Keywords: vcl panic segfault kernel | ---------------------------------------+------------------------------------ This is reproduced with a new Ubuntu Lucid instance. Caused by VRT_synth_page in vcl_fetch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 10 19:57:30 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Jan 2012 19:57:30 -0000 Subject: [Varnish] #1084: VRT_synth_page in vcl_fetch In-Reply-To: <045.dd9ab447cdf614a5304ecbab409b377d@varnish-cache.org> References: <045.dd9ab447cdf614a5304ecbab409b377d@varnish-cache.org> Message-ID: <054.ec6af40aa684eb9262a9f2cc21836312@varnish-cache.org> #1084: VRT_synth_page in vcl_fetch ------------------------------+--------------------------------------------- Reporter: diecast | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: varnishd Version: 3.0.2 | Severity: major Resolution: invalid | Keywords: vcl panic segfault kernel ------------------------------+--------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: synthetic only works in vcl_error -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jan 11 13:32:23 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Jan 2012 13:32:23 -0000 Subject: [Varnish] #1085: -w should not allow thread_pool_min to be 1 Message-ID: <043.f13738db6d7f57b1b7ef0ff3ebed7ffe@varnish-cache.org> #1085: -w should not allow thread_pool_min to be 1 ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: 3.0.2 Severity: trivial | Keywords: ----------------------+----------------------------------------------------- thread_pool_min must be at least 2, but -w allows it to be 1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 17 15:16:40 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jan 2012 15:16:40 -0000 Subject: [Varnish] #1051: child process died In-Reply-To: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> References: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> Message-ID: <054.a70099608868fa385e61ca00aa9538b2@varnish-cache.org> #1051: child process died -----------------------+---------------------------------------------------- Reporter: sreniaw | Type: defect Status: reopened | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by sreniaw2): * status: closed => reopened * resolution: fixed => Comment: I am having problem with persistent cache. Silo file is created using dd command with initial size of 35GBs. After two weeks varnish is starting crashing. I am using varnish-3.0.2-1.el5 on Centos Linux 5 x86_64 with 32 GB of physical memory and 33 GB of swap. dm-7 is only for silo file {{{ # iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util dm-7 0.00 0.00 1.29 163.92 111.77 1311.38 8.61 0.60 3.64 1.29 21.30 dm-7 0.00 0.00 0.00 662.00 0.00 5296.00 8.00 113.08 171.04 1.51 100.10 dm-7 0.00 0.00 2.00 646.00 256.00 5168.00 8.37 116.20 177.84 1.54 100.10 dm-7 0.00 0.00 0.00 647.52 0.00 5180.20 8.00 113.79 182.72 1.53 99.11 dm-7 0.00 0.00 4.00 640.00 312.00 5120.00 8.43 94.62 131.55 1.55 100.10 dm-7 0.00 0.00 2.00 620.00 216.00 4960.00 8.32 118.29 202.90 1.61 100.20 dm-7 0.00 0.00 4.00 645.00 416.00 5160.00 8.59 114.23 179.15 1.54 100.10 dm-7 0.00 0.00 0.00 611.00 0.00 4888.00 8.00 112.30 164.37 1.64 100.10 dm-7 0.00 0.00 3.00 581.00 424.00 4648.00 8.68 113.39 209.71 1.71 100.00 dm-7 0.00 0.00 4.00 594.00 512.00 4752.00 8.80 91.58 168.89 1.67 100.10 dm-7 0.00 0.00 2.00 708.00 112.00 5664.00 8.14 115.57 158.32 1.41 100.10 dm-7 0.00 0.00 4.00 658.00 376.00 5264.00 8.52 115.12 166.39 1.51 100.10 dm-7 0.00 0.00 2.00 527.00 256.00 4216.00 8.45 114.82 213.90 1.89 100.10 dm-7 0.00 0.00 0.00 680.00 0.00 5440.00 8.00 115.64 171.43 1.47 100.20 dm-7 0.00 0.00 19.80 599.01 633.66 4792.08 8.77 101.46 172.11 1.60 99.21 dm-7 0.00 0.00 1.00 664.00 128.00 5312.00 8.18 115.89 167.74 1.51 100.20 dm-7 0.00 0.00 5.00 622.00 360.00 4976.00 8.51 114.20 172.12 1.60 100.10 dm-7 0.00 0.00 3.00 582.00 224.00 4656.00 8.34 112.75 205.01 1.71 100.10 dm-7 0.00 0.00 0.00 667.00 0.00 5336.00 8.00 110.22 164.68 1.50 100.20 dm-7 0.00 0.00 1.00 669.00 128.00 5352.00 8.18 103.50 155.61 1.50 100.20 dm-7 0.00 0.00 3.00 596.00 240.00 4768.00 8.36 113.84 184.50 1.67 100.10 dm-7 0.00 0.00 10.89 564.36 807.92 4514.85 9.25 114.11 203.60 1.72 99.21 dm-7 0.00 0.00 4.00 617.00 264.00 4936.00 8.37 116.19 184.58 1.61 100.10 dm-7 0.00 0.00 3.00 607.00 224.00 4856.00 8.33 112.08 186.60 1.64 100.00 dm-7 0.00 0.00 0.00 698.00 0.00 5584.00 8.00 113.24 145.28 1.44 100.20 dm-7 0.00 0.00 0.00 6062.00 0.00 48496.00 8.00 1007.00 106.46 0.17 100.10 dm-7 0.00 0.00 0.00 750.00 0.00 6000.00 8.00 268.74 834.84 1.34 100.20 dm-7 0.00 0.00 0.00 656.00 0.00 5248.00 8.00 115.95 209.27 1.52 100.00 dm-7 0.00 0.00 0.00 730.00 0.00 5840.00 8.00 152.54 187.88 1.37 100.20 dm-7 0.00 0.00 15.84 55.45 2146.53 443.56 36.33 21.85 652.62 6.14 43.76 dm-7 0.00 0.00 4.00 0.00 512.00 0.00 128.00 0.03 6.75 6.75 2.70 dm-7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-7 0.00 0.00 3.00 0.00 288.00 0.00 96.00 0.00 1.33 1.33 0.40 dm-7 0.00 0.00 3.00 456.00 384.00 3648.00 8.78 38.76 64.82 0.66 30.40 dm-7 0.00 0.00 0.00 991.00 0.00 7928.00 8.00 119.20 120.89 1.01 100.20 dm-7 0.00 0.00 2.00 945.00 112.00 7560.00 8.10 114.86 114.68 1.06 100.20 dm-7 0.00 0.00 4.00 834.00 216.00 6672.00 8.22 118.92 138.72 1.19 100.10 dm-7 0.00 0.00 2.97 743.56 205.94 5948.51 8.24 117.64 156.17 1.33 99.21 dm-7 0.00 0.00 11.00 681.00 592.00 5448.00 8.73 117.81 176.87 1.45 100.00 }}} {{{ # ps axu | grep varnishd root 6462 0.0 0.0 34716380 1392 ? Ss Jan02 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish +-g varnish -S /etc/varnish/secret -p lru_interval 20 -p cli_timeout 60 -h classic,500009 -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 -p +thread_pool_min 500 -p thread_pool_max 4000 -p thread_pools 4 -p thread_pool_add_delay 2 -p session_linger 100 -p send_timeout 120 -p sess_timeout 10 -p listen_depth 4096 +-p nuke_limit 50 varnish 29817 25.9 0.0 0 0 ? Zl 22:29 4:48 [varnishd] }}} {{{ # ps axu | grep varnishd varnish 1870 25.4 2.4 55950024 808356 ? Sl 22:48 0:09 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish +-g varnish -S /etc/varnish/secret -p lru_interval 20 -p cli_timeout 60 -h classic,500009 -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 -p +thread_pool_min 500 -p thread_pool_max 4000 -p thread_pools 4 -p thread_pool_add_delay 2 -p session_linger 100 -p send_timeout 120 -p sess_timeout 10 -p listen_depth 4096 +-p nuke_limit 50 root 3969 0.0 0.0 61172 728 pts/3 R+ 22:48 0:00 grep varnishd root 6462 0.0 0.0 34716380 1400 ? Ss Jan02 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish +-g varnish -S /etc/varnish/secret -p lru_interval 20 -p cli_timeout 60 -h classic,500009 -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 -p +thread_pool_min 500 -p thread_pool_max 4000 -p thread_pools 4 -p thread_pool_add_delay 2 -p session_linger 100 -p send_timeout 120 -p sess_timeout 10 -p listen_depth 4096 +-p nuke_limit 50 }}} Next day: {{{ # ps axu | grep varnishd root 6462 0.0 0.0 34716380 1524 ? Ss Jan02 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish -g varnish -S /etc/varnish/secret -p lru_interval 20 -p cli_timeout 60 -h classic,500009 -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 -p thread_pool_min 500 -p thread_pool_max 4000 -p thread_pools 4 -p thread_pool_add_delay 2 -p session_linger 100 -p send_timeout 120 -p sess_timeout 10 -p listen_depth 4096 -p nuke_limit 50 varnish 14624 11.4 17.9 56139464 5921276 ? Sl 15:14 4:29 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish -g varnish -S /etc/varnish/secret -p lru_interval 20 -p cli_timeout 60 -h classic,500009 -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 -p thread_pool_min 500 -p thread_pool_max 4000 -p thread_pools 4 -p thread_pool_add_delay 2 -p session_linger 100 -p send_timeout 120 -p sess_timeout 10 -p listen_depth 4096 -p nuke_limit 50 }}} {{{ DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -u varnish -g varnish \ -S /etc/varnish/secret \ -p lru_interval=20 \ -p cli_timeout=60 \ -h classic,500009 \ -s malloc,30G -s persistent,/var/lib/varnish/store/silo,35433480192 \ -p thread_pool_min=500 \ -p thread_pool_max=4000 \ -p thread_pools=4 \ -p thread_pool_add_delay=2 \ -p session_linger=100 \ -p send_timeout=120 \ -p sess_timeout=10 \ -p listen_depth=4096 \ -p nuke_limit=50" }}} Any clues ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 17 15:36:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jan 2012 15:36:53 -0000 Subject: [Varnish] #1051: child process died In-Reply-To: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> References: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> Message-ID: <054.920be52a2f0e33cf33d38e3b835916eb@varnish-cache.org> #1051: child process died -----------------------+---------------------------------------------------- Reporter: sreniaw | Type: defect Status: reopened | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by sreniaw2): Logs provides clues: Jan 17 14:14:31 varnishd[6462]: Child (14624) said Dropped 10 segments to make free_reserve Jan 17 14:14:32 varnishd[6462]: Child (14624) said Silo completely loaded Jan 17 15:03:00 varnishd[6462]: Child (14624) said Out of space in persistent silo Jan 17 15:03:00 varnishd[6462]: Child (14624) said Committing suicide, restart will make space {{{ # du -sh /var/lib/varnish/store/silo 34G /var/lib/varnish/store/silo }}} {{{ # df -h /var/lib/varnish/store Filesystem Size Used Avail Use% Mounted on /dev/mapper/SysStor-Varnish 36G 34G 442M 99% /var/lib/varnish/store }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 17 15:37:50 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Jan 2012 15:37:50 -0000 Subject: [Varnish] #1051: child process died In-Reply-To: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> References: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> Message-ID: <054.8a19902de09a29c247e31f9c2d796317@varnish-cache.org> #1051: child process died -----------------------+---------------------------------------------------- Reporter: sreniaw | Type: defect Status: reopened | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by sreniaw2): {{{ Jan 17 14:14:31 varnishd[6462]: Child (14624) said Dropped 10 segments to make free_reserve Jan 17 14:14:32 varnishd[6462]: Child (14624) said Silo completely loaded Jan 17 15:03:00 varnishd[6462]: Child (14624) said Out of space in persistent silo Jan 17 15:03:00 varnishd[6462]: Child (14624) said Committing suicide, restart will make space }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 22 16:30:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 22 Jan 2012 16:30:31 -0000 Subject: [Varnish] #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data Message-ID: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data ----------------------+----------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- If VGZ_WrwGunzip is called again with junk data after end of gzip data, it will loop forever. Note that this does not happen if the junk data is part of the same input data buffer that contained the of gzip data, but it only happens on successive calls to VGZ_WrwGunzip and VGZ_Guzip has seen the end of gzip data. This has an increased probability of happening when doing streaming. See attached test case. Bug has been confirmed in both 3.0 and master. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 23 11:07:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jan 2012 11:07:21 -0000 Subject: [Varnish] #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data In-Reply-To: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> References: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> Message-ID: <053.f456391e833f51ce7a25e0e35bde04ea@varnish-cache.org> #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data ----------------------+----------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * version: 3.0.0 => 3.0.2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 23 13:28:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Jan 2012 13:28:02 -0000 Subject: [Varnish] #1051: child process died In-Reply-To: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> References: <045.f22d848aeef4ec1e301fd6d2603e1e88@varnish-cache.org> Message-ID: <054.844eaf7444dda071cc961c2c8da70367@varnish-cache.org> #1051: child process died ----------------------+----------------------------------------------------- Reporter: sreniaw | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * status: reopened => closed * resolution: => fixed Comment: @sreniaw2: What you are experiencing is running out of space, and persistent storage currently has no code to handle it, therefor it restarts. The fix PHK committed fixed corruption, which made restarting problematic, but does not solve the lack of LRU, which is distinct and a feature request. The only remedy for this is to make sure you do not run out of space. Either by caching content for a shorter duration or by increasing the available space. As this is a known limitation of persistent storage, and the correct code to fix it is a feature request, I'm closing this. This does not indicate we're not planning to fix it, just that we do not track feature requests in trac. I'm closing this as "fixed" because the corruption and origional assert should have been fixed. The LRU-thing is not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 24 12:07:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jan 2012 12:07:48 -0000 Subject: [Varnish] #1085: -w should not allow thread_pool_min to be 1 In-Reply-To: <043.f13738db6d7f57b1b7ef0ff3ebed7ffe@varnish-cache.org> References: <043.f13738db6d7f57b1b7ef0ff3ebed7ffe@varnish-cache.org> Message-ID: <052.e7d0db4b7e44ed4eb37fad4537ccd756@varnish-cache.org> #1085: -w should not allow thread_pool_min to be 1 ----------------------+----------------------------------------------------- Reporter: scoof | Owner: scoof Type: defect | Status: assigned Priority: lowest | Milestone: Component: varnishd | Version: 3.0.2 Severity: trivial | Keywords: ----------------------+----------------------------------------------------- Changes (by scoof): * owner: => scoof * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 24 21:58:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jan 2012 21:58:44 -0000 Subject: [Varnish] #1079: Test v00036.vtc fails with an expectation mismatch In-Reply-To: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> References: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> Message-ID: <058.90c60c6cacaed7e68974b3f20e23eabd@varnish-cache.org> #1079: Test v00036.vtc fails with an expectation mismatch -------------------------+-------------------------------------------------- Reporter: andreacampi | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------------------------------------- Comment(by andreacampi): Fixed by this commit, thanks! commit 3a1b9ca8fcf1e9c901f6e57b8863ec678f6538a7 Author: Poul-Henning Kamp Date: Tue Jan 24 19:35:28 2012 +0000 Make this test case more robust (and faster) by using the CLI to control backend health, rather than rely on probes. Submitted by: Federico G. Schwindt -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jan 24 22:04:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Jan 2012 22:04:56 -0000 Subject: [Varnish] #1079: Test v00036.vtc fails with an expectation mismatch In-Reply-To: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> References: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> Message-ID: <058.56e43f61fb28a6784b66f737ee293bbf@varnish-cache.org> #1079: Test v00036.vtc fails with an expectation mismatch --------------------------+------------------------------------------------- Reporter: andreacampi | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 26 06:01:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jan 2012 06:01:37 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> References: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> Message-ID: <055.862d1e1778f806c70571fc5b28fb48e1@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) -----------------------+---------------------------------------------------- Reporter: rzuidhof | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by nicholas): Got the same error, on varnish 3.0.2: FetchError c chunked read_error: 12 (Could not get storage) We have a peculiar mix of very many very small objects, like 100s of bytes, and some 2M+ objects. Setting nuke_limit=1000, in hope to free enough space. Nicholas -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jan 26 12:19:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Jan 2012 12:19:03 -0000 Subject: [Varnish] #1087: Requests dropped due to long headers are invisible Message-ID: <046.51b5f88fa91d9e1805a2c1d9b6719239@varnish-cache.org> #1087: Requests dropped due to long headers are invisible ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Currently Varnish will not be very specific if a connection is dropped due to overly long headers. It's assumed to be an attack or otherwise malicious. This makes it close to impossible for sysadmins to determine that it's happening and why. There needs to be a log entry for this, otherwise this can itself be used to mask attacks.... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jan 29 15:26:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 29 Jan 2012 15:26:35 -0000 Subject: [Varnish] #1088: Problem with download large file Message-ID: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> #1088: Problem with download large file --------------------------------------------+------------------------------- Reporter: advancehost | Type: defect Status: new | Priority: highest Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: big file, large file, download | --------------------------------------------+------------------------------- Hi have the varnish with apache and cpanel on 10 servers and on all server i have two problems. 1-If i download a file with 10M the download stop before completing the file size, ex. stop after downloaded 2M 2-If i download a file with 10GB the error 503 is displayed and the download not start. I am using this options to run the varnishd: varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/dead_pools 3 -p thread_pool_min 150 -p thread_pool_max 1500 -p thread_pool_add_delay 2 -p sess_workspace 32768 -s malloc,1G -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 30 10:56:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jan 2012 10:56:33 -0000 Subject: [Varnish] #1088: Problem with download large file In-Reply-To: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> References: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> Message-ID: <058.c4ece7691136a12adf8aef4d19800486@varnish-cache.org> #1088: Problem with download large file --------------------------------------------+------------------------------- Reporter: advancehost | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: big file, large file, download | --------------------------------------------+------------------------------- Changes (by kristian): * priority: highest => normal * severity: critical => normal Comment: Please post varnishlog data for the 10M download. And check syslog for assert errors. For the 10GB, you will need to instruct varnish not to cache, otherwise it wont work since you only have 1GB of cache. Posting VCL might help, and trying with Varnish 3.0.2. We also need varnishstat -1 output for bost cases. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 30 11:33:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jan 2012 11:33:29 -0000 Subject: [Varnish] #1088: Problem with download large file In-Reply-To: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> References: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> Message-ID: <058.3cf00eab29e9d05b45d9d9204f2cbe7f@varnish-cache.org> #1088: Problem with download large file --------------------------------------------+------------------------------- Reporter: advancehost | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: big file, large file, download | --------------------------------------------+------------------------------- Comment(by advancehost): My VLC is a minimal, i have only the backed default. How to set the varnish to not cache files downloadable(zip, mp3, tar.gz, gz, exe, etc)? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 30 15:53:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jan 2012 15:53:32 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.614949aafabd6f6acb854084c89c419a@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Comment(by guangnan): Save problem here. Really annoying that made my live site goes down. =< -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 30 15:57:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jan 2012 15:57:33 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.ff45f468f5ae63c459587f593bc01b20@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Comment(by guangnan): BTW, I'm having this problem on a 32bit Fedora with Varnish (varnish-2.1.5 SVN ) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jan 30 15:59:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Jan 2012 15:59:43 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <052.a575ba1e54d4f74ccd31df24caf62ff5@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+----------------------------------------------------- Reporter: acdha | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- Comment(by guangnan): {{{ Jan 30 15:38:36 (none) varnishd[11667]: child (11671) Started Jan 30 15:38:37 (none) varnishd[11667]: Pushing vcls failed: CLI communication error (hdr) Jan 30 15:38:37 (none) varnishd[11667]: Child (11671) died signal=6 Jan 30 15:38:37 (none) varnishd[11667]: Child (11671) Panic message: Assert error in smp_open_segs(), storage_persistent.c line 1026:#012 Condition(sg1->p.offset != sg->p.offset) not true.#012errno = 9 (Bad file descriptor)#012thread = (cache-main)#012ident = Linux,3.0.17-linode41,i686,-spersistent,-hcritbit,no_waiter#012Backtrace:#012 0x8070a34: varnishd() [0x8070a34]#012 0x8090818: varnishd() [0x8090818]#012 0x8091add: varnishd() [0x8091add]#012 0x808ba7c: varnishd(STV_open+0x1c) [0x808ba7c]#012 0x806f80f: varnishd(child_main+0xdf) [0x806f80f]#012 0x8081d9c: varnishd() [0x8081d9c]#012 0x8082722: varnishd(MGT_Run+0x212) [0x8082722]#012 0x80505d4: varnishd(main+0xeb4) [0x80505d4]#012 0xb74a5413: /lib/libc.so.6(__libc_start_main+0xf3) [0xb74a5413]#012 0x80509b9: varnishd() [0x80509b9]#012 Jan 30 15:38:37 (none) varnishd[11667]: Child (-1) said Jan 30 15:38:37 (none) varnishd[11667]: Child (-1) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From snapcase1993-tech at yahoo.com Tue Jan 10 22:13:01 2012 From: snapcase1993-tech at yahoo.com (Philip Seidel) Date: Tue, 10 Jan 2012 22:13:01 -0000 Subject: VARNISH_MIN_THREADS Message-ID: It appears that the -w option doesn't enforce the requirement that VARNISH_MIN_THREADS is >= 2. This causes issues with grace where requests for cached content are blocked rather than served stale. Also, the VARNISH_MIN_THREADS value in the default.vcl is set to 1 so this should probably be updated to meet the 2 thread minimum requirement. Feel free to contact me if there are any questions. This was already discussed on IRC. Thanks -- Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickroland78 at gmail.com Sun Jan 22 17:40:49 2012 From: nickroland78 at gmail.com (Nick Roland) Date: Sun, 22 Jan 2012 17:40:49 -0000 Subject: OpenVZ and Varnish Message-ID: Hi, I am having problems with Varnish inside OpenVZ container. Every time there is some "huge" disk load on any of containers on shared host Varnish breaks up and just "hangs" untill restarted manualy. I dont know if this is issue with OpenVZ or Varnish but I would like to find solution with this. OpenVZ kernel is 2.6.18-194.3.1.el5.028stab069.6 Varnish version is varnishd (varnish-3.0.1 revision 6152bf7) -------------- next part -------------- An HTML attachment was scrubbed... URL: