From varnish-bugs at projects.linpro.no Fri Jan 2 22:00:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 02 Jan 2009 22:00:03 -0000 Subject: [Varnish] #416: Segfault Message-ID: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> #416: Segfault -----------------+---------------------------------------------------------- Reporter: sky | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | -----------------+---------------------------------------------------------- {{{ #0 0x00007ff58d931095 in raise () from /lib/libc.so.6 #1 0x00007ff58d932af0 in abort () from /lib/libc.so.6 #2 0x000000000042111a in pan_ic (func=0x450cae "Tcheck", file=0x450cc0 "cache.h", line=674, cond=0x450cb5 "(t.b) != 0", err=0, xxx=0) at cache_panic.c:325 #3 0x000000000041c929 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:674 #4 0x000000000041c9e0 in http_findhdr (hp=0x7ff2e3c5e0b8, l=13, hdr=0x665f11 "Cache-Control:") at cache_http.c:194 #5 0x000000000041cb4f in http_GetHdr (hp=0x7ff2e3c5e0b8, hdr=0x665f11 "Cache-Control:", ptr=0x7fd25d1dd9d8) at cache_http.c:216 #6 0x000000000041cc34 in http_GetHdrField (hp=0x7ff2e3c5e0b8, hdr=0x665f10 "\016Cache-Control:", field=0x45a722 "s-maxage", ptr=0x7fd25d1dda98) at cache_http.c:244 #7 0x0000000000439714 in RFC2616_Ttl (sp=0x7fd146553008, hp=0x7ff2e3c5e0b8, obj=0x7ff2e3c5e000) at rfc2616.c:95 #8 0x0000000000439ba6 in RFC2616_cache_policy (sp=0x7fd146553008, hp=0x7ff2e3c5e0b8) at rfc2616.c:199 #9 0x00000000004122cf in cnt_fetch (sp=0x7fd146553008) at cache_center.c:406 #10 0x00000000004142d3 in CNT_Session (sp=0x7fd146553008) at steps.h:41 #11 0x0000000000422c89 in wrk_do_cnt_sess (w=0x7fd25d1e5c30, priv=0x7fd146553008) at cache_pool.c:362 #12 0x0000000000422320 in wrk_thread (priv=0x7ff58d543320) at cache_pool.c:276 #13 0x00007ff58e1013f7 in start_thread () from /lib/libpthread.so.0 #14 0x00007ff58d9d6b3d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 2 22:36:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 02 Jan 2009 22:36:18 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> References: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> Message-ID: <058.d2bf098f4c1dd6b500f05855ea818918@projects.linpro.no> #416: Segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): Basically, when the backend server responds with more than overflow number of headers, then RFC2616 can't find the right header and goes all wrong. Verifying this theory. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 2 22:51:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 02 Jan 2009 22:51:41 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> References: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> Message-ID: <058.c5ef360f2db79b809404a3d5ba7f8baf@projects.linpro.no> #416: Segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ Child (7473) Panic message: Assert error in Tcheck(), cache.h line 674: Condition((t.b) != 0) not true. thread = (cache-worker)sp = 0x7fd146553008 { fd = 62, id = 62, xid = 1884821607, client = 71.229.46.158:63958, step = STP_FETCH, handling = FETCH, ws = 0x7fd146553078 { id = "sess", {s,f,r,e} = {0x7fd1465537b0,,+1046,(nil),+32768}, }, worker = 0x7fd25d1e5c30 { }, vcl = { srcname = { "/etc/varnish/wikia.vcl", "Default", }, }, obj = 0x7ff2e3c5e000 { refcnt = 1, xid = 1884821607, ws = 0x7ff2e3c5e028 { overflow id = "obj", {s,f,r,e} = {0x7ff2e3c5e358,,+3173,(nil),+3240}, }, http = { ws = 0x7ff2e3c5e028 { overflow id = "obj", {s,f,r,e} = {0x7ff2e3c5e358,,+3173,(nil),+3240}, }, hd = { "Date: Fri, 02 Jan 2009 21:52:16 GMT", "Server: Apache", "X-Powered-By: PHP/5.2.6", "Set-Cookie: wgWikiaUniqueBrowserId=53b79d8118cd5934ad842b75f1614bea; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=2aa1e3cf299d2b9581658b9e6c79b131; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=b82a9929f72c2c8dddf021e7c577ee75; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=129e6d212adbaf71ac863ae1e70885ac; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=cfa728dec719008f19779e75fc71cf53; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=566af54f2cbff5ae33874287ddda5322; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=fa5227cefabb0c70aa7f3a9fdd94a8de; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=a1cd537d5a42f4dd408f3a05df70a63f; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=43246f7b7de987d6034fbc82e58377f3; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=667d74a4537b1ab4e3a4d0b5ff3c7a4c; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=b3030410a4a5b71585d387ca3b656b38; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=d34399a19132d64ce14b2d11cf9ea234; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=f06a1fcff0080c0f69bea68bbd19307a; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=61f6936b1539897cec3a73fcc7940a9f; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=f58ca732bd7882ad4fbd6b8551511926; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=1ef2caf59c25ee6ae4852fb7660686a4; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=2b37050fd489f480c2b51e4dd7e519d2; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=d61a114a1682e82d5fac140515343ea2; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=6e8f0012982687dcc226bbb610a42671; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=101551180608c234e10fef14b94fe514; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=858460d4596d12e8b5ff52171ef610bb; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=61054e0cca80df61a4fdc9a59ed66857; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "Set-Cookie: wgWikiaUniqueBrowserId=32083e108be5be49c77d5f92a35f007e; expires=Wed, 01-Jul-2009 21:52:16 GMT; path=/; domain=.wikia.com", "", }, }, len = 7084, store = { 7084 { 1f 8b 08 00 00 00 00 00 00 03 ed 5d 7b 73 db 46 |...........] {s.F| 92 ff fb fc 29 26 be 5a 5b 4e f1 21 c9 71 e2 93 |....)&.Z[N.!.q..| 45 67 6d cb 59 fb ca 8a b5 b1 72 4e 6a 6b 6b 0b | Egm.Y.....rNjkk.| 24 41 12 11 08 30 00 68 9a 5b fe f0 f7 eb ee c1 |$A...0.h. [......| [7020 more] }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 2 23:08:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 02 Jan 2009 23:08:38 -0000 Subject: [Varnish] #410: Varnish uses up all system RAM on OpenVZ VPS In-Reply-To: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> References: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> Message-ID: <061.ab74f876d30ed32c59128f8699e4f710@projects.linpro.no> #410: Varnish uses up all system RAM on OpenVZ VPS ---------------------+------------------------------------------------------ Reporter: eugaia | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 2.0 Severity: blocker | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by eugaia): * status: closed => reopened * resolution: worksforme => Comment: Replying to [comment:2 phk]: > I'm slightly surprised that Varnish would use 8 times as much RAM as you have given it storage, but absent information about what amount of traffic you throw at it or any other details, it is awfully hard for me to say something intelligent. So was I! I couldn't throw any traffic at Varnish. It basically rendered my VPS (i.e. the whole server) unusable when it started because it used up so much RAM, and I had to restart the server. I can get Varnish working perfectly ok on my home computer, and I have exactly the same configuration installed on my remote server (though they are compiled separately). I am only experiencing a problem on the remote server, which is a virtual private server, and therefore using a virtualized OS. I tried again, setting the SHM file to 10MB. Again it used up 875 of 883MB (there were 34MB used before I launched Varnish). I believe that it probably has to do with the virtualized environment that is used on OpenVZ, and how Varnish's SHM operations work with it. I don't know what information you're looking for. With a 10MB SHM file (I've not tried with higher), I am able to log into the admin server using telnet. I can start/stop Varnish (when I stop it, the RAM usage goes down from 881MB to 30MB). The stats for two requests reads as follows: ================== 4 Client connections accepted 4 Client requests received 0 Cache hits 0 Cache hits for pass 4 Cache misses 0 Backend connections success 0 Backend connections not attempted 0 Backend connections too many 4 Backend connections failures 0 Backend connections reuses 0 Backend connections recycles 0 Backend connections unused 1 N struct srcaddr 0 N active struct srcaddr 2 N struct sess_mem 1 N struct sess 0 N struct object 2 N struct objecthead 1 N struct smf 0 N small free smf 1 N large free smf 0 N struct vbe_conn 1 N struct bereq 80 N worker threads 80 N worker threads created 769 N worker threads not created 0 N worker threads limited 0 N queued work requests 0 N overflowed work requests 0 N dropped work requests 1 N backends 0 N expired objects 0 N LRU nuked objects 0 N LRU saved objects 0 N LRU moved objects 0 N objects on deathrow 0 HTTP header overflows 0 Objects sent with sendfile 4 Objects sent with write 0 Objects overflowing workspace 4 Total Sessions 4 Total Requests 0 Total pipe 0 Total pass 0 Total fetch 676 Total header bytes 1808 Total body bytes 4 Session Closed 0 Session Pipeline 0 Session Read Ahead 0 Session Linger 0 Session herd 1105 SHM records 980 SHM writes 0 SHM flushes due to overflow 0 SHM MTX contention 0 SHM cycles through buffer 8 allocator requests 0 outstanding allocations 0 bytes allocated 10485760 bytes free 0 SMA allocator requests 0 SMA outstanding allocations 0 SMA outstanding bytes 0 SMA bytes allocated 0 SMA bytes free 4 SMS allocator requests 0 SMS outstanding allocations 0 SMS outstanding bytes 1808 SMS bytes allocated 1808 SMS bytes freed 0 Backend requests made 1 N vcl total 1 N vcl available 0 N vcl discarded 1 N total active purges 1 N new purges added 0 N old purges deleted 0 N objects tested 0 N regexps tested against 0 N duplicate purges removed =========================== The VCL file is: =========================== backend default { .host = "127.0.0.1"; .port = "8000"; } sub vcl_recv { if (req.http.host ~ "^www.simpl.it$") { set req.http.host = "simpl.it"; error 301; } if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { remove req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { remove req.http.Accept-Encoding; } } if (req.http.host == "simpl.it" || req.http.host == "simpl") { if (req.url ~ "^/__/") { error 403; } if (req.url ~ "\.(png|jpg|gif|js|css)$") { lookup; } if (req.http.Cookie ~ "lang=[^;]+;" && ! req.url ~ "lang=[^;]+" ) { set req.url = req.url regsub (req.http.Cookie, "lang=([^;]+)(;.*)?", "&lang=\1"); } if (req.http.Cookie ~ "ssid=[^;]+" ) { set req.url = req.url regsub (req.http.Cookie, "ssid=([^;]+)(;.*)?", "&ssid=\1"); } if (req.request != "GET" && req.request != "HEAD" ) { set req.url = "/__/page.php?url=" req.url; pass; } } lookup; } sub vcl_error { if ( obj.status == 301 ) { set obj.http.Location = "http://" req.http.host req.url; } } sub vcl_miss { if (req.http.host == "simpl.it" || req.http.host == "simpl") { if (req.url ~ "^/__/") { error 404; } if (req.url ~ "^/_/images/text/") { if ( ! req.url ~ "^/_/images/text/[^/]+/[^/]+/[^/]+/[^/]+/[^/]+$" ) { error 404; } set bereq.url = "/__/text_image.php?" regsub ( req.url , "^/_/images/text/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)$" , "font=\1&size=\2&col=\3&bg=\4&word=\5" ); remove bereq.http.Cookie; ### CHANGE - send to PBMS (automatically?) - but cache them for say 30mins - so that cache doesn't become ridiculously large with text images } elsif (! req.url ~ "\.(png|jpg|gif|js|css)$") { set bereq.url = "/__/page.php?url=" req.url; } } fetch; } sub vcl_fetch { if ( ! obj.http.Cache-Control && ! obj.http.Expires ) { set obj.ttl = 10s; ### CHANGE - set to a higher amount later } if (req.http.host ~ "boslowen") { set obj.ttl = 1h; } deliver; } sub vcl_deliver { remove resp.http.Age; remove resp.http.Server; remove resp.http.Via; remove resp.http.X-Varnish; } ======================= What other information would be useful to you? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 3 11:30:49 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 03 Jan 2009 11:30:49 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> References: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> Message-ID: <058.888ff6a1de042ee9927d3ba49f1ee792@projects.linpro.no> #416: Segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * owner: => sky * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 4 04:55:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 04 Jan 2009 04:55:04 -0000 Subject: [Varnish] #410: Varnish uses up all system RAM on OpenVZ VPS In-Reply-To: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> References: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> Message-ID: <061.f9566edcf2d8d2f91f7ee47b056abef8@projects.linpro.no> #410: Varnish uses up all system RAM on OpenVZ VPS ---------------------+------------------------------------------------------ Reporter: eugaia | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 2.0 Severity: blocker | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by eugaia): I think the problem might be caused by the OpenVZ platform rather than a bug in Varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 4 08:59:23 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 04 Jan 2009 08:59:23 -0000 Subject: [Varnish] #410: Varnish uses up all system RAM on OpenVZ VPS In-Reply-To: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> References: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> Message-ID: <061.f158d374645a412e88f04cb9473b5422@projects.linpro.no> #410: Varnish uses up all system RAM on OpenVZ VPS ---------------------+------------------------------------------------------ Reporter: eugaia | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by perbu): * status: reopened => closed * resolution: => invalid Comment: This must be a OpenVZ issue. They probably have some silly limit on virtual memory or something. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 4 20:29:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 04 Jan 2009 20:29:16 -0000 Subject: [Varnish] #417: Segmentation fault with mal-formed regsub and regsuball Message-ID: <052.c2acfb1b1c831dab3c77b4549885376b@projects.linpro.no> #417: Segmentation fault with mal-formed regsub and regsuball ----------------------+----------------------------------------------------- Reporter: eugaia | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: minor | Keywords: segmentation fault regsub regsuball vcl ----------------------+----------------------------------------------------- I get a segmentation fault when code like: regsub (req.url, OR regsuball (req.http.host, (i.e. not being properly formed VCL) is included in the VCL file using Varnish 2.0.2. This should probably show a syntax error instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 4 23:57:11 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 04 Jan 2009 23:57:11 -0000 Subject: [Varnish] #408: Varnish crash with -h critbit In-Reply-To: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> References: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> Message-ID: <061.a45575e2a2fe8f051c91a8ec1f3cddec@projects.linpro.no> #408: Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * status: new => closed * resolution: => duplicate Comment: Duplicate of #414. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Jan 4 23:58:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 04 Jan 2009 23:58:04 -0000 Subject: [Varnish] #414: Another Varnish crash with -h critbit In-Reply-To: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> References: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> Message-ID: <061.b3f51fe15ce87aa0dc6d807aa89439db@projects.linpro.no> #414: Another Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Got this one again: {{{ Child (15012) died signal=6 Child (15012) Panic message: Assert error in HSH_Deref(), cache_hash.c line 440: Condition((oh)->magic == 0x1b96615d) not true. thread = (cache-timeout) Child cleanup complete }}} Finally I got a core-dump also. Backtrace: {{{ (gdb) bt #0 0x0000000000414807 in hsh_rush (oh=0xfcb4e48f0) at cache_hash.c:375 #1 0x0000000000414913 in HSH_Deref (o=0x1259d97000) at cache_hash.c:448 #2 0x000000000040f75d in cnt_deliver (sp=0x17ea972008) at cache_center.c:180 #3 0x0000000000410311 in CNT_Session (sp=0x17ea972008) at steps.h:42 #4 0x000000000041c42c in wrk_do_cnt_sess (w=0x7fffb1b8fa40, priv=Variable "priv" is not available. ) at cache_pool.c:398 #5 0x000000000041ba62 in wrk_thread (priv=0x806452ba0) at cache_pool.c:310 #6 0x0000000800aa7a88 in pthread_getprio () from /lib/libthr.so.3 #7 0x00007fffb1990000 in ?? () Cannot access memory at address 0x7fffb1b90000 (gdb) frame 1 #1 0x0000000000414913 in HSH_Deref (o=0x1259d97000) at cache_hash.c:448 448 hsh_rush(oh); (gdb) print *oh $2 = {magic = 462840157, mtx = {priv = 0xfc8ef1d00}, refcnt = 0, objects = { vtqh_first = 0x1259d97000, vtqh_last = 0x1259d97308}, hash = 0xfc8ef1d40 "/mmo/6/159/361/46_903995808_hoved.jpg#cache.finn.no#", hashlen = 53, digest = "?u?L???A?\200'?U,?\226?{:???\235!)S\n?[9?\215", __u = {__u_waitinglist = {vtqh_first = 0x12589e1230, vtqh_last = 0x12571c3fc8}, __u_coollist = {vtqe_next = 0x12589e1230, vtqe_prev = 0x12571c3fc8}}, u = {filler = {0x1020017, 0x0, 0x0}, n = { u_n_hoh_list = {vtqe_next = 0x1020017, vtqe_prev = 0x0}, u_n_hoh_head = 0x0, u_n_hoh_digest = 0}}} (gdb) frame 0 #0 0x0000000000414807 in hsh_rush (oh=0xfcb4e48f0) at cache_hash.c:375 375 VTAILQ_REMOVE(&oh->waitinglist, sp, list); (gdb) print *sp $3 = {magic = 462840157, fd = 0, id = 1532310336, xid = 18, restarts = 0, esis = 0, wrk = 0x0, sockaddrlen = 1486754376, mysockaddrlen = 18, sockaddr = 0x125b553380, mysockaddr = 0x320a1bbf00000036, mylsock = 0xb386f615cc218603, addr = 0xed04548a830894f6
, port = 0x4e41ed962570257d
, srcaddr = 0x13f99ec4, doclose = 0x0, http = 0xfcb4e4948, http0 = 0x4020015, ws = {{magic = 0, id = 0x0, s = 0x0, f = 0xa5a5a5a5a5a5a5a5
, r = 0x1b96615d
, e = 0x125b5533c0 "??\206{", overflow = 1}}, ws_ses = 0x125b54c800 "B\035\2052\001", ws_req = 0x125b54cb08 "", htc = {{ magic = 1532310528, fd = 18, ws = 0xda72b70d00000034, rxbuf = { b = 0x83d8aedd3bab7182
, e = 0x501ff09115825eec
}, pipeline = { b = 0x61ba5b30509ff99f
, e = 0xc8712787
}}}, t_open = 0, t_req = 3.8930478601126296e-313, t_resp = 1.6642861158692102e-316, t_end = 0, connect_timeout = 0, first_byte_timeout = 0, between_bytes_timeout = -2.4983353906949635e-127, grace = 2.2867342108946895e-315, step = 1532310592, cur_method = 18, handling = 1, sendbody = 0 '\0', wantbody = 0 '\0', err_code = 899649536, err_reason = 0x12359f9308 "", list = {vtqe_next = 0x1255519800, vtqe_prev = 0x6da9ac530000002e}, director = 0x82464dd154b4f770, vbe = 0x5b0f3d78c6e5d1c7, bereq = 0x503e5a2b3bbcc4ca, obj = 0x5aaa6ee, objhead = 0x0, vcl = 0x12589e13a8, mem = 0x8020014, workreq = {list = { vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0, priv = 0xa5a5a5a5a5a5a5a5}, acct = {first = 2.2867342108946895e-315, sess = 78841721984, req = 1, pipe = 78841696256, pass = 78841697032, fetch = 78841722048, hdrbytes = 5162986676217184305, bodybytes = 11177425214313201848}, nhashptr = 3786983412, ihashptr = 51184323, lhashptr = 2412129124, hashptr = 0xd585f48f} }}} In order to continue testing -h critbit, I really need some feedback on this. Ticket #408 seems to be a dupe of this one, so I closed it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 5 13:41:06 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 05 Jan 2009 13:41:06 -0000 Subject: [Varnish] #418: Segfault in cnt_lookup Message-ID: <049.42411f5feeab7b68ba4353832e0339d9@projects.linpro.no> #418: Segfault in cnt_lookup --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ #0 0x00007f67a2d30095 in raise () from /lib/libc.so.6 #1 0x00007f67a2d31af0 in abort () from /lib/libc.so.6 #2 0x000000000042111a in pan_ic (func=0x44f14d "cnt_lookup", file=0x44ee8f "cache_center.c", line=625, cond=0x44f17e "sp->objhead != NULL", err=11, xxx=0) at cache_panic.c:325 #3 0x0000000000412c29 in cnt_lookup (sp=0x7f436525c008) at cache_center.c:625 #4 0x000000000041423a in CNT_Session (sp=0x7f436525c008) at steps.h:38 #5 0x0000000000422c89 in wrk_do_cnt_sess (w=0x7f45a9c72c30, priv=0x7f436525c008) at cache_pool.c:362 #6 0x0000000000422320 in wrk_thread (priv=0x7f67a29432b0) at cache_pool.c:276 #7 0x00007f67a35003f7 in start_thread () from /lib/libpthread.so.0 #8 0x00007f67a2dd5b3d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () }}} in {{{ if (o == NULL) { /* * We hit a busy object, disembark worker thread and expect * hash code to restart us, still in STP_LOOKUP, later. */ assert(sp->objhead != NULL); if (params->diag_bitmap & 0x20) WSP(sp, SLT_Debug, "on waiting list <%s>", sp->objhead->hash); SES_Charge(sp); return (1); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 5 14:09:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 05 Jan 2009 14:09:53 -0000 Subject: [Varnish] #418: Segfault in cnt_lookup In-Reply-To: <049.42411f5feeab7b68ba4353832e0339d9@projects.linpro.no> References: <049.42411f5feeab7b68ba4353832e0339d9@projects.linpro.no> Message-ID: <058.9e514b1d58854cb8d86c748e22fb0636@projects.linpro.no> #418: Segfault in cnt_lookup --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * owner: => sky Comment: {{{ (gdb) p sp->obj->objhead->objects->vtqh_first $32 = (struct object *) 0x7f5fb4e76000 (gdb) p sp->obj $33 = (struct object *) 0x7f5fb4e7d000 (gdb) p sp->obj->objhead->objects->vtqh_first->objhead $34 = (struct objhead *) 0x7f432eb50430 (gdb) p sp->obj->objhead $35 = (struct objhead *) 0x7f432eb50430 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 6 06:26:59 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 06 Jan 2009 06:26:59 -0000 Subject: [Varnish] #408: Varnish crash with -h critbit In-Reply-To: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> References: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> Message-ID: <061.f9f41c99c2aaa1be9cb0e23cbf9dff2b@projects.linpro.no> #408: Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by dldhks366): * status: closed => reopened * resolution: duplicate => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 6 13:33:21 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 06 Jan 2009 13:33:21 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.8d82c57600170302dca25758c011f5e6@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): Could you please provide us with a Varnishstat from when this happens? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 6 13:34:32 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 06 Jan 2009 13:34:32 -0000 Subject: [Varnish] #392: Varnish installs but doesn't start on suse 10.3 (X86-64) In-Reply-To: <052.3c6bf685f7cf98159b81e6983206c77b@projects.linpro.no> References: <052.3c6bf685f7cf98159b81e6983206c77b@projects.linpro.no> Message-ID: <061.3322f1b92b0fbac7ef9d87cd014b1870@projects.linpro.no> #392: Varnish installs but doesn't start on suse 10.3 (X86-64) --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: task | Status: closed Priority: high | Milestone: Component: build | Version: 2.0 Severity: major | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: This looks like your varnishd binary got stripped too hard, which would either be because of user error or a bug in opensuse (especially given that the relevant build scripts have not changed in trunk, and trunk works for you). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 7 09:09:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 07 Jan 2009 09:09:56 -0000 Subject: [Varnish] #359: regsub documented as using $1, $2 etc, but actually uses \1, \2 for replacement strings In-Reply-To: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> References: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> Message-ID: <061.56a66c1a695c835fcd1443d4c95539ba@projects.linpro.no> #359: regsub documented as using $1,$2 etc, but actually uses \1, \2 for replacement strings ---------------------------+------------------------------------------------ Reporter: eugaia | Owner: Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: regsub | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: reopened => closed * resolution: => fixed Comment: This bug has been fixed in trunk, please don't reopen it because an older release still has the bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 7 09:10:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 07 Jan 2009 09:10:40 -0000 Subject: [Varnish] #408: Varnish crash with -h critbit In-Reply-To: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> References: <052.1dfd87ee48c6d695b0cbdaef82616f0a@projects.linpro.no> Message-ID: <061.b8c829ef514a18b17643370554a98d6f@projects.linpro.no> #408: Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: reopened => closed * resolution: => duplicate Comment: Duplicate of #414. (Resolving again as dldhks366 for some reason reopened this) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 7 09:13:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 07 Jan 2009 09:13:43 -0000 Subject: [Varnish] #410: Varnish uses up all system RAM on OpenVZ VPS In-Reply-To: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> References: <052.577f7cc74b7ad374f42f1810ecbe4620@projects.linpro.no> Message-ID: <061.647361febe9844acdf2eea78c11fec35@projects.linpro.no> #410: Varnish uses up all system RAM on OpenVZ VPS ---------------------+------------------------------------------------------ Reporter: eugaia | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Comment (by tfheen): eugaia, could you please try using -s malloc,10MB and see how much memory is consumed then? If that works fine, try with -s malloc,100MB. Even if we can't fix this, we can document that Varnish and OpenVZ doesn't play well together and either recommend people not use OpenVZ with Varnish, or if the abovementioned idea works, to use -s malloc. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 7 09:16:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 07 Jan 2009 09:16:27 -0000 Subject: [Varnish] #246: Make req available in vcl_deliver In-Reply-To: <058.53d2945701dca8896a94831a3f392163@projects.linpro.no> References: <058.53d2945701dca8896a94831a3f392163@projects.linpro.no> Message-ID: <067.83c914af32d4632e88e50be8723fdd66@projects.linpro.no> #246: Make req available in vcl_deliver --------------------------+------------------------------------------------- Reporter: alex.taggart | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------------+------------------------------------------------- Changes (by tfheen): * status: reopened => closed * resolution: => invalid Comment: This request has been moved to the wiki, so marking as invalid again. "Moved to wiki" does not mean "tossed in the bin", it means we are not keeping feature requests in the bug tracking system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 10 22:11:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 10 Jan 2009 22:11:28 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> References: <049.0d7375050ad3ab144226d798cfac7a66@projects.linpro.no> Message-ID: <058.41f81e41ab687f0b6617db00a5942bf2@projects.linpro.no> #416: Segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: (In [3498]) If we get more HTTP headers than we have room for (default: 28) we used to ignore the rest. This is not a bright solution if crucial HTTP headers like "Content-Length" or "Transfer-Encoding" are last and get ignored. In general, it is highly suspect to randomly ignore HTTP headers, as opposed to deliberately ignoring them, either by having first looked at them and found them uninteresting, or by having looked for the headers we care about, and having not matched some others. Change too many headers to firm error condition: 400 if from the client, and 503 (like every other trouble) if from the backend. Fixes #416 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 10 22:27:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 10 Jan 2009 22:27:39 -0000 Subject: [Varnish] #387: Varnish crashes on Missing errorhandling code in fetch_chunked In-Reply-To: <052.22bfa1b1cfef87b231048e0ed3d9726b@projects.linpro.no> References: <052.22bfa1b1cfef87b231048e0ed3d9726b@projects.linpro.no> Message-ID: <061.59da288336b370f77192564a8deecdca@projects.linpro.no> #387: Varnish crashes on Missing errorhandling code in fetch_chunked ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3500]) Don't panic if the chunked header is ridiculously long, just fail the transaction. Fixes #387 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 10 22:30:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 10 Jan 2009 22:30:05 -0000 Subject: [Varnish] #376: Varnish core-dumps on ctrl-c In-Reply-To: <052.e6b196f75eb9cb191e0cd030b908f316@projects.linpro.no> References: <052.e6b196f75eb9cb191e0cd030b908f316@projects.linpro.no> Message-ID: <061.70a08a2e273bc2b5b3eae8eaa4de85d6@projects.linpro.no> #376: Varnish core-dumps on ctrl-c ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3501]) Don't panic if we fail to delete shared objects in atexit(). Fixes #376 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 10 22:34:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 10 Jan 2009 22:34:08 -0000 Subject: [Varnish] #378: unresonable varnish free smf number In-Reply-To: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> References: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> Message-ID: <061.54d47c05fde7ce31699bfd47d64ada3d@projects.linpro.no> #378: unresonable varnish free smf number ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: blocker | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: If you have multiple storage devices configured, some of the counters are not locked globally and can get out of sync with reality. If you did not have multiple storage devices, we need to dig deeper. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 10 22:45:21 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 10 Jan 2009 22:45:21 -0000 Subject: [Varnish] #405: Varnish problem with purge requests In-Reply-To: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> References: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> Message-ID: <061.79655f4e0da30abee031154b2109606e@projects.linpro.no> #405: Varnish problem with purge requests ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Sorry about the delay. This is an interesting case, the crucial bit of the log is: {{{ 8 VCL_call c hash 8 VCL_return c hash 8 HitPass c 1525573757 8 VCL_call c pass 8 VCL_return c pass }}} Where your PURGE request hits a "you should pass this one" cache entry. Under normal circumstances you would not have such an entry. The good news is, your clients will get the right content for that URL because Varnish will ask the backend for it, for each client, until that cache entry expires. The bad news is that reduces your cache-hit rate. I am not sure we are able to properly recover using a PURGE, because by the time we get to vcl_pass{} we don't have the object anymore, so we cannot invalidate it. One thing you could do, as a work-around, is to put something like this in vcl_pass: {{{ sub vcl_pass { if (req.request == "PURGE") { purge_url ("^" req.url "$"); } } }}} But it is not quite perfect, because your URL will be treated like regexp. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 12 18:50:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 12 Jan 2009 18:50:57 -0000 Subject: [Varnish] #419: param esi syntax not documented Message-ID: <051.7373329eae51a8db9500657bbbf1f391@projects.linpro.no> #419: param esi syntax not documented ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ Hi. According to PHK esi_syntax=0x3 disables the XML requirements. This is not documented in the varnishd man page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 13 19:55:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Jan 2009 19:55:38 -0000 Subject: [Varnish] #420: Document string concatenation Message-ID: <051.5ed723d27fec71a2e8c24978ff211422@projects.linpro.no> #420: Document string concatenation ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ Hi. Strings can be concatenated in VCL. This is not documented in VCL. According to PHK on IRC strings are just concatenated like set req.foo = "foo" req.url "bar"; Suggested text: Strings are concatenated automatically. Just separate the string objects with spaces and they are concatenated. A note about where this doesn't happen would be useful. PHK? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 15:10:23 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 15:10:23 -0000 Subject: [Varnish] #405: Varnish problem with purge requests In-Reply-To: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> References: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> Message-ID: <061.d5d0b1112fa4e51b27bc37c7456bb03b@projects.linpro.no> #405: Varnish problem with purge requests ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * status: closed => reopened * resolution: worksforme => Comment: This syntax is not valid: {{{ Expected ')' got 'req.url' (program line 352), at (/usr/local/etc/varnish.vcl Line 147 Pos 40) purge_url ("^" req.url "$"); ---------------------------------------#######------ VCL compilation failed }}} It seems obj.ttl is not reachable in vcl_pass either. Is that fixable? If so we could just set it to 0? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 20:42:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 20:42:24 -0000 Subject: [Varnish] #418: Segfault in cnt_lookup In-Reply-To: <049.42411f5feeab7b68ba4353832e0339d9@projects.linpro.no> References: <049.42411f5feeab7b68ba4353832e0339d9@projects.linpro.no> Message-ID: <058.3f824304433af5032bd61703c44d1fe3@projects.linpro.no> #418: Segfault in cnt_lookup --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3512 and r3513: After HSH_Lookup() returns NULL indicating a busy object, we diddled the session a bit to transfer the per-request stats to the session counters with SES_Charge(). Not only was it inconsistent to charge accounting data in the middle of a request, it was also illegal because after the hash lock was released we no longer owned the session. Once a system is under sufficient load that there is a queue for the CPU, a race could happen where upon hitting a busy object, the hash lock was released, another thread would schedule, finish the busy object, start the sessions on the waiting list, finish off the request we had and then when we get the cpu again and access it, it's gone. The previous commit (r3512) eliminated the need to call SES_Charge, this commit removes the (option) shmlog message inside the hash lock thus, hopefully, eliminating the race that caused #418. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 20:44:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 20:44:05 -0000 Subject: [Varnish] #414: Another Varnish crash with -h critbit In-Reply-To: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> References: <052.d1b5f20b8f9b6ec243165098c2b9a912@projects.linpro.no> Message-ID: <061.2c4dc7c95bd4fde4395da6d98db57dfc@projects.linpro.no> #414: Another Varnish crash with -h critbit ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I suspect this could be the same issue as 418, in which case r3512+r3513 would have fixed it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 20:44:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 20:44:51 -0000 Subject: [Varnish] #420: Document string concatenation In-Reply-To: <051.5ed723d27fec71a2e8c24978ff211422@projects.linpro.no> References: <051.5ed723d27fec71a2e8c24978ff211422@projects.linpro.no> Message-ID: <060.c6326e66ef427a56e6aab08c1fe86c12@projects.linpro.no> #420: Document string concatenation ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by phk): Unfortunately, this is not (yet) universally the case in VCL, I need to go through and make it possible wherever a string is expected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 20:46:11 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 20:46:11 -0000 Subject: [Varnish] #391: Panic message: Assert error in cnt_lookup(), cache_center.c In-Reply-To: <053.29acd601888f493fb4fef82533c92d10@projects.linpro.no> References: <053.29acd601888f493fb4fef82533c92d10@projects.linpro.no> Message-ID: <062.7c1ba814b3518e4dc295580cc7950278@projects.linpro.no> #391: Panic message: Assert error in cnt_lookup(), cache_center.c ----------------------+----------------------------------------------------- Reporter: vrobert | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: This is the same as #418, closed as duplicate. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 14 20:48:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 14 Jan 2009 20:48:41 -0000 Subject: [Varnish] #405: Varnish problem with purge requests In-Reply-To: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> References: <052.cf256d302e48e7823f83c4eea4d95c5e@projects.linpro.no> Message-ID: <061.f23855a25065b64531745659a0951599@projects.linpro.no> #405: Varnish problem with purge requests ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: you'll have to stash it in a temporary header then: set req.http.foobar = "^" req.url "$"; purge_url(req.http.foobar); we have no object held in vcl_pass, so that is not possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 15 14:09:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 15 Jan 2009 14:09:27 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 Message-ID: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Running Varnish 2.0.2 in FreeBSD/amd64 7.0-RELEASE, I got: {{{ Jan 15 14:52:33 aicache8 kernel: varnishd(pid 77220 uid 0) aborted: Assert error in cnt_done(), cache_center.c line 209: Condition((sp->bereq) == 0) not true. errno = 54 (Connection reset by pe Jan 15 13:52:33 aicache8 varnishd[77219]: Child (77220) Panic message: Assert error in cnt_done(), cache_center.c line 209: Condition((sp->bereq) == 0) not true. errno = 54 (Connection reset by peer) thread = (cache-worker)sp = 0x807975008 { fd = 167, id = 167, xid = 1498840349, client = 80.91.40.241:59357, step = STP_DONE, handling = DELIVER, ws = 0x807975078 { id = "sess", {s,f,r,e} = {0x8079757b0,,+341,0x0,+8192}, }, worker = 0x7ffffb9ddac0 { }, vcl = { srcname = { "/usr/local/etc/varnish.vcl", "Default", }, }, }, }}} Unfortunately I did not get any coredump. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 16 08:32:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 16 Jan 2009 08:32:18 -0000 Subject: [Varnish] #378: unresonable varnish free smf number In-Reply-To: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> References: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> Message-ID: <061.5602b1598dced9b45cfa5216c573a613@projects.linpro.no> #378: unresonable varnish free smf number ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by 191919): * status: closed => reopened * resolution: worksforme => Comment: The strange value of counter is found when varnish stopped responding and a wget "localhost" timeouts and no reply received. The management port can be connected and give the above statistics. [[br]] (I did use multiple storages). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 16 12:47:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 16 Jan 2009 12:47:04 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.d04b45914c5dff63e9b01afec271d9ff@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by noah): I've recently tried to upgrade from 2.0-beta2 to 2.0.2 and run into this problem aswell. Symptoms: * Varnish does not accept() any new connections * Backend works OK! * CPU usage drops to zero There's nothing special in the VCL and it's basically made up of two modified sub routines: vcl_recv() ^-- remove and set a few header and checks and ACL, and the vc vcl_fetch() ^-- if(obj.status == 200) { set obj.ttl = time depending on req.url } Here's output from Varnishstat. {{{ 18167 0.00 19.64 Client connections accepted 184164 0.00 199.10 Client requests received 170510 0.00 184.34 Cache hits 1 0.00 0.00 Cache hits for pass 6493 0.00 7.02 Cache misses 13654 0.00 14.76 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 0 0.00 0.00 Backend connections failures 11972 0.00 12.94 Backend connections reuses 13355 0.00 14.44 Backend connections recycles 0 0.00 0.00 Backend connections unused 953 . . N struct srcaddr 4 . . N active struct srcaddr 1011 . . N struct sess_mem 6 . . N struct sess 2313 . . N struct object 2278 . . N struct objecthead 5252 . . N struct smf 620 . . N small free smf 37 . . N large free smf 1 . . N struct vbe_conn 10 . . N struct bereq 32 . . N worker threads 34 0.00 0.04 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 175 0.00 0.19 N overflowed work requests 0.00 0.00 N dropped work requests }}} Here's some lines from varnishlog before killing varnishd: {{{ 0 Debug - "Attempt Prefetch 662879512" 0 ExpPick - 662870028 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870028 -10 0 ExpPick - 662870039 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870039 -10 0 ExpPick - 662870042 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870042 -10 0 ExpPick - 662870053 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870053 -10 0 ExpPick - 662870209 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870209 -10 0 ExpPick - 662870214 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870214 -10 0 ExpPick - 662870215 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870215 -10 0 ExpPick - 662870220 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870220 -10 0 ExpPick - 662870226 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870226 -10 0 ExpPick - 662870227 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870227 -10 0 ExpPick - 662870234 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870234 -10 0 ExpPick - 662870235 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870235 -10 0 ExpPick - 662870240 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870240 -10 0 ExpPick - 662870241 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870241 -10 0 ExpPick - 662870245 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870245 -10 0 ExpPick - 662870246 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870246 -10 0 ExpPick - 662870250 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870250 -10 0 ExpPick - 662870251 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870251 -10 0 ExpPick - 662870252 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870252 -10 0 ExpPick - 662870256 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870256 -10 0 ExpPick - 662870257 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870257 -10 0 ExpPick - 662870262 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870262 -10 0 ExpPick - 662870263 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870263 -10 0 ExpPick - 662870267 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870267 -10 0 ExpPick - 662870268 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870268 -10 0 ExpPick - 662870275 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870275 -10 0 ExpPick - 662870276 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 662870276 -10 0 ExpPick - 662880125 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug - "Attempt Prefetch 662880125" 0 ExpPick - 662880218 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug - "Attempt Prefetch 662880218" 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1232109460 1.0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 16 12:49:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 16 Jan 2009 12:49:41 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.61a6963abb6a4ed0b441a8ccfd357943@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by noah): Replying to [comment:2 noah]: > I've recently tried to upgrade from 2.0-beta2 to 2.0.2 and run into this problem aswell. > Varnish was compiled from source with --prefix being the only option to ./configure. The OS is Ubuntu Linux 8.04.1 (2.6.24) on x86_64. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 16 15:42:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 16 Jan 2009 15:42:42 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.bff46f495caefc58903200dd8b4ba806@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by anders): * priority: normal => high * severity: normal => major Comment: This seems to happen often. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 16 15:44:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 16 Jan 2009 15:44:34 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.6c0e46b05fb9b8148d612c5dc347366c@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): From another cache server: {{{ Jan 16 11:57:02 aicache7 kernel: varnishd(pid 23320 uid 0) aborted: Assert error in cnt_done(), cache_center.c line 209: Condition((sp->bereq) == 0) not true. thread = (cache-worker)sp = 0x8078 Jan 16 10:57:02 aicache7 varnishd[87041]: Child (23320) Panic message: Assert error in cnt_done(), cache_center.c line 209: Condition((sp->bereq) == 0) not true. thread = (cache-worker)sp = 0x807879008 { fd = 102, id = 102, xid = 2070353154, client = 80.91.40.240:52121, step = STP_DONE, handling = DELIVER, ws = 0x807879078 { id = "sess", {s,f,r,e} = {0x8078797b0,,+324,0x0,+8192}, }, worker = 0x7ffff77bcac0 { }, vcl = { srcname = { "/usr/local/etc/varnish.vcl", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 17 21:07:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 17 Jan 2009 21:07:56 -0000 Subject: [Varnish] #422: varnishd crashes on VCL that contains ~! Message-ID: <058.6032c21a1dda1e90aeb3f323da81616a@projects.linpro.no> #422: varnishd crashes on VCL that contains ~! --------------------------+------------------------------------------------- Reporter: trent.nelson | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: --------------------------+------------------------------------------------- [root at wind/ttypt(..l/etc/varnish)#] cat dodge.vcl sub vcl_fetch { if (req.url ~! "www.google.com") { lookup; } } [root at wind/ttypt(..l/etc/varnish)#] varnishd -f dodge.vcl zsh: segmentation fault (core dumped) varnishd -f dodge.vcl [root at wind/ttypt(..l/etc/varnish)#] varnishd -V varnishd (varnish-2.0.2) Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS [root at wind/ttypt(..l/etc/varnish)#] ldd `which varnishd` /usr/local/sbin/varnishd: libvarnish.so.1 => /usr/local/lib/libvarnish.so.1 (0x280c7000) librt.so.1 => /usr/lib/librt.so.1 (0x280d2000) libvarnishcompat.so.1 => /usr/local/lib/libvarnishcompat.so.1 (0x280d7000) libvcl.so.1 => /usr/local/lib/libvcl.so.1 (0x280d9000) libthr.so.3 => /lib/libthr.so.3 (0x280ef000) libm.so.5 => /lib/libm.so.5 (0x28102000) libc.so.7 => /lib/libc.so.7 (0x28117000) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 17 21:09:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 17 Jan 2009 21:09:02 -0000 Subject: [Varnish] #423: varnishd crashes on VCL that contains ~! Message-ID: <058.c12eb9a00d91548eb82812916227e5b6@projects.linpro.no> #423: varnishd crashes on VCL that contains ~! --------------------------+------------------------------------------------- Reporter: trent.nelson | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: --------------------------+------------------------------------------------- {{{ [root at wind/ttypt(..l/etc/varnish)#] cat dodge.vcl sub vcl_fetch { if (req.url ~! "www.google.com") { lookup; } } [root at wind/ttypt(..l/etc/varnish)#] varnishd -f dodge.vcl zsh: segmentation fault (core dumped) varnishd -f dodge.vcl [root at wind/ttypt(..l/etc/varnish)#] varnishd -V varnishd (varnish-2.0.2) Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS [root at wind/ttypt(..l/etc/varnish)#] ldd `which varnishd` /usr/local/sbin/varnishd: libvarnish.so.1 => /usr/local/lib/libvarnish.so.1 (0x280c7000) librt.so.1 => /usr/lib/librt.so.1 (0x280d2000) libvarnishcompat.so.1 => /usr/local/lib/libvarnishcompat.so.1 (0x280d7000) libvcl.so.1 => /usr/local/lib/libvcl.so.1 (0x280d9000) libthr.so.3 => /lib/libthr.so.3 (0x280ef000) libm.so.5 => /lib/libm.so.5 (0x28102000) libc.so.7 => /lib/libc.so.7 (0x28117000) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Jan 17 21:12:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 17 Jan 2009 21:12:41 -0000 Subject: [Varnish] #422: varnishd crashes on VCL that contains ~! In-Reply-To: <058.6032c21a1dda1e90aeb3f323da81616a@projects.linpro.no> References: <058.6032c21a1dda1e90aeb3f323da81616a@projects.linpro.no> Message-ID: <067.c63f5fef18933c5561b999fcc5ff52d1@projects.linpro.no> #422: varnishd crashes on VCL that contains ~! --------------------------+------------------------------------------------- Reporter: trent.nelson | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: | --------------------------+------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: Duplicate of 423, closing -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 12:52:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 12:52:31 -0000 Subject: [Varnish] #386: Varnish sometimes fails to insert ESI snippet In-Reply-To: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> References: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> Message-ID: <060.16ce7f8de5d781f53659015cf7e8c85b@projects.linpro.no> #386: Varnish sometimes fails to insert ESI snippet --------------------+------------------------------------------------------- Reporter: peter | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [3528]) Merge r3433: When we receive an If-Modified-Since on an ESI object, do not process the conditional for the child object and pretend to send a 304 reply for them, if we have decided to deliver the main object. Fixes #386 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 12:57:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 12:57:26 -0000 Subject: [Varnish] #359: regsub documented as using $1, $2 etc, but actually uses \1, \2 for replacement strings In-Reply-To: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> References: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> Message-ID: <061.c7a10d067f9e40118caf2f385336035c@projects.linpro.no> #359: regsub documented as using $1,$2 etc, but actually uses \1, \2 for replacement strings ---------------------------+------------------------------------------------ Reporter: eugaia | Owner: Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: regsub | ---------------------------+------------------------------------------------ Comment (by tfheen): (In [3529]) Merge r3361: Fix up $N vs \N in man page The VCL man page documented the capturing parentheses as using $N rather than \N which is actually used. Fixes #359 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 13:08:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 13:08:10 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.f08ffeab3fc63f807ab31c65f413e8b3@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): This is some marginal path where the space we used to talk to the backend has not been released. r3530 may make this worse or better, it gets much more stringent about berequests and adds a couple of free's that could be responsible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 13:21:36 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 13:21:36 -0000 Subject: [Varnish] #423: varnishd crashes on VCL that contains ~! In-Reply-To: <058.c12eb9a00d91548eb82812916227e5b6@projects.linpro.no> References: <058.c12eb9a00d91548eb82812916227e5b6@projects.linpro.no> Message-ID: <067.0da32b650d045fefec1e90c07ad8bdea@projects.linpro.no> #423: varnishd crashes on VCL that contains ~! --------------------------+------------------------------------------------- Reporter: trent.nelson | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This was fixed a month ago in r3466 in trunk, and your traceback looks like 2.0.2 ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 13:24:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 13:24:14 -0000 Subject: [Varnish] #362: Add malloc size option to varnishd.1 manual page In-Reply-To: <048.6d6293d69bbb64b321d0094c7f25f6f5@projects.linpro.no> References: <048.6d6293d69bbb64b321d0094c7f25f6f5@projects.linpro.no> Message-ID: <057.6572d6964c098607f65072b15765747a@projects.linpro.no> #362: Add malloc size option to varnishd.1 manual page ---------------------------+------------------------------------------------ Reporter: mm | Owner: phk Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Comment (by tfheen): (In [3531]) Merge r3362: Document the size parameter to -s malloc Fixes #362 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 14:28:11 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 14:28:11 -0000 Subject: [Varnish] #365: Calling "restart" from "vcl_hit" serves an empty request. In-Reply-To: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> References: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> Message-ID: <062.8417349a395d47237bee7b6ca377f121@projects.linpro.no> #365: Calling "restart" from "vcl_hit" serves an empty request. ----------------------+----------------------------------------------------- Reporter: nkallen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3536]) Merge r3386: Implement restart in vcl_hit. Fixes #365 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 19 14:29:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Jan 2009 14:29:24 -0000 Subject: [Varnish] #424: test c00014 failure on RHEL 4u7 build Message-ID: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> #424: test c00014 failure on RHEL 4u7 build -------------------+-------------------------------------------------------- Reporter: kwy | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- 1 out of 99 tests fail in package building on RHEL4 update 7 Part of build log: ---- c2 EXPECT resp.http.content-length (12) == 6 (6) failed ---- c1 EXPECT resp.http.content-length (6) == 12 (12) failed ---- TEST FILE: ././tests/c00014.vtc ---- TEST DESCRIPTION: Test parking second request on backend delay, then pass FAIL: ./tests/c00014.vtc -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 20 09:49:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 20 Jan 2009 09:49:57 -0000 Subject: [Varnish] #424: test c00014 failure on RHEL 4u7 build In-Reply-To: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> References: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> Message-ID: <058.3f1b81c0d6f11fd4b99a4f3221daf2bc@projects.linpro.no> #424: test c00014 failure on RHEL 4u7 build --------------------+------------------------------------------------------- Reporter: kwy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kwy): Varnish version is 2.0.2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 20 09:56:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 20 Jan 2009 09:56:41 -0000 Subject: [Varnish] #424: test c00014 failure on RHEL 4u7 build In-Reply-To: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> References: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> Message-ID: <058.cfa7f4176d211b654f979cbd004a84ea@projects.linpro.no> #424: test c00014 failure on RHEL 4u7 build --------------------+------------------------------------------------------- Reporter: kwy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kwy): 81 of 97 tests failed on RHEL 3 update 9 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 20 22:33:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 20 Jan 2009 22:33:02 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.4dedbc48ca99c2af85bb02b2eef0aa40@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Old description: > Hi, > > I have encountered a strange problem with varnish wherein it just hangs > and stops responding to http requests even though it is in running state > . The backends run without issue , one can telnet to varnish console also > . What could be the issue ? I had downloaded varnish from trunk also to > check if this issue goes but it tends to reoccur . I get following > messages in varnishlog . > > 0 VCL_return - discard > 0 ExpKill - 958922603 -30 > 0 ExpPick - 958922604 ttl > 0 VCL_call - timeout > 0 VCL_return - discard > 0 ExpKill - 958922604 -30 > 0 ExpPick - 958922605 ttl > 0 VCL_call - timeout > 0 VCL_return - discard > 0 ExpKill - 958922605 -30 > 0 ExpPick - 958930071 prefetch > 0 VCL_call - prefetch > 0 VCL_return - fetch > 0 Debug - "Attempt Prefetch 958930071" > 0 ExpPick - 958922606 ttl > 0 VCL_call - timeout > 0 VCL_return - discard > 0 ExpKill - 958922606 -30 > 0 ExpPick - 958930072 prefetch > 0 VCL_call - prefetch > 0 VCL_return - fetch > 0 Debug - "Attempt Prefetch 958930072" > 0 ExpPick - 959145014 ttl > 0 VCL_call - timeout > 0 VCL_return - discard > > Thanks in advance. > > -Paras New description: Hi, I have encountered a strange problem with varnish wherein it just hangs and stops responding to http requests even though it is in running state . The backends run without issue , one can telnet to varnish console also . What could be the issue ? I had downloaded varnish from trunk also to check if this issue goes but it tends to reoccur . I get following messages in varnishlog . {{{ 0 VCL_return - discard 0 ExpKill - 958922603 -30 0 ExpPick - 958922604 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 958922604 -30 0 ExpPick - 958922605 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 958922605 -30 0 ExpPick - 958930071 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug - "Attempt Prefetch 958930071" 0 ExpPick - 958922606 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 958922606 -30 0 ExpPick - 958930072 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug - "Attempt Prefetch 958930072" 0 ExpPick - 959145014 ttl 0 VCL_call - timeout 0 VCL_return - discard }}} Thanks in advance. -Paras -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 21 08:38:09 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Jan 2009 08:38:09 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.f6f65c9962b041baf0fbda1280ef7e59@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kvaade): We experience the same kind of problem with version 2.0.2... Our vcl.conf is very simple: # # This is a basic VCL configuration file for varnish. See the vcl(7) # man page for details on VCL syntax and semantics. # # $Id: vcl.conf 1200 2006-10-19 09:21:42Z des $ # backend default { set backend.host = "127.0.0.1"; set backend.port = "90"; } sub vcl_recv { # pass mode can't handle POST (yet) if (req.request == "POST") { pipe; } # force lookup even when cookies are present if (req.request == "GET" && req.http.cookie) { lookup; } } #sub vcl_fetch { # if (req.url ~ "template") { # set obj.ttl = 3s; # } elseif (obj.ttl < 300s) { # set obj.ttl = 300s; # } #} sub vcl_fetch { if (obj.ttl < 2s) { set obj.ttl = 1s; } } Varnishstat: 0+00:44:18 grandis09 Hitrate ratio: 1 1 1 Hitrate avg: 0.0306 0.0306 0.0306 45 0.00 0.02 Client connections accepted 116 0.00 0.04 Client requests received 3 0.00 0.00 Cache hits 0 0.00 0.00 Cache hits for pass 95 0.00 0.04 Cache misses 95 0.00 0.04 Backend connections success 0 0.00 0.00 Backend connections failures 0 0.00 0.00 Backend connections reuses 0 0.00 0.00 Backend connections recycles 8 0.00 0.00 Backend connections unused 2 . . N struct srcaddr 1 . . N active struct srcaddr 25 . . N struct sess_mem 25 . . N struct sess 30 . . N struct object 30 . . N struct objecthead 20 . . N struct smf 5 . . N small free smf 0 . . N large free smf 13 . . N struct vbe_conn Varnishlog (at the start of the log everything is OK, at the lower part Varnish hangs): 16 ReqStart c 194.19.36.2 34546 902563468 16 RxRequest c GET 16 RxURL c /multimedia/dynamic/00069/14NYHHAguddingsmo002_69559p.jpg 16 RxProtocol c HTTP/1.1 16 RxHeader c Host: grandis09.adresseavisen.no 16 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 16 RxHeader c Accept: image/png,image/*;q=0.8,*/*;q=0.5 16 RxHeader c Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 16 RxHeader c Accept-Encoding: gzip,deflate 16 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 16 RxHeader c Keep-Alive: 300 16 RxHeader c Connection: keep-alive 16 RxHeader c Referer: http://grandis09.adresseavisen.no/ 16 RxHeader c Cookie: __utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; __utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; __utmc=2304850; __utmb=112304850.17.10.1232 16 VCL_call c recv 16 VCL_return c lookup 16 VCL_call c hash 16 VCL_return c hash 16 VCL_call c miss 16 VCL_return c fetch 24 BackendOpen b default 127.0.0.1 44110 127.0.0.1 90 24 BackendXID b 902563468 16 Backend c 24 default 24 TxRequest b GET 24 TxURL b /multimedia/dynamic/00069/14NYHHAguddingsmo002_69559p.jpg 24 TxProtocol b HTTP/1.1 24 TxHeader b Host: grandis09.adresseavisen.no 24 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 24 TxHeader b Accept: image/png,image/*;q=0.8,*/*;q=0.5 24 TxHeader b Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 24 TxHeader b Accept-Encoding: gzip,deflate 24 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 TxHeader b Referer: http://grandis09.adresseavisen.no/ 24 TxHeader b Cookie: __utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; __utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; __utmc=2304850; __utmb=112304850.17.10.1232 24 TxHeader b X-Varnish: 902563468 24 TxHeader b X-Forwarded-for: 194.19.36.2 24 RxProtocol b HTTP/1.1 24 RxStatus b 200 24 RxResponse b OK 24 RxHeader b Date: Tue, 20 Jan 2009 14:30:28 GMT 24 RxHeader b Server: Resin/3.1.8 24 RxHeader b Content-Type: image/jpeg 24 RxHeader b Connection: close 24 RxHeader b Transfer-Encoding: chunked 16 ObjProtocol c HTTP/1.1 16 ObjStatus c 200 16 ObjResponse c OK 16 ObjHeader c Date: Tue, 20 Jan 2009 14:30:28 GMT 16 ObjHeader c Server: Resin/3.1.8 16 ObjHeader c Content-Type: image/jpeg 24 BackendClose b default 16 TTL c 902563468 RFC 120 1232461828 1232461828 0 0 0 16 VCL_call c fetch 16 VCL_return c insert 16 Length c 4299 16 VCL_call c deliver 16 VCL_return c deliver 16 TxProtocol c HTTP/1.1 16 TxStatus c 200 16 TxResponse c OK 16 TxHeader c Date: Tue, 20 Jan 2009 14:30:28 GMT 16 TxHeader c Server: Resin/3.1.8 16 TxHeader c Content-Type: image/jpeg 16 TxHeader c Content-Length: 4299 16 TxHeader c X-Varnish: 902563468 16 TxHeader c Age: 0 16 TxHeader c Via: 1.1 varnish 16 ReqEnd c 902563468 1232461828.629636049 1232461828.749588013 0.0566091 0.119915009 0.000036955 0 StatAddr 194.19.36.2 0 139 112 382 0 0 345 67281 6177207 28 SessionOpen c 194.19.36.2 34557 28 Debug c "/multimedia/dynamic/00069/DSO_69532h.jpg#grandis09.adresavisen.no#" 37 ReqStart c 194.19.36.2 34552 902563475 37 RxRequest c GET 37 RxURL c /multimedia/dynamic/00069/15NYHHAgjerstad013_3_69582d.jpg 37 RxProtocol c HTTP/1.1 37 RxHeader c Host: grandis09.adresseavisen.no 37 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 37 RxHeader c Accept: image/png,image/*;q=0.8,*/*;q=0.5 37 RxHeader c Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 37 RxHeader c Accept-Encoding: gzip,deflate 37 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 37 RxHeader c Keep-Alive: 300 37 RxHeader c Connection: keep-alive 37 RxHeader c Referer: http://grandis09.adresseavisen.no/ 37 RxHeader c Cookie: __utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; __utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; __utmc=2304850; __utmb=112304850.17.10.1232 37 VCL_call c recv 37 VCL_return c lookup 37 VCL_call c hash 37 VCL_return c hash 37 VCL_call c miss 37 VCL_return c fetch 46 BackendOpen b default 127.0.0.1 44117 127.0.0.1 90 46 BackendXID b 902563475 37 Backend c 46 default 46 TxRequest b GET 46 TxURL b /multimedia/dynamic/00069/15NYHHAgjerstad013_3_69582d.jpg 46 TxProtocol b HTTP/1.1 46 TxHeader b Host: grandis09.adresseavisen.no 46 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 46 TxHeader b Accept: image/png,image/*;q=0.8,*/*;q=0.5 46 TxHeader b Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 46 TxHeader b Accept-Encoding: gzip,deflate 46 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 46 TxHeader b Referer: http://grandis09.adresseavisen.no/ 46 TxHeader b Cookie: __utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; __utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; __utmc=2304850; __utmb=112304850.17.10.1232 46 TxHeader b X-Varnish: 902563475 46 TxHeader b X-Forwarded-for: 194.19.36.2 46 RxProtocol b HTTP/1.1 46 RxStatus b 200 46 RxResponse b OK 46 RxHeader b Date: Tue, 20 Jan 2009 14:30:28 GMT 46 RxHeader b Server: Resin/3.1.8 46 RxHeader b Content-Type: image/jpeg 46 RxHeader b Connection: close 46 RxHeader b Transfer-Encoding: chunked 37 ObjProtocol c HTTP/1.1 37 ObjStatus c 200 37 ObjResponse c OK 37 ObjHeader c Date: Tue, 20 Jan 2009 14:30:28 GMT 37 ObjHeader c Server: Resin/3.1.8 37 ObjHeader c Content-Type: image/jpeg 46 BackendClose b default 37 TTL c 902563475 RFC 120 1232461828 1232461828 0 0 0 37 VCL_call c fetch 37 VCL_return c insert 37 Length c 13979 37 VCL_call c deliver 37 VCL_return c deliver 37 TxProtocol c HTTP/1.1 37 TxStatus c 200 37 TxResponse c OK 37 TxHeader c Date: Tue, 20 Jan 2009 14:30:28 GMT 37 TxHeader c Server: Resin/3.1.8 37 TxHeader c Content-Type: image/jpeg 37 TxHeader c Content-Length: 13979 37 TxHeader c X-Varnish: 902563475 37 TxHeader c Age: 0 37 TxHeader c Via: 1.1 varnish 37 ReqEnd c 902563475 1232461828.633925915 1232461828.750211954 0.0019804 0.116243124 0.000042915 0 StatAddr 194.19.36.2 0 139 113 383 0 0 346 67455 6191186 29 SessionOpen c 194.19.36.2 34558 29 Debug c "/multimedia/dynamic/00069/090114_-_Bellman_69531i.jpg#grdis09.adresseavisen.no#" 19 Debug c "/multimedia/dynamic/00068/pondus_front_68819h.jpg#grandi9.adresseavisen.no#" 23 Debug c "/multimedia/dynamic/00069/splatt_69454i.jpg#grandis09.adsseavisen.no#" 0 WorkThread 0x44004cf0 start 22 Debug c "/multimedia/dynamic/00069/090114_-_Midnight_Ch_69530i.jpgrandis09.adresseavisen.no#" 0 WorkThread 0x46008cf0 start 0 WorkThread 0x43002cf0 start 0 WorkThread 0x4a010cf0 start 16 Debug c "/multimedia/dynamic/00069/TS-20080317-NYHETER- _69455h.jpgrandis09.adresseavisen.no#" 13 Debug c "/multimedia/dynamic/00069/mosviksentrum_69449h.jpg#grand09.adresseavisen.no#" 37 Debug c "/multimedia/dynamic/00069/31REPkjellrun01_69506h.jpg#grais09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461830 14 SessionClose c timeout 14 StatSess c 192.168.101.83 17635 nan 1 4 0 0 2 974 30246 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461833 0 WorkThread 0x4a811cf0 start 14 SessionOpen c 194.19.36.2 34833 14 Debug c "/i/t.gif#grandis09.adresseavisen.no#" 0 WorkThread 0x4b012cf0 start 53 SessionOpen c 194.19.36.2 34834 0 WorkThread 0x4b813cf0 start 56 SessionOpen c 194.19.36.2 34836 53 Debug c "/multimedia/dynamic/00069/19KULmus_og_menn2_69604h.jpg#gndis09.adresseavisen.no#" 56 Debug c "/#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461836 0 WorkThread 0x4c014cf0 start 63 SessionOpen c 194.19.36.2 34910 63 Debug c "/template/ver1-0/css/none#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461839 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461842 0 WorkThread 0x4c815cf0 start 70 SessionOpen c 194.19.36.2 35144 70 Debug c "/nyheter/article60936.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461845 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461848 0 WorkThread 0x4d016cf0 start 73 SessionOpen c 194.19.36.2 35264 73 Debug c "/nyheter/article60943.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461851 0 WorkThread 0x4d817cf0 start 76 SessionOpen c 194.19.36.2 35466 76 Debug c "/nyheter/article60946.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461855 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461858 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 21 12:32:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Jan 2009 12:32:26 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.a1366c766e3492a6ae3955cf24e04551@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): By using a backported version of your patch (http://anders.fupp.net/diffs /patch-ticket421-try2-varnish2.0.2.diff), I get a crash another place in cache_center.c, at line 310 in the cnt_error function. This is the AZ(sp->bereq) that was introduced by r3530. {{{ Jan 20 18:09:03 aicache8 varnishd[68071]: Child (68072) Panic message: Assert er ror in cnt_error(), cache_center.c line 310: Condition((sp->bereq) == 0) not t rue. thread = (cache-worker)sp = 0x807f31008 { fd = 214, id = 214, xid = 1419 057355, client = 80.91.40.241:58819, step = STP_ERROR, handling = ERROR, err_code = 200, err_reason = Purged in pass mode., ws = 0x807f31078 { id = "sess", {s,f,r,e} = {0x807f317b0,,+223,0x0,+8192}, }, worker = 0x7f ffef37aac0 { }, vcl = { srcname = { "/usr/local/etc/varnis h.vcl", "Default", }, }, }, }}} How do we handle this? No coredump unfortunately. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 21 15:04:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Jan 2009 15:04:15 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.5f545af36393dd8ff7d9a7b7d175417d@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kvaade): Replying to [comment:5 kvaade]: I'm sorry, we actually use Varnish 1.1... Don't mind my former post... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 21 22:43:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Jan 2009 22:43:39 -0000 Subject: [Varnish] #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object Message-ID: <049.4b99dfd23383049079de7b680316dab4@projects.linpro.no> #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When we discover in vcl_fetch that an object must be passed, typically because of Set-Cookie headers, we create a special cache object that records this fact, so that future requests to this object will go directly from lookup to pass, rather than stall on the potentially busy object. If, due to backend headers, this special object gets a TTL of zero, all requests to this object ends up being serialized, as one request after another holds a busy object, stalling everybody else. Discovere: SEWilco -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 21 23:00:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Jan 2009 23:00:44 -0000 Subject: [Varnish] #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object In-Reply-To: <049.4b99dfd23383049079de7b680316dab4@projects.linpro.no> References: <049.4b99dfd23383049079de7b680316dab4@projects.linpro.no> Message-ID: <058.c2ac96f05510204ba944008b0bf0056d@projects.linpro.no> #425: Object pass'ed in vcl_fetch with TTL=0s can serialize that object ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3537]) Enforce a minimum ttl for "hit for pass" objects to prevent a value of zero from serializing access to an object with very draconian backend cache-control headers. We could get far even with a one second TTL, but following our general "there is a reason people put Varnish there in the first place" logic we use the default_ttl parameter (default: 120 s) for this value. If another value is desired, this can be set in vcl_fetch, even if it looks somewhat counter-intuitive: sub vcl_fetch { if (obj.http.set-cookie) { set obj.ttl = 10s; pass; } } Fixes #425 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 22 09:33:17 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 22 Jan 2009 09:33:17 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.a30346fc1ba20eff817df0eff1f9b32f@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by perbu): With proper formatting: {{{ 16 ReqStart? c 194.19.36.2 34546 902563468 16 RxRequest? c GET 16 RxURL c /multimedia/dynamic/00069/14NYHHAguddingsmo002_69559p.jpg 16 RxProtocol? c HTTP/1.1 16 RxHeader? c Host: grandis09.adresseavisen.no 16 RxHeader? c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 16 RxHeader? c Accept: image/png,image/*;q=0.8,*/*;q=0.5 16 RxHeader? c Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 16 RxHeader? c Accept-Encoding: gzip,deflate 16 RxHeader? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 16 RxHeader? c Keep-Alive: 300 16 RxHeader? c Connection: keep-alive 16 RxHeader? c Referer: http://grandis09.adresseavisen.no/ 16 RxHeader? c Cookie: utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; utmc=2304850; utmb=112304850.17.10.1232 16 VCL_call c recv 16 VCL_return c lookup 16 VCL_call c hash 16 VCL_return c hash 16 VCL_call c miss 16 VCL_return c fetch 24 BackendOpen? b default 127.0.0.1 44110 127.0.0.1 90 24 BackendXID b 902563468 16 Backend c 24 default 24 TxRequest? b GET 24 TxURL b /multimedia/dynamic/00069/14NYHHAguddingsmo002_69559p.jpg 24 TxProtocol? b HTTP/1.1 24 TxHeader? b Host: grandis09.adresseavisen.no 24 TxHeader? b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 24 TxHeader? b Accept: image/png,image/*;q=0.8,*/*;q=0.5 24 TxHeader? b Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 24 TxHeader? b Accept-Encoding: gzip,deflate 24 TxHeader? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 TxHeader? b Referer: http://grandis09.adresseavisen.no/ 24 TxHeader? b Cookie: utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; utmc=2304850; utmb=112304850.17.10.1232 24 TxHeader? b X-Varnish: 902563468 24 TxHeader? b X-Forwarded-for: 194.19.36.2 24 RxProtocol? b HTTP/1.1 24 RxStatus? b 200 24 RxResponse? b OK 24 RxHeader? b Date: Tue, 20 Jan 2009 14:30:28 GMT 24 RxHeader? b Server: Resin/3.1.8 24 RxHeader? b Content-Type: image/jpeg 24 RxHeader? b Connection: close 24 RxHeader? b Transfer-Encoding: chunked 16 ObjProtocol? c HTTP/1.1 16 ObjStatus? c 200 16 ObjResponse? c OK 16 ObjHeader? c Date: Tue, 20 Jan 2009 14:30:28 GMT 16 ObjHeader? c Server: Resin/3.1.8 16 ObjHeader? c Content-Type: image/jpeg 24 BackendClose? b default 16 TTL c 902563468 RFC 120 1232461828 1232461828 0 0 0 16 VCL_call c fetch 16 VCL_return c insert 16 Length c 4299 16 VCL_call c deliver 16 VCL_return c deliver 16 TxProtocol? c HTTP/1.1 16 TxStatus? c 200 16 TxResponse? c OK 16 TxHeader? c Date: Tue, 20 Jan 2009 14:30:28 GMT 16 TxHeader? c Server: Resin/3.1.8 16 TxHeader? c Content-Type: image/jpeg 16 TxHeader? c Content-Length: 4299 16 TxHeader? c X-Varnish: 902563468 16 TxHeader? c Age: 0 16 TxHeader? c Via: 1.1 varnish 16 ReqEnd? c 902563468 1232461828.629636049 1232461828.749588013 0.0566091 0.119915009 0.000036955 0 StatAddr? 194.19.36.2 0 139 112 382 0 0 345 67281 6177207 28 SessionOpen? c 194.19.36.2 34557 28 Debug c "/multimedia/dynamic/00069/DSO_69532h.jpg#grandis09.adresavisen.no#" 37 ReqStart? c 194.19.36.2 34552 902563475 37 RxRequest? c GET 37 RxURL c /multimedia/dynamic/00069/15NYHHAgjerstad013_3_69582d.jpg 37 RxProtocol? c HTTP/1.1 37 RxHeader? c Host: grandis09.adresseavisen.no 37 RxHeader? c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 37 RxHeader? c Accept: image/png,image/*;q=0.8,*/*;q=0.5 37 RxHeader? c Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 37 RxHeader? c Accept-Encoding: gzip,deflate 37 RxHeader? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 37 RxHeader? c Keep-Alive: 300 37 RxHeader? c Connection: keep-alive 37 RxHeader? c Referer: http://grandis09.adresseavisen.no/ 37 RxHeader? c Cookie: utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; utmc=2304850; utmb=112304850.17.10.1232 37 VCL_call c recv 37 VCL_return c lookup 37 VCL_call c hash 37 VCL_return c hash 37 VCL_call c miss 37 VCL_return c fetch 46 BackendOpen? b default 127.0.0.1 44117 127.0.0.1 90 46 BackendXID b 902563475 37 Backend c 46 default 46 TxRequest? b GET 46 TxURL b /multimedia/dynamic/00069/15NYHHAgjerstad013_3_69582d.jpg 46 TxProtocol? b HTTP/1.1 46 TxHeader? b Host: grandis09.adresseavisen.no 46 TxHeader? b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-N rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 46 TxHeader? b Accept: image/png,image/*;q=0.8,*/*;q=0.5 46 TxHeader? b Accept-Language: nb,no;q=0.8,nn;q=0.6,en- us;q=0.4,en;q=0. 46 TxHeader? b Accept-Encoding: gzip,deflate 46 TxHeader? b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 46 TxHeader? b Referer: http://grandis09.adresseavisen.no/ 46 TxHeader? b Cookie: utma=112304850.2329896987502384600.1228385752.12459661.1232461691.23; utmz=112304850.1232456212.21.9.utmcsr=grandis09|utmcc(referral)|utmcmd=referral|utmcct=/; JSESSIONID=abcj4fI_VAP_TbuzICZ7r; utmc=2304850; utmb=112304850.17.10.1232 46 TxHeader? b X-Varnish: 902563475 46 TxHeader? b X-Forwarded-for: 194.19.36.2 46 RxProtocol? b HTTP/1.1 46 RxStatus? b 200 46 RxResponse? b OK 46 RxHeader? b Date: Tue, 20 Jan 2009 14:30:28 GMT 46 RxHeader? b Server: Resin/3.1.8 46 RxHeader? b Content-Type: image/jpeg 46 RxHeader? b Connection: close 46 RxHeader? b Transfer-Encoding: chunked 37 ObjProtocol? c HTTP/1.1 37 ObjStatus? c 200 37 ObjResponse? c OK 37 ObjHeader? c Date: Tue, 20 Jan 2009 14:30:28 GMT 37 ObjHeader? c Server: Resin/3.1.8 37 ObjHeader? c Content-Type: image/jpeg 46 BackendClose? b default 37 TTL c 902563475 RFC 120 1232461828 1232461828 0 0 0 37 VCL_call c fetch 37 VCL_return c insert 37 Length c 13979 37 VCL_call c deliver 37 VCL_return c deliver 37 TxProtocol? c HTTP/1.1 37 TxStatus? c 200 37 TxResponse? c OK 37 TxHeader? c Date: Tue, 20 Jan 2009 14:30:28 GMT 37 TxHeader? c Server: Resin/3.1.8 37 TxHeader? c Content-Type: image/jpeg 37 TxHeader? c Content-Length: 13979 37 TxHeader? c X-Varnish: 902563475 37 TxHeader? c Age: 0 37 TxHeader? c Via: 1.1 varnish 37 ReqEnd? c 902563475 1232461828.633925915 1232461828.750211954 0.0019804 0.116243124 0.000042915 0 StatAddr? 194.19.36.2 0 139 113 383 0 0 346 67455 6191186 29 SessionOpen? c 194.19.36.2 34558 29 Debug c "/multimedia/dynamic/00069/090114_-_Bellman_69531i.jpg#grdis09.adresseavisen.no#" 19 Debug c "/multimedia/dynamic/00068/pondus_front_68819h.jpg#grandi9.adresseavisen.no#" 23 Debug c "/multimedia/dynamic/00069/splatt_69454i.jpg#grandis09.adsseavisen.no#" 0 WorkThread? 0x44004cf0 start 22 Debug c "/multimedia/dynamic/00069/090114_-_Midnight_Ch_69530i.jpgrandis09.adresseavisen.no#" 0 WorkThread? 0x46008cf0 start 0 WorkThread? 0x43002cf0 start 0 WorkThread? 0x4a010cf0 start 16 Debug c "/multimedia/dynamic/00069/TS-20080317-NYHETER- _69455h.jpgrandis09.adresseavisen.no#" 13 Debug c "/multimedia/dynamic/00069/mosviksentrum_69449h.jpg#grand09.adresseavisen.no#" 37 Debug c "/multimedia/dynamic/00069/31REPkjellrun01_69506h.jpg#grais09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461830 14 SessionClose? c timeout 14 StatSess? c 192.168.101.83 17635 nan 1 4 0 0 2 974 30246 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461833 0 WorkThread? 0x4a811cf0 start 14 SessionOpen? c 194.19.36.2 34833 14 Debug c "/i/t.gif#grandis09.adresseavisen.no#" 0 WorkThread? 0x4b012cf0 start 53 SessionOpen? c 194.19.36.2 34834 0 WorkThread? 0x4b813cf0 start 56 SessionOpen? c 194.19.36.2 34836 53 Debug c "/multimedia/dynamic/00069/19KULmus_og_menn2_69604h.jpg#gndis09.adresseavisen.no#" 56 Debug c "/#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461836 0 WorkThread? 0x4c014cf0 start 63 SessionOpen? c 194.19.36.2 34910 63 Debug c "/template/ver1-0/css/none#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461839 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461842 0 WorkThread? 0x4c815cf0 start 70 SessionOpen? c 194.19.36.2 35144 70 Debug c "/nyheter/article60936.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461845 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461848 0 WorkThread? 0x4d016cf0 start 73 SessionOpen? c 194.19.36.2 35264 73 Debug c "/nyheter/article60943.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461851 0 WorkThread? 0x4d817cf0 start 76 SessionOpen? c 194.19.36.2 35466 76 Debug c "/nyheter/article60946.ece#grandis09.adresseavisen.no#" 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461855 0 CLI Rd ping 0 CLI Wr 0 200 PONG 1232461858 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 22 13:46:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 22 Jan 2009 13:46:50 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.de733366b4608c2cacf38219eec4b19b@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by anders): We (Aftenposten & E24) are interested in helping sponsor this feature, provided that: 1) Forced grace always will work for any kind of backend error (network timeout, connection refused, response too slow, wrong http return code) 2) It works with a longer grace period, so that the backlog of cached data is longer. This shall not create problems for updates/purges for new content. 3) It is possible to control in VCL when forced grace should happen. For example if the backend delivers an unwanted 5xx http return code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 23 08:02:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Jan 2009 08:02:14 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.19b6d077cd6ad425de4e1bc978fc1bb2@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kvaade): For your information: Varnish doesn't hang anymore for us after we actually run version 2.0.2. :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 11:58:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 11:58:40 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.af43edab00d26e9a8a566d164c9d195f@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: kristian Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by perbu): * owner: phk => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 12:00:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 12:00:54 -0000 Subject: [Varnish] #415: Varnish Hangs In-Reply-To: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> References: <052.1ae6aa888aa0b4fd1a42dba13f520e37@projects.linpro.no> Message-ID: <061.07d91f3e60d8bf64eb3649d61fac025a@projects.linpro.no> #415: Varnish Hangs --------------------+------------------------------------------------------- Reporter: plfgoa | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: major | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Appearantly version confusion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 12:05:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 12:05:42 -0000 Subject: [Varnish] #419: param esi syntax not documented In-Reply-To: <051.7373329eae51a8db9500657bbbf1f391@projects.linpro.no> References: <051.7373329eae51a8db9500657bbbf1f391@projects.linpro.no> Message-ID: <060.27cc17212ab0f2e5e8f8fcb3cc9f8cf1@projects.linpro.no> #419: param esi syntax not documented ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Comment (by phk): All parameters have semi-comprehensive help if you type "param.show $name", in this case: {{{ param.show esi_syntax 200 429 esi_syntax 0 [bitmap] Default is 0 Bitmap controlling ESI parsing code: 0x00000001 - Don't check if it looks like XML 0x00000002 - Ignore non-esi elements 0x00000004 - Emit parsing debug records Use 0x notation and do the bitor in your head :-) }}} I am not sure to what extent we should replicate this in documentation, if we want to do that, we should certainly co-locate the explanations, so they do not get out of sync. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 12:18:52 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 12:18:52 -0000 Subject: [Varnish] #417: Segmentation fault with mal-formed regsub and regsuball In-Reply-To: <052.c2acfb1b1c831dab3c77b4549885376b@projects.linpro.no> References: <052.c2acfb1b1c831dab3c77b4549885376b@projects.linpro.no> Message-ID: <061.d0b4195a9131c4dec6c340eb0ce8447c@projects.linpro.no> #417: Segmentation fault with mal-formed regsub and regsuball -----------------------------------------------------+---------------------- Reporter: eugaia | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: minor | Resolution: fixed Keywords: segmentation fault regsub regsuball vcl | -----------------------------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3546 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 12:21:30 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 12:21:30 -0000 Subject: [Varnish] #406: Add information about ESI documents needing to be XML docs In-Reply-To: <052.92730d808dedd28564a2c2af6d65094d@projects.linpro.no> References: <052.92730d808dedd28564a2c2af6d65094d@projects.linpro.no> Message-ID: <061.8bf4bff438537744d86e952a3f2d8898@projects.linpro.no> #406: Add information about ESI documents needing to be XML docs ---------------------------------+------------------------------------------ Reporter: eugaia | Owner: Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: 2.0 Severity: trivial | Resolution: fixed Keywords: esi xml opening tag | ---------------------------------+------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: It is possible to tweak the ESI parser with the parameter esi_syntax now, that should solve this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 12:31:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 12:31:27 -0000 Subject: [Varnish] #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 In-Reply-To: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> References: <052.40b61854e54ab5b592a821d8a9656bb7@projects.linpro.no> Message-ID: <061.1481f3bb84b98711e354f3e4f9f0e1c5@projects.linpro.no> #421: Varnish crashes with Assert error in cnt_done, cache_center.c line 209 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): This seems gone from -trunk, but needs attention in 2.0.x -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 16:15:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 16:15:04 -0000 Subject: [Varnish] #426: Can't get the occurrences using "regsub". Message-ID: <058.887f38c4ba01f04859a3493305742721@projects.linpro.no> #426: Can't get the occurrences using "regsub". ----------------------------------+----------------------------------------- Reporter: basilio.vera | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: regsub occurrence $n | ----------------------------------+----------------------------------------- There's a bug introduced at some point between the 1.1.2 and 2.0.2 versions that breaks the possibility of use the "$n" matched strings. For example: {{{ sub vcl_recv { .... set req.http.Foo-value = regsub(req.http.Cookie, "(.*)(foo=[^;]+)(.*)", "$2"); .... } }}} In 1.1.2 versions I get in the server the header with the right value: "Foo-value: foo=test" In the 2.0.2 version all I get is: "$2". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 20:59:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 20:59:56 -0000 Subject: [Varnish] #427: Assert error in vsl_hdr(), shmlog.c line 85: Condition(id < 0x10000) not true. errno = 32 (Broken pipe) Message-ID: <049.d73a8332aff0a5cd62036c651653ebdf@projects.linpro.no> #427: Assert error in vsl_hdr(), shmlog.c line 85: Condition(id < 0x10000) not true. errno = 32 (Broken pipe) -------------------+-------------------------------------------------------- Reporter: tom | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Varnish dies every 30 / 60 minutes with the following error: {{{ Child (28511) died signal=6 (core dumped) Child (28511) Panic message: Assert error in vsl_hdr(), shmlog.c line 85: Condition(id < 0x10000) not true. errno = 32 (Broken pipe) thread = (cache-worker)sp = 0x7ff011428008 { fd = -1, id = 813, xid = 0, client = 212.45.52.229:42395, step = STP_RECV, handling = error, err_code = 200, err_reason = (null), ws = 0x7ff011428078 { id = "sess", {s,f,r,e} = {0x7ff011428808,,+1149,(nil),+16384}, }, worker = 0x4891ec40 { }, vcl = { srcname = { "input", "Default", }, }, }, }}} Backtrace: {{{ (gdb) bt #0 0x00007ff01cd973c5 in raise () from /lib/libc.so.6 #1 0x00007ff01cd9873e in abort () from /lib/libc.so.6 #2 0x00000000004210f0 in pan_ic (func=0x4593f0 "vsl_hdr", file=0x459406 "shmlog.c", line=85, cond=0x45940f "id < 0x10000", err=32, xxx=0) at cache_panic.c:317 #3 0x0000000000438cd5 in vsl_hdr (tag=SLT_VCL_call, p=0x4891cb90 "\026", len=4, id=4294967295) at shmlog.c:85 #4 0x0000000000439aea in WSL (w=0x4891ec40, tag=SLT_VCL_call, id=-1, fmt=0x450f35 "%s") at shmlog.c:266 #5 0x000000000042681a in VCL_recv_method (sp=0x7ff011428008) at ../../include/vcl_returns.h:23 #6 0x0000000000413982 in cnt_recv (sp=0x7ff011428008) at cache_center.c:818 #7 0x0000000000414441 in CNT_Session (sp=0x7ff011428008) at steps.h:34 #8 0x000000000042f2b0 in ESI_Deliver (sp=0x7ff011428008) at cache_vrt_esi.c:853 #9 0x0000000000423bbb in RES_WriteObj (sp=0x7ff011428008) at cache_response.c:150 #10 0x00000000004117ca in cnt_deliver (sp=0x7ff011428008) at cache_center.c:180 #11 0x00000000004145d9 in CNT_Session (sp=0x7ff011428008) at steps.h:42 #12 0x000000000042289b in wrk_do_cnt_sess (w=0x4891ec40, priv=0x7ff011428008) at cache_pool.c:398 #13 0x0000000000422336 in wrk_thread (priv=0x7ff01cc0b150) at cache_pool.c:310 #14 0x00007ff01d544037 in start_thread () from /lib/libpthread.so.0 #15 0x00007ff01ce2728d in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () (gdb) }}} Varnish is running on a Gentoo 64 bit system. Esi includes are used in the site. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 27 21:14:36 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 27 Jan 2009 21:14:36 -0000 Subject: [Varnish] #427: Assert error in vsl_hdr(), shmlog.c line 85: Condition(id < 0x10000) not true. errno = 32 (Broken pipe) In-Reply-To: <049.d73a8332aff0a5cd62036c651653ebdf@projects.linpro.no> References: <049.d73a8332aff0a5cd62036c651653ebdf@projects.linpro.no> Message-ID: <058.c7bde26d29df2a0910620960d18acd3d@projects.linpro.no> #427: Assert error in vsl_hdr(), shmlog.c line 85: Condition(id < 0x10000) not true. errno = 32 (Broken pipe) --------------------+------------------------------------------------------- Reporter: tom | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3547]) Stop processing ESI elements as soon as we discover that the client has closed the connection on us. Fixes #427 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 28 13:23:00 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 28 Jan 2009 13:23:00 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish Message-ID: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- While working on the web gui, I suddenly made Varnish die when sending bad input to the management port. Here is the backtrace [Switching to Thread 0xb7de36b0 (LWP 23570)] 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 "HASH(0x8839c4c)") at cache_acceptor.c:371 371 for (i = 0; vca_acceptors[i]->name; i++) { (gdb) bt #0 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 "HASH(0x8839c4c)") at cache_acceptor.c:371 #1 0x0807d3c3 in tweak_acceptor (cli=0xb7c0c628, par=0x809bb3c, arg=0xb7c05210 "HASH(0x8839c4c)") at mgt_param.c:421 #2 0x0807d843 in MCF_ParamSet (cli=0xb7c0c628, param=0xb7c05200 "acceptor", val=0xb7c05210 "HASH(0x8839c4c)") at mgt_param.c:860 #3 0x0807d8fa in mcf_param_set (cli=0xb7c0c628, av=0xb7c2e140, priv=0x0) at mgt_param.c:884 #4 0xb7fc8652 in cli_dispatch (cli=0xb7c0c628, clp=0x80a1d60, line=0xb7c79000 "param.set acceptor HASH(0x8839c4c)") at cli.c:133 #5 0x0807b706 in mgt_cli_vlu (priv=0xb7c0c610, p=0xb7c79000 "param.set acceptor HASH(0x8839c4c)") at mgt_cli.c:252 #6 0xb7fcbda0 in LineUpProcess (l=0xb7c071e0) at vlu.c:97 #7 0xb7fcbf9b in VLU_Fd (fd=9, l=0xb7c071e0) at vlu.c:122 #8 0x0807bce7 in mgt_cli_callback (e=0xb7c76290, what=1) at mgt_cli.c:347 #9 0xb7fcba9f in vev_schedule_one (evb=0xb7c0c5b0) at vev.c:500 #10 0xb7fcb2b6 in vev_schedule (evb=0xb7c0c5b0) at vev.c:365 #11 0x0807a0e3 in mgt_run (dflag=0, T_arg=0xbfce8745 ":9002") at mgt_child.c:560 #12 0x080870d2 in main (argc=0, argv=0xbfce6a84) at varnishd.c:639 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 28 13:48:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 28 Jan 2009 13:48:04 -0000 Subject: [Varnish] #428: Sending badly formed parameters to the management console kills Varnish In-Reply-To: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> References: <052.bfc72c097098110a4a483c75ec14892b@projects.linpro.no> Message-ID: <061.8725eba0dc66e35a4507357c0270a5d3@projects.linpro.no> #428: Sending badly formed parameters to the management console kills Varnish ----------------------+----------------------------------------------------- Reporter: petter | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by petter): Some more info: #0 0x08050b88 in VCA_tweak_acceptor (cli=0xb7c0c628, arg=0xb7c05210 "HASH(0x8820990)") at cache_acceptor.c:371 371 for (i = 0; vca_acceptors[i]->name; i++) { (gdb) print vca_acceptors $2 = {0x80a1504, 0x80a1518, 0x0} (gdb) print i $3 = 2 (gdb) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 28 14:32:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 28 Jan 2009 14:32:58 -0000 Subject: [Varnish] #409: Segmentation fault with malformed regex ~! In-Reply-To: <052.44f7b40c9e8de9781e864a9037b0b1de@projects.linpro.no> References: <052.44f7b40c9e8de9781e864a9037b0b1de@projects.linpro.no> Message-ID: <061.f6e142b595e8f0a11d6f377d4caf5aef@projects.linpro.no> #409: Segmentation fault with malformed regex ~! ----------------------+----------------------------------------------------- Reporter: eugaia | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3561]) Merge r3466: Add a missing error check. Fixes #409 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 28 20:25:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 28 Jan 2009 20:25:05 -0000 Subject: [Varnish] #429: Segfault in expire timer thread Message-ID: <049.82d6da0e75374723f1d3ca37c4634c37@projects.linpro.no> #429: Segfault in expire timer thread --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ #2 0x00000000004210ca in pan_ic (func=0x44ff3e "exp_timer", file=0x44fcd4 "cache_expire.c", line=294, cond=0x44fce3 "(o)->magic == 0x32851d42", err=0, xxx=0) at cache_panic.c:325 #3 0x0000000000417a0b in exp_timer (arg=0x0) at cache_expire.c:294 #4 0x00007f599cf753f7 in start_thread () from /lib/libpthread.so.0 }}} {{{ $2 = {magic = 0, refcnt = 0, xid = 0, objhead = 0x0, objstore = 0x0, objexp = 0x0, ws_o = {{magic = 0, id = 0x0, s = 0x0, f = 0x0, r = 0x0, e = 0x0, overflow = 0}}, vary = 0x0, ban = 0x0, pass = 0, response = 0, cacheable = 0, busy = 0, len = 0, age = 0, entered = 0, ttl = 0, grace = 0, prefetch = 0, last_modified = 0, http = {{magic = 0, ws = 0x0, conds = 0 '\0', logtag = 0, status = 0, protover = 0, hd = {{b = 0x0, e = 0x0} }, hdf = '\0' , nhd = 0}}, list = { vtqe_next = 0x7f42c1617000, vtqe_prev = 0x0}, store = {vtqh_first = 0x0, vtqh_last = 0x0}, esibits = {vtqh_first = 0x0, vtqh_last = 0x0}, last_use = 0, parent = 0x0, child = 0x0, hits = 0} (gdb) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Jan 28 20:38:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 28 Jan 2009 20:38:10 -0000 Subject: [Varnish] #429: Segfault in expire timer thread In-Reply-To: <049.82d6da0e75374723f1d3ca37c4634c37@projects.linpro.no> References: <049.82d6da0e75374723f1d3ca37c4634c37@projects.linpro.no> Message-ID: <058.827ab023d780916548990cec906b5b97@projects.linpro.no> #429: Segfault in expire timer thread --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * version: trunk => 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 29 16:09:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 29 Jan 2009 16:09:44 -0000 Subject: [Varnish] #430: Varnish crashes with Assert error in HSH_Deref Message-ID: <052.240c1acf64980e7d5debe86f76e68fc0@projects.linpro.no> #430: Varnish crashes with Assert error in HSH_Deref ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Running Varnish/trunk 3507 in FreeBSD/amd64 7.0, I got: Child (83954) Panic message: Assert error in HSH_Deref(), cache_hash.c line 424: Condition((oh)->magic == 0x1b96615d) not true. thread = (cache-timeout) Unfortunately, I got no core-dump. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Jan 29 18:04:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 29 Jan 2009 18:04:56 -0000 Subject: [Varnish] #431: Crash in fetch Message-ID: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> #431: Crash in fetch --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ Child (29542) Panic message: Assert error in Tcheck(), cache.h line 674: Condition((t.b) != 0) not true. errno = 104 (Connection reset by peer) thread = (cache-worker)sp = 0x7f1182465008 { fd = 4029, id = 4029, xid = 575153983, client = xxxxxxxxxxx, step = STP_FETCH, handling = FETCH, ws = 0x7f1182465078 { id = "sess", {s,f,r,e} = {0x7f11824657f0,,+2907,(nil),+131072}, }, worker = 0x7f15d77f9c70 { }, vcl = { srcname = { "/etc/varnish/wikia.vcl", "Default", }, }, obj = 0x7f2fffdb0000 { refcnt = 1, xid = 575153983, ws = 0x7f2fffdb0028 { overflow id = "obj", {s,f,r,e} = {0x7f2fffdb0358,,+3240,(nil),+3240}, }, http = { ws = 0x7f2fffdb0028 { overflow id = "obj", {s,f,r,e} = {0x7f2fffdb0358,,+3240,(nil),+3240}, }, hd = { "Server: Apache", "X-Powered-By: PHP/5.2.6", "Content-language: en", "X-CPU-Time: 0.082", "X-Real-Time: 0.152", "X-Served-By-Backend: ap18", "X-User-Id: 0", "X-Article-Id: 0", "X-Namespace-Number: -1", "Vary: Accept-Encoding,Cookie", "X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string- contains=wikicitiesToken;string-contains=wikicitiesLoggedOut;string- contains=wikicities_session", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Cache-Control: private, must-revalidate, max-age=0", "Content-Type: text/html; charset=utf-8", "X-Orighost: ragnarok2.wikia.com", "X-Origurl: /wiki/Special:Ask?title=Special%3AAsk&q=a777%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fhatetos.html+buying%2C+http%3A%2F%2Fkpjhcel.uvoweb.net%2Fxpedly.html+casino%2C+http%3A%2F%2Fvexwszi.wtcsites.com%2Fwers.html+gm%2C+http%3A%2F%2Fshathfb.hostparq.com%2Forrdic.html+hire%2C+http%3A%2F%2Ffuhhubr.blackapplehost.com%2Firu.html+dealers%2C+http%3A%2F%2Fqadmeis.007webs.com%2Fkennw.html+to%2C+http%3A%2F%2Frarruaf.007webs.com%2Furlytlt.html+canada%2C+http%3A%2F%2Fshathfb.hostparq.com%2Factofel.html+sut%2C+http%3A%2F%2Fjubsegn.hostbot.com%2Frleche.html+vegas%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fkha.html+wheels%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fchathacke.html+no%2C+http%3A%2F%2Fogjaakd.angelfire.com%2Fvedis.html+with%2C+http%3A%2F%2Fwissjet.wakeboardreview.com%2Fich.html+hummers%2C+http%3A%2F%2Fjioczae.justfree.com%2Fdsounedi.html+the%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fpetondrate.html+personal%2C+http%3A%2F%2Fwxuvanu.s-enterprize.com%2Fidemnearn.html+suv%2C+http%3A%2F%2Fvexwszi.wtcsites.com%2Fyeaiks.html+life%2C+http%3A%2F%2Fzthrkdo.yourprivatespace.com%2Fenconthans.html+free%2C+http%3A%2F%2Fernnzhm.freehost.net.au%2Fkit.html+air%2C+http%3A%2F%2Fkpjhcel.uvoweb.net%2Ffuriorch.html+vegas%2C+http%3A%2F%2Fowuyeua.5nxs.com%2Fsas.html+texas%2C+http%3A%2F%2Fioiesik.9ix.net%2Fcowhar.html+dealership%2C+&po=a777%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fhatetos.html+buying%2C+http%3A%2F%2Fkpjhcel.uvoweb.net%2Fxpedly.html+casino%2C+http%3A%2F%2Fvexwszi.wtcsites.com%2Fwers.html+gm%2C+http%3A%2F%2Fshathfb.hostparq.com%2Forrdic.html+hire%2C+http%3A%2F%2Ffuhhubr.blackapplehost.com%2Firu.html+dealers%2C+http%3A%2F%2Fqadmeis.007webs.com%2Fkennw.html+to%2C+http%3A%2F%2Frarruaf.007webs.com%2Furlytlt.html+canada%2C+http%3A%2F%2Fshathfb.hostparq.com%2Factofel.html+sut%2C+http%3A%2F%2Fjubsegn.hostbot.com%2Frleche.html+vegas%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fkha.html+wheels%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fchathacke.html+no%2C+http%3A%2F%2Fogjaakd.angelfire.com%2Fvedis.html+with%2C+http%3A%2F%2Fwissjet.wakeboardreview.com%2Fich.html+hummers%2C+http%3A%2F%2Fjioczae.justfree.com%2Fdsounedi.html+the%2C+http%3A%2F%2Fadheppc.fizwig.com%2Fpetondrate.html+personal%2C+http%3A%2F%2Fwxuvanu.s-enterprize.com%2Fidemnearn.html+suv%2C+http%3A%2F%2Fvexwszi.wtcsites.com%2Fyeaiks.html+life%2C+http%3A%2F%2Fzthrkdo.yourprivatespace.com%2Fenconthans.html+free%2C+http%3A%2F%2Fernnzhm.freehost.net.au%2Fkit.html+air%2C+http%3A%2F%2Fkpjhcel.uvoweb.net%2Ffuriorch.html+vegas%2C+http%3A%2F%2Fowuyeua.5nxs.com%2Fsas.html+texas%2C+http%3A%2F%2Fioiesik.9ix.net%2Fcowhar.html+dealership%2C+&sc=0&eq=yes", "X-Cacheable: NO:Not-Cacheable", "Date: Thu, 29 Jan 2009 14:21:05 GMT", "X-Varnish: 1106534922", "", "", "X-Cache: MISS", "", "", }, }, len = 52193, store = { 52193 { 3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 20 50 | Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 30 10:06:01 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 30 Jan 2009 10:06:01 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.c3325a40a91e1c7200a052d29579853f@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: kristian Type: enhancement | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator