From rodrie.violante at gmail.com Mon May 24 17:45:28 2010 From: rodrie.violante at gmail.com (Rodrigo Violante) Date: Mon, 24 May 2010 12:45:28 -0500 Subject: Problem with X_FORWARD_FOR Message-ID: I made a test to check my IP and sometimes it shows it sometimes it doesnt, I already checked if it was cached, but it wasnt, I made a change to the vcl_recv if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; } else { set req.http.X-Forwarded-For = client.ip; } It didnt work so I did this one: > sub vcl_recv { > # Add a unique header containing the client address > remove req.http.X-Forwarded-For; > set req.http.X-Forwarded-For = client.ip; > # [...] > } And still had no luck at all. Its random sometimes it shows the user ip sometimes it doesnt. Any clues? Rodrigo Violante Team Manager Solo Racing rodrigo at soloracing.com http://www.linkedin.com/in/rodrigoviolante http://twitter.com/rodriev Mobile MEX: +52 1(554) 611 35 32 This e-mail message is intended only for the personal use of the recipient(s) named above. This message may be an attorney-client communication and as such privileged and confidential. If you are not an intended recipient,you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. PPlease consider the environment before printing email -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at varnish-software.com Mon May 31 06:02:22 2010 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Mon, 31 May 2010 08:02:22 +0200 Subject: Problem with X_FORWARD_FOR In-Reply-To: (Rodrigo Violante's message of "Mon, 24 May 2010 12:45:28 -0500") References: Message-ID: <87bpbw6235.fsf@qurzaw.linpro.no> ]] Rodrigo Violante | And still had no luck at all. | | Its random sometimes it shows the user ip sometimes it doesnt. Sounds like you're piping requests and not setting connection: close on those requests. -- Tollef Fog Heen Varnish Software t: +47 21 54 41 73 From varnish-bugs at varnish-cache.org Sat May 1 01:44:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 May 2010 01:44:28 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler Message-ID: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- We use an internal crawler to refresh the pages cache. So if we want something refreshed very soon but not deleted, this will do it. This allows us to almost always serve the request from the cache & still have content updated on a regular basis. vcl configuration {{{ if (req.http.user-agent == "our-crawler") { #HACK C{ VRT_l_req_grace(sp, -300); }C } else { # in case "our-crawler" hasn't refresh the data; this will reduce the load on the backend set req.grace = 5m; } }}} patch to cache_hash.c {{{ --- ./bin/varnishd/cache_hash.c 2009-12-16 00:45:49.000000000 -0800 +++ ./bin/varnishd/cache_hash.c 2010-02-22 11:29:06.000000000 -0800 @@ -293,6 +293,15 @@ grace_o = o; } + if (sp->grace < 0) { + sp->grace = -sp->grace; + if (o != NULL) { + o->ttl = sp->t_req-1; + o = NULL; + } + grace_o = NULL; + } + /* * If we have seen a busy object or the backend is unhealthy, and * have an object in grace, use it, if req.grace is also --- ./bin/varnishd/cache_vrt.c 2009-10-23 01:00:09.000000000 -0700 +++ ./bin/varnishd/cache_vrt.c 2010-02-22 11:29:35.000000000 -0800 @@ -534,8 +534,6 @@ { CHECK_OBJ_NOTNULL(sp, SESS_MAGIC); - if (a < 0) - a = 0; sp->grace = a; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat May 1 13:18:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 May 2010 13:18:16 -0000 Subject: [Varnish] #691: Varnish Cache misses Message-ID: <042.2ed887d140555df0536b2bbf25d94131@varnish-cache.org> #691: Varnish Cache misses -------------------+-------------------------------------------------------- Reporter: S2eve | Type: defect Status: new | Priority: highest Milestone: | Component: website Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- How to make varnish cache? my cache misses much bigger that cache hits... 264851 15.00 29.01 Client connections accepted 650455 55.00 71.24 Client requests received 1542 0.00 0.17 Cache hits 39 0.00 0.00 Cache hits for pass 7091 0.00 0.78 Cache misses -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat May 1 20:24:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 May 2010 20:24:57 -0000 Subject: [Varnish] #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 Message-ID: <040.e45238aad298b4337bf972c8d3ed33f0@varnish-cache.org> #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 -------------------------------+-------------------------------------------- Reporter: Kwi | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Keywords: v00017.vtc x86_64 | -------------------------------+-------------------------------------------- Test case v00017.vtc fails (seemingly just ''after'', and thus unrelated, to the problematic test of bug #356) with the following output: {{{ #### v1 CLI TX| vcl.inline vcl6 "\n\tbackend b { .host = \"127.0.0.1\"; }\n\tacl a { \"10.1.2.\"; }\n\tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n" ### v1 CLI RX 200 #### v1 CLI RX| VCL compiled. ---- v1 VCL compilation got 200 expected 106 }}} I'm unfortunately not quite sure what this test does. :-) Environment: * Operating system: Ubuntu Server 10.04 LTS (amd64) * Kernel: Linux 2.6.32-21-server * RAM: 512 MB * Network: Host address 10.1.5.3, subnet 10.1.0.0/16 * Varnish versions: both 2.1.1 and r4752 Commands to reproduce: {{{ sudo apt-get install wget pkg-config groff-base libpcre3-dev autotools-dev automake gcc libtool libncurses5-dev make wget 'http://downloads.sourceforge.net/project/varnish/varnish/2.1.1/varnish-2.1.1.tar.gz?use_mirror=switch' tar xf varnish-2.1.1.tar.gz cd varnish-2.1.1 ./autogen.sh ./configure --enable-stack-protector make make check }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 3 08:13:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 May 2010 08:13:04 -0000 Subject: [Varnish] #693: Assert error in WS_Release(), cache_ws.c line 175 Message-ID: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> #693: Assert error in WS_Release(), cache_ws.c line 175 -------------------+-------------------------------------------------------- Reporter: tore | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- The following errors appeared in the logs yesterday: May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv-guide/css/favstar.png", "HTTP/1.1", "Accept: */*", "Referer: http://w May 2 17:43:15 joanie varnishd[27393]: child (32486) Started May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 4 5 9 10 12 13 May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts And on another machine: May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv- guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", "Referer: ht May 2 20:50:18 dexter varnishd[23728]: child (1153) Started May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 5 9 10 12 13 May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts I don't think it led to any serious consequences though. Tore -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 3 08:17:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 May 2010 08:17:30 -0000 Subject: [Varnish] #693: Assert error in WS_Release(), cache_ws.c line 175 In-Reply-To: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> References: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> Message-ID: <050.bb79c707045890bd2c78dce4854f0c14@varnish-cache.org> #693: Assert error in WS_Release(), cache_ws.c line 175 -------------------+-------------------------------------------------------- Reporter: tore | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by tore): It seems Trac hates newlines. I'll try again: {{{ May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv-guide/css/favstar.png", "HTTP/1.1", "Accept: */*", "Referer: http://w May 2 17:43:15 joanie varnishd[27393]: child (32486) Started May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 4 5 9 10 12 13 May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts }}} {{{ May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv- guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", "Referer: ht May 2 20:50:18 dexter varnishd[23728]: child (1153) Started May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 5 9 10 12 13 May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 4 08:33:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 May 2010 08:33:00 -0000 Subject: [Varnish] #694: Calls from silverlight fails on 2.1.1 Message-ID: <039.8c84989dd66811372bc99657b6742cac@varnish-cache.org> #694: Calls from silverlight fails on 2.1.1 ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: normal | Keywords: silverlight ----------------------+----------------------------------------------------- When upgrading to 2.1.1 silverlight stopped working. The plugin does not manage to load it's initial content (in our case, the videoplayer itself) http://pastebin.com/UAcLwnNp This is a failed request and the following failed hit. The silverlight plugin says it manages to download about 45% of the file then fails. Downloading the same file with wget works fine and has the same md5sum as a file downloaded from 2.1.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 4 13:58:37 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 May 2010 13:58:37 -0000 Subject: [Varnish] #695: Varnish trunk 4516 segmentation fault in FreeBSD Message-ID: <043.0c8af4e7ee3cb80191b04279eace67a7@varnish-cache.org> #695: Varnish trunk 4516 segmentation fault in FreeBSD ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am running Varnish trunk/4516 in FreeBSD/amd64 7.2-RELEASE with these parameters: varnishd_flags="-p sess_workspace=16384 -p obj_workspace=0 -p lru_interval=3600 -h critbit -p ping_interval=0 -p cli_timeout=30 -p auto_restart=on -p thread_pools=10 -p thread_pool_min=70 -p thread_pool_max=4000 -p session_linger=40 -p listen_depth=4096 -p default_ttl=604800 -T localhost:8080 -f /usr/local/etc/varnish.vcl -s malloc,60G -P /var/run/varnishd.pid" After running for 20 days I got a sig11 crash from the child process: May 4 14:43:01 cache12 kernel: pid 871 (varnishd), uid 65534: exited on signal 11 (core dumped) Backtrace shows: {{{ (gdb) bt full #0 0x00000008009d235f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 No locals. #1 0x00000008009d2394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 i = 2 #2 0x0000000000422538 in pan_backtrace () at cache_panic.c:273 array = {0x0, 0x5, 0x0, 0x115ea1, 0x1, 0x10000, 0x0, 0xffff, 0x0, 0x801108040} size = Variable "size" is not available. (gdb) frame 1 #1 0x00000008009d2394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 70 for (i = 1; getframeaddr(i + 1) != NULL && i != size + 1; i++) { (gdb) print panicstr $2 = "Assert error in cnt_lookup(), cache_center.c line 792:\n Condition((sp->wrk) == 0) not true.\nthread = (cache-worker)\nident = FreeBSD,7.2-RELEASE-p3,amd64,-smalloc,-hcritbit,kqueue\n", '\0' (gdb) print *sp No symbol "sp" in current context. (gdb) frame 2 #2 0x0000000000422538 in pan_backtrace () at cache_panic.c:273 273 size = backtrace (array, 10); (gdb) print *sp No symbol "sp" in current context. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 4 14:19:11 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 May 2010 14:19:11 -0000 Subject: [Varnish] #694: Calls from silverlight fails on 2.1.1 In-Reply-To: <039.8c84989dd66811372bc99657b6742cac@varnish-cache.org> References: <039.8c84989dd66811372bc99657b6742cac@varnish-cache.org> Message-ID: <048.4a32e47f09917a750e10781f9d1e6285@varnish-cache.org> #694: Calls from silverlight fails on 2.1.1 -------------------------+-------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: normal | Resolution: fixed Keywords: silverlight | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4758]) Fix one of those "nothing can possibly go wrong" bugs that are so typical of "lets just try to get this into the release" features. The resent addition of experimental Range: header support, broke a cornercase in normal content delivery. If an object was delivered from the backend using chunked encoding, and was larger than the storage segment size (default: 128k) this bug may bite. The effect of the bug is that up to storage segment worth of junk may be appended to the transmitted object. This is mostly harmless, because the Content-Length header will make the browser do the right thing, but certain load-balancers will go cross-eyed and act really weird at the TCP level, spewing interesting RST packets to the client. This bug is only in 2.1.1, not in 2.1.0. Fixes: #694 Isolated by: ay Fool who did this: phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 07:48:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 07:48:26 -0000 Subject: [Varnish] #694: Calls from silverlight fails on 2.1.1 In-Reply-To: <039.8c84989dd66811372bc99657b6742cac@varnish-cache.org> References: <039.8c84989dd66811372bc99657b6742cac@varnish-cache.org> Message-ID: <048.2d186a96056a676f1aa9a4b4f28cb7dc@varnish-cache.org> #694: Calls from silverlight fails on 2.1.1 -------------------------+-------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.1.1 Severity: normal | Resolution: fixed Keywords: silverlight | -------------------------+-------------------------------------------------- Comment(by tfheen): (In [4763]) Merge r4758: Fix trailing garbage for large objects Fix one of those "nothing can possibly go wrong" bugs that are so typical of "lets just try to get this into the release" features. The resent addition of experimental Range: header support, broke a cornercase in normal content delivery. If an object was delivered from the backend using chunked encoding, and was larger than the storage segment size (default: 128k) this bug may bite. The effect of the bug is that up to storage segment worth of junk may be appended to the transmitted object. This is mostly harmless, because the Content-Length header will make the browser do the right thing, but certain load-balancers will go cross-eyed and act really weird at the TCP level, spewing interesting RST packets to the client. This bug is only in 2.1.1, not in 2.1.0. Fixes: #694 Isolated by: ay Fool who did this: phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 08:37:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 08:37:06 -0000 Subject: [Varnish] #693: Assert error in WS_Release(), cache_ws.c line 175 In-Reply-To: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> References: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> Message-ID: <050.bcfb4e87a1c14d7c8ade9955c5c8281e@varnish-cache.org> #693: Assert error in WS_Release(), cache_ws.c line 175 -------------------+-------------------------------------------------------- Reporter: tore | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Description changed by phk: Old description: > The following errors appeared in the logs yesterday: > > May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 > May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: > Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= > ws->e - ws->f) not true. thread = (cache-worker) ident = > Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: > 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: > vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: > _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: > cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: > wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { > fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, > step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = > "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, > http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv- > guide/css/favstar.png", "HTTP/1.1", "Accept: */*", > "Referer: http://w > May 2 17:43:15 joanie varnishd[27393]: child (32486) Started > May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 > 4 5 9 10 12 13 > May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts > > And on another machine: > > May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 > May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: > Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= > ws->e - ws->f) not true. thread = (cache-worker) ident = > Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: > 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: > vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: > _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: > cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: > wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { > fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, > step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = > "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, > http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv- > guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", > "Referer: ht > May 2 20:50:18 dexter varnishd[23728]: child (1153) Started > May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 > 5 9 10 12 13 > May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts > > I don't think it led to any serious consequences though. > > Tore New description: The following errors appeared in the logs yesterday: {{{ May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv-guide/css/favstar.png", "HTTP/1.1", "Accept: */*", "Referer: http://w May 2 17:43:15 joanie varnishd[27393]: child (32486) Started May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 4 5 9 10 12 13 May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts }}} And on another machine: {{{ May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv- guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", "Referer: ht May 2 20:50:18 dexter varnishd[23728]: child (1153) Started May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 5 9 10 12 13 May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts }}} I don't think it led to any serious consequences though. Tore -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 08:38:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 08:38:46 -0000 Subject: [Varnish] #691: Varnish Cache misses In-Reply-To: <042.2ed887d140555df0536b2bbf25d94131@varnish-cache.org> References: <042.2ed887d140555df0536b2bbf25d94131@varnish-cache.org> Message-ID: <051.db6deaa85019588056cefdee9aaf13cf@varnish-cache.org> #691: Varnish Cache misses ----------------------+----------------------------------------------------- Reporter: S2eve | Type: defect Status: closed | Priority: highest Milestone: | Component: website Version: trunk | Severity: normal Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: The most likely cause is Cookies. By default varnish does not cache if there are Cookie or Set-Cookie headers involved. Please see the the default vcl code and the examples on the wiki for more information. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 08:39:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 08:39:31 -0000 Subject: [Varnish] #687: Varnish, squid and apc In-Reply-To: <042.61148997d1c00f9569c2424784b2d1ae@varnish-cache.org> References: <042.61148997d1c00f9569c2424784b2d1ae@varnish-cache.org> Message-ID: <051.1eeaa1b2d447f2153c939f7be83534ec@varnish-cache.org> #687: Varnish, squid and apc ----------------------+----------------------------------------------------- Reporter: S2eve | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: can't see why not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 08:41:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 08:41:19 -0000 Subject: [Varnish] #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 In-Reply-To: <040.e45238aad298b4337bf972c8d3ed33f0@varnish-cache.org> References: <040.e45238aad298b4337bf972c8d3ed33f0@varnish-cache.org> Message-ID: <049.149cde787f059e46debd3b0a1cd774ee@varnish-cache.org> #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 -------------------------+-------------------------------------------------- Reporter: Kwi | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Resolution: worksforme | Keywords: v00017.vtc x86_64 -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: It seems to be because your operating system thinks it can resolve the address "10.1.2." to an IP number. That is a bug in your OS. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 08:42:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 08:42:10 -0000 Subject: [Varnish] #688: varnish doesn't work In-Reply-To: <042.8f30762555411d7407ced6b52b8ae242@varnish-cache.org> References: <042.8f30762555411d7407ced6b52b8ae242@varnish-cache.org> Message-ID: <051.2d6466205092a4cd329517f11973f2bd@varnish-cache.org> #688: varnish doesn't work ----------------------+----------------------------------------------------- Reporter: S2eve | Type: defect Status: closed | Priority: highest Milestone: | Component: build Version: trunk | Severity: normal Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: I have no idea. Please don't use our ticket system for user-help requests, we only use it to track actual bugs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 12:35:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 12:35:56 -0000 Subject: [Varnish] #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 In-Reply-To: <040.e45238aad298b4337bf972c8d3ed33f0@varnish-cache.org> References: <040.e45238aad298b4337bf972c8d3ed33f0@varnish-cache.org> Message-ID: <049.814ae254b912b3853cf2efbc86dad30d@varnish-cache.org> #692: Test case v00017.vtc fails: VCL compilation got 200 expected 106 -------------------------+-------------------------------------------------- Reporter: Kwi | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Resolution: worksforme | Keywords: v00017.vtc x86_64 -------------------------+-------------------------------------------------- Comment(by Kwi): Ah, so that's why. (In Ubuntu's defense, it's in fact my upstream DNS server that claim that the domain "10.1.2." resolves to 10.1.0.2. Silly thing.) Thanks for the quick response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 13:59:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 13:59:47 -0000 Subject: [Varnish] #696: Varnish returning on a 503 while backend is returning a 302 Message-ID: <047.a804c7190a56abcf85f208a1735f98a3@varnish-cache.org> #696: Varnish returning on a 503 while backend is returning a 302 ------------------------+--------------------------------------------------- Reporter: jayjanssen | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ------------------------+--------------------------------------------------- This seems to happen only on my wordpress installations behind varnish when I logout from my session. I replaced my config with the default.vcl and got the same result. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 5 14:03:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 May 2010 14:03:41 -0000 Subject: [Varnish] #696: Varnish returning on a 503 while backend is returning a 302 In-Reply-To: <047.a804c7190a56abcf85f208a1735f98a3@varnish-cache.org> References: <047.a804c7190a56abcf85f208a1735f98a3@varnish-cache.org> Message-ID: <056.cdc603cb43ee0f2962829a8eb1d0bc8b@varnish-cache.org> #696: Varnish returning on a 503 while backend is returning a 302 ------------------------+--------------------------------------------------- Reporter: jayjanssen | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ------------------------+--------------------------------------------------- Comment(by jayjanssen): I forgot to add, I'm running varnish-2.0.4 on Debian Lenny $ dpkg -l varnish Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii varnish 2.0.4-5~bpo50+ a state-of-the-art, high-performance HTTP ac $ varnishd -V varnishd (varnish-2.0.4) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 6 03:18:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 May 2010 03:18:02 -0000 Subject: [Varnish] #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! Message-ID: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- I just updated and I cant get anything working, first I get compile errors at vcl_fetch which I had to comment everything, once that was comment it start working but the COOKIE rules for the pass didnt work. Here is a sample of my config I got no clue at all. {{{ backend default { .host = "192.168.11.30"; .port = "80"; /*.first_byte_timeout = 3000s;*/ } acl purge { "localhost"; "192.168.11.0"/24; } sub vcl_recv { if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ # POST - Logins and Edits if (req.request == "POST") { return (pass); } # PURGE if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } return (lookup); } } if(req.request == "GET" && req.url ~ "^/admin/") { /* Do not cache admin pages */ return (pass); } if(req.request == "GET" && req.url ~ "^/no-cache/") { /* Do not cache admin pages */ return (pass); } /* Cache image files */ if (req.url ~ "\.(jpg|jpeg|gif|png|tiff|tif|svg)$") { return (lookup); } /* Cache audio and video files */ if (req.url ~ "\.(swf|mp3|mp4|m4a|ogg|mov|avi|wmv)$") { return (lookup); } /* Cache ico, css and java script */ if (req.url ~ "\.(ico|css|js)$") { return (lookup); } /* Miscellaneous files to cache */ if (req.url ~ "\.(vsd|doc|ppt|pps|xls|pdf|sxw|zip|gz|bz2|tgz|tar|rar|odc|odb|odf|odg|odi|odp|ods|odt|sxc|sxd|sxi|sxw|dmg|torrent|deb|msi|iso|rpm)$") { return (lookup); } /* tarreoipb_stronghold|tarreocoppa|tarreomember_id|tarreopass_hash|tarreosession_id| */ if (req.http.Cookie ~ "(tarreoipb_stronghold|tarreocoppa|tarreomember_id|tarreopass_hash|tarreosession_id|loginLUP[email]|loginLUP[password]|login[email]|login[password])") { /* dont do anything, the user is logged in */ return (pipe); } else { /* Remove any other cookies */ remove req.http.Cookie; } if (req.http.Authorization || req.http.Cookie) { /* Not cacheable by default */ return (pass); } return (lookup); } # Do the PURGE thing sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged"; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache"; } } # Enforce a minimum TTL, since we can PURGE changed objects actively sub vcl_fetch { set obj.grace = 60s; if (req.url ~ "\.(jpg|jpeg|gif|png|tiff|tif|svg|ico)$") { unset obj.http.expires; set obj.ttl = 14400s; } if (obj.ttl < 3600s) { set obj.ttl = 3600s; } } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } return (deliver); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 6 03:18:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 May 2010 03:18:25 -0000 Subject: [Varnish] #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! In-Reply-To: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> References: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> Message-ID: <053.089f29ec6622bfc0eb64cd2ff224aa93@varnish-cache.org> #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Comment(by Rodrigo): Also to mention, this config was working just fine before the upgrade. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 6 03:57:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 May 2010 03:57:25 -0000 Subject: [Varnish] #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! In-Reply-To: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> References: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> Message-ID: <053.a80b96f3376aa58fe1e0370a33222dc0@varnish-cache.org> #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Comment(by Rodrigo): I changed in vcl_fetch the *.obj to *.beresp and now it runs, but the cookie section is not working yet. Any clues? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 10 13:21:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 May 2010 13:21:53 -0000 Subject: [Varnish] #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! In-Reply-To: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> References: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> Message-ID: <053.bc6c2966303bb1f0f512b0a74eab017b@varnish-cache.org> #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Comment(by tfheen): Can you please provide a varnishlog transaction where it does not do as you want it to? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 10 13:25:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 May 2010 13:25:23 -0000 Subject: [Varnish] #696: Varnish returning on a 503 while backend is returning a 302 In-Reply-To: <047.a804c7190a56abcf85f208a1735f98a3@varnish-cache.org> References: <047.a804c7190a56abcf85f208a1735f98a3@varnish-cache.org> Message-ID: <056.c19eb720517503dc3d815871a651fce9@varnish-cache.org> #696: Varnish returning on a 503 while backend is returning a 302 -------------------------+-------------------------------------------------- Reporter: jayjanssen | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: invalid | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: Your backend is sending too many headers compared to the built-in in your version. Either recompile and increase the number then, upgrade to 2.1 where it is a parameter you can increase or fix the backend to send fewer headers. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 10 13:28:03 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 May 2010 13:28:03 -0000 Subject: [Varnish] #693: Assert error in WS_Release(), cache_ws.c line 175 In-Reply-To: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> References: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> Message-ID: <050.a4c49bfcef7aaeab40d288a95940f4b4@varnish-cache.org> #693: Assert error in WS_Release(), cache_ws.c line 175 -------------------+-------------------------------------------------------- Reporter: tore | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Description changed by phk: Old description: > The following errors appeared in the logs yesterday: > {{{ > May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 > May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: > Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= > ws->e - ws->f) not true. thread = (cache-worker) ident = > Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: > 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: > vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: > _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: > cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: > wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { > fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, > step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = > "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, > http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv- > guide/css/favstar.png", "HTTP/1.1", "Accept: */*", > "Referer: http://w > May 2 17:43:15 joanie varnishd[27393]: child (32486) Started > May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 > 4 5 9 10 12 13 > May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts > }}} > And on another machine: > {{{ > May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 > May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: > Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= > ws->e - ws->f) not true. thread = (cache-worker) ident = > Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: > 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: > vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: > _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: > cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: > wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { > fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, > step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = > "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, > http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv- > guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", > "Referer: ht > May 2 20:50:18 dexter varnishd[23728]: child (1153) Started > May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 > 5 9 10 12 13 > May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts > }}} > I don't think it led to any serious consequences though. > > Tore New description: The following errors appeared in the logs yesterday: {{{ May 2 17:43:15 joanie varnishd[27393]: Child (27398) died signal=6 May 2 17:43:15 joanie varnishd[27393]: Child (27398) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-53.1.21.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aae5b406ddd: _end+2aae5ad96ed5 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aacace35008 { fd = 2210, id = 2210, xid = 673071254, client = 85.165.170.142:54967, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aacace35078 { id = "sess", {s,f,r,e} = {0x2aacace35c90,+495,(nil),+65536}, }, http[req] = { ws = 0x2aacace35078[sess] "GET", "/tv-guide/css/favstar.png", "HTTP/1.1", "Accept: */*", "Referer: http://w May 2 17:43:15 joanie varnishd[27393]: child (32486) Started May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Closed fds: 3 4 5 9 10 12 13 May 2 17:43:15 joanie varnishd[27393]: Child (32486) said Child starts }}} And on another machine: {{{ May 2 20:50:18 dexter varnishd[23728]: Child (22882) died signal=6 May 2 20:50:18 dexter varnishd[23728]: Child (22882) Panic message: Assert error in WS_Release(), cache_ws.c line 175: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x421e36: pan_ic+b6 0x42c5c5: WS_Release+e5 0x426eda: vrt_assemble_string+aa 0x42aeb5: VRT_SetHdr+f5 0x2aadb8c06d9f: _end+2aadb8596e97 0x426416: VCL_deliver_method+46 0x412e0f: cnt_deliver+13f 0x413b59: CNT_Session+369 0x424228: wrk_do_cnt_sess+b8 0x42352e: wrk_thread_real+32e sp = 0x2aad132cc008 { fd = 3485, id = 3485, xid = 2325556459, client = 171.23.129.9:23438, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aad132cc078 { id = "sess", {s,f,r,e} = {0x2aad132ccc90,+516,(nil),+65536}, }, http[req] = { ws = 0x2aad132cc078[sess] "GET", "/tv-guide/css/icon_calendar.png", "HTTP/1.1", "Accept: */*", "Referer: ht May 2 20:50:18 dexter varnishd[23728]: child (1153) Started May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Closed fds: 3 4 5 9 10 12 13 May 2 20:50:18 dexter varnishd[23728]: Child (1153) said Child starts }}} I don't think it led to any serious consequences though. Tore -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 10 13:34:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 May 2010 13:34:30 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.c3b6f04bca2cb237afd1fd745c9753ab@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- Comment(by tfheen): Is there a particular reason why you can't just do something like: sub vcl_recv { set req.grace = 5m; if (req.http.user-agent == "crawler") { set req.grace = 0s; } } sub vcl_hit { if (req.http.user-agent == "crawler" && req.restarts == 0) { set obj.ttl = 0s; restart; } } In this case you can have real clients which end up fetching the object, I'm assuming that's not a problem, and if it is, that's fixable too. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 10 14:27:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 May 2010 14:27:25 -0000 Subject: [Varnish] #698: High load after upgrade from 2.1.0 to 2.1.2 Message-ID: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org> #698: High load after upgrade from 2.1.0 to 2.1.2 -----------------------------+---------------------------------------------- Reporter: lukasz.jagiello | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- After upgrade varnish from 2.1.0 to 2.1.2 get really big load: [[Image(http://dl.dropbox.com/u/133846/graph_image.png)]] It's i686 system with kernel 2.6.18-164.2.1.el5.plusPAE. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 11 01:10:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 May 2010 01:10:33 -0000 Subject: [Varnish] #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) Message-ID: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) ----------------------+----------------------------------------------------- Reporter: osterman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Keywords: | ----------------------+----------------------------------------------------- Varnishncsa assumes that a ReqEnd will always happen before a SessionClose. Very frequently, a SessionClose happens after a ReqEnd, which casues lp->bogus to be set and the log event dropped. This has been a problem for us sometime. The fix we have implemented is to not rely on the ordering of ReqEnd/SessionClose, but instead rely on SessionOpen. When we get a SessionOpen, we initialize the *lp pointer, thereby resetting everything. Since I'm not that familiar with the varnish source code, I'm not submitting a patch as our solution might not be the best. Below, you will see ReqEnd before SessionClose. The output was generated using varnishlog. 16 TxProtocol c HTTP/1.1 16 TxStatus c 200 16 TxResponse c OK 16 TxHeader c Server: Varnish 16 TxHeader c Retry-After: 0 16 TxHeader c X-Cacheable-URL: /health_check.html 16 TxHeader c Content-Type: text/plain; charset=utf-8 16 TxHeader c Cache-Control: no-cache, must-revalidate 16 TxHeader c Expires: Mon, 26 Jul 1997 05:00:00 GMT 16 TxHeader c Content-Length: 2 16 TxHeader c Date: Tue, 11 May 2010 00:12:33 GMT 16 TxHeader c X-Varnish: 176572510 16 TxHeader c Age: 0 16 TxHeader c Via: 1.1 varnish 16 TxHeader c Connection: close 16 TxHeader c X-Served-By: domU-12-31-39-0E-41-C2 16 TxHeader c X-Cache: MISS 16 ReqEnd c 176572510 1273536753.646451950 1273536753.646547079 0.000028849 0.000061035 0.000034094 16 SessionClose c error 16 StatSess c 10.240.61.192 35698 0 1 1 0 0 0 387 2 0 Backend_health - s3_varnish_prod Still healthy 4--X-RH 5 3 5 0.008935 0.011059 HTTP/1.1 200 OK 16 SessionOpen c 127.0.0.1 33707 :80 16 ReqStart c 127.0.0.1 33707 176572511 16 RxRequest c GET 16 RxURL c /s2?q=test 16 RxProtocol c HTTP/1.1 16 RxHeader c Host: www-qa.host.com 16 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 16 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 16 RxHeader c Accept-Language: en-us,en;q=0.5 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: 115 16 RxHeader c Connection: keep-alive -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 11 01:11:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 May 2010 01:11:24 -0000 Subject: [Varnish] #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) In-Reply-To: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> References: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> Message-ID: <054.7fb73fb09e944da29f9351804cb6e88d@varnish-cache.org> #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) ----------------------+----------------------------------------------------- Reporter: osterman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by osterman): Sorry, I didn't use the Wiki formatting! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 11 01:11:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 May 2010 01:11:55 -0000 Subject: [Varnish] #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) In-Reply-To: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> References: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> Message-ID: <054.4561f45fd42edf3ccda013e7de63716b@varnish-cache.org> #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) ----------------------+----------------------------------------------------- Reporter: osterman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by osterman): {{{ 16 TxProtocol c HTTP/1.1 16 TxStatus c 200 16 TxResponse c OK 16 TxHeader c Server: Varnish 16 TxHeader c Retry-After: 0 16 TxHeader c X-Cacheable-URL: /health_check.html 16 TxHeader c Content-Type: text/plain; charset=utf-8 16 TxHeader c Cache-Control: no-cache, must-revalidate 16 TxHeader c Expires: Mon, 26 Jul 1997 05:00:00 GMT 16 TxHeader c Content-Length: 2 16 TxHeader c Date: Tue, 11 May 2010 00:12:33 GMT 16 TxHeader c X-Varnish: 176572510 16 TxHeader c Age: 0 16 TxHeader c Via: 1.1 varnish 16 TxHeader c Connection: close 16 TxHeader c X-Served-By: domU-12-31-39-0E-41-C2 16 TxHeader c X-Cache: MISS 16 ReqEnd c 176572510 1273536753.646451950 1273536753.646547079 0.000028849 0.000061035 0.000034094 16 SessionClose c error 16 StatSess c 10.240.61.192 35698 0 1 1 0 0 0 387 2 0 Backend_health - s3_varnish_prod Still healthy 4--X-RH 5 3 5 0.008935 0.011059 HTTP/1.1 200 OK 16 SessionOpen c 127.0.0.1 33707 :80 16 ReqStart c 127.0.0.1 33707 176572511 16 RxRequest c GET 16 RxURL c /s2?fmt=0&user=evildoc- test9-2486-2010:0510T:17:12:35&c_clicker=C446964A- AF50-0001-A9F3-C3001165E750&key=694abbea-87eb-4195-a48d- ad00a0a1048c&show_tids=tv:nova&available=true&sort=air_date&num_eps_res=10&group=show|video 16 RxProtocol c HTTP/1.1 16 RxHeader c Host: www-qa.clicker.com 16 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 16 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 16 RxHeader c Accept-Language: en-us,en;q=0.5 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: 115 16 RxHeader c Connection: keep-alive }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 11 13:57:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 May 2010 13:57:00 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.7cc7869f41786c2967d33b1292bd2893@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by whocares): The fix outlined above fixed my issue where varnishncsa (2.1.0/2.1.2) would segfault on Solaris 10 e very couple of seconds. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 12 00:15:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 May 2010 00:15:39 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.25966e85954663886bea2b5dbd331f85@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- Comment(by LaurentChavet): Let me explain what the idea is here as I wrote the code. We want our users to always get cache hit; to do that we can cache pages for a very long time (could be forever if we have enough memory). That works fine until pages are changed (we know it at the backend level); at that point we want to put a new version of the page in the cache without impacting our users (they should still get their pages from the cache). With the changes above, here is what happens: Page FOO is cached with a large TTL (say 1 week); that part can be triggered by an internal crawler. It is served from cache to our users. 1 hour later a change needs to be pushed to that page: the crawler visit the page with user-agent="crawler" which (through the code change) sets the current cached page to expired with a grace period so it is still served. When the crawler request completes it is added to the cache and any future requests from our users get the new page without anyone (except for the crawler) getting a cache miss. I couldn't find any way to implement this feature without the code above. Let me know if there is a different solution. Laurent Chavet -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 12 08:30:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 May 2010 08:30:56 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.1704298e09a2ef6e1cf5516adaba47af@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- Comment(by tfheen): You don't need to set a negative grace period for that to happen, you can just expire the object by setting the TTL to zero and setting req.grace to 0 for the crawler. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 12 10:21:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 May 2010 10:21:06 -0000 Subject: [Varnish] #700: Response Reason-Phrase can contain SP Message-ID: <042.348b46dfda00d59b349769e65b19cd10@varnish-cache.org> #700: Response Reason-Phrase can contain SP -------------------+-------------------------------------------------------- Reporter: slink | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Currently, Varnish refuses a TAB in the reason phrase in a response status line. My understanding of the rfc is that it should accept a tab. I'll send a patch http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 : 6.1 Status-Line The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF further down: Reason-Phrase = * http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 : TEXT = LWS = [CRLF] 1*( SP | HT ) SP = HT = -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 12 16:47:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 May 2010 16:47:57 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.52e0c47c1abf309286ff79e2d5123532@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- Comment(by LaurentChavet): The negative grace is not really "negative grace"; it's just a way to do what you explained. Now I see that the VCL you posted will do pretty much the same thing; so I guess this code change is not needed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 13 07:51:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 May 2010 07:51:06 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.1949b7815543b70e26027d3baccbde12@varnish-cache.org> #690: Allow for a negative grace period for internal crawler ------------------------+--------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: grace | ------------------------+--------------------------------------------------- Comment(by tfheen): Ok, closing this ticket then. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 13 14:01:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 May 2010 14:01:33 -0000 Subject: [Varnish] #701: Parameters to limit URI / header sizes Message-ID: <042.493cf661d63924842b246786a8245a7c@varnish-cache.org> #701: Parameters to limit URI / header sizes -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: max_hdr_len max_uri_len limit size -------------------------+-------------------------------------------------- There still exist various scenarios where varnish may panic on failed assertions when the session workspace gets overflowed. A prominent case is extensive header/URI processing involving creation of (multiple) copies on the workspace. To ensure stable operation, the workspace needs to be sized based on maximum values for URI / header sizes. Thus, I am proposing to add respective limits. The attached patch will add two parameters: * max_hdr_len to limit the total size for request and response headers (as received from backends), excluding the request/status line, but including the terminal CRLF * max_uri_len to limit the total size of the request URI as received from clients The latter limit is probably already implied for most installations by backend servers' limits, so it seems sensible to make the respective check early in the processing chain. Thanks, Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 14 09:50:54 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 May 2010 09:50:54 -0000 Subject: [Varnish] #565: "git: command not found" messages during build w/o git In-Reply-To: <045.a29fbd2129821e15a57bbf8e2cf2da04@varnish-cache.org> References: <045.a29fbd2129821e15a57bbf8e2cf2da04@varnish-cache.org> Message-ID: <054.f520d4a24195c0d838e930cf76ad3c76@varnish-cache.org> #565: "git: command not found" messages during build w/o git ----------------------+----------------------------------------------------- Reporter: kristian | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: minor | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): It's harmless, but I've fixed it in r4791. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 17 22:57:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 May 2010 22:57:21 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris In-Reply-To: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> References: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> Message-ID: <053.102c446f6a1a977edd2653512530465d@varnish-cache.org> #649: Varnish LINGER crash on Solaris ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Comment(by jdzst): Hello, I am testing Varnish (r4576) in Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000. [[BR]] We are planning to use a cache like Varnish or Squid and I have followed the instructions in http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ I have the same LINGER crash like in #660 that has the same root cause in #649 : {{{ child (4033) Started Child (4033) said Closed fds: 3 5 6 7 13 14 16 17 Child (4033) said Child starts Child (4033) said managed to mmap 4583923712 bytes of 4583923712 Child (4033) died signal=6 Child (4033) Panic message: Assert error in TCP_linger(), tcp.c line 271: Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument) ident = -sfile,-hcritbit,ports Child cleanup complete child (12179) Started Child (12179) said Closed fds: 3 5 6 7 13 14 16 17 Child (12179) said Child starts Child (12179) said managed to mmap 4583923712 bytes of 4583923712 Child (12179) died signal=6 Child (12179) Panic message: Assert error in TCP_linger(), tcp.c line 271: Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument) ident = -sfile,-hcritbit,ports Child cleanup complete }}} I have trying to fix the bug and I have found '''the problem is that solaris setsockopt returns sometimes EINVAL''' when it is no invalid parameters, problem found in Java JVM in Solaris:[[BR]] * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870 [[BR]] * http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464 [[BR]] {{{ 2. The Sockets API in Java is not truly portable because it still closely mirro rs the behavior of the OS's internal socket implementation. The root of the prob lem is that Solaris is unique in that calls to setsockopt can result in an EINVA L if the underlying connection has closed. This behavior was actually not docume nted on Solaris 8, they did finally document it in Solaris 9. [...] 1. Most platforms do not return an error on calls to setsockopt 2. Solaris does do this, but it was not documented at the time the JVM and tomca t were developed. 3. The tomcat error was difficult to reproduce, because it only occurs when a cl ient quickly closes its connection between the initial call to accept() and the first call to setsockopt(). (This information was of course not known when the p roblem was reported in the past, because no one has been able to gather the data that shows how it occurs until now) 4. EINVAL is usually used to indicate a bad argument was passed to the call (in fact this is what the Solaris 8 documentation says). This gives one the impressi on of something wrong in the JVM, because it is the JVM's responsibility to pass correct data structures to OS system calls. }}} After reading all this information, I changed the definition of "TCP_Check" in '''libvarnish.h''' {{{ #define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN || errno == EINVAL) //OLD: #define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN) }}} I have tested the change (in a test enviroment, not production), and it seems works right. Some possibility is to change the definition only for Solaris with some #ifdef, I am new in Varnish, ?what is de better solution to make the modification in trunk code? Thank you -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 17 23:22:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 May 2010 23:22:00 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.7c197903e58f64c7da5dec09fb045ea4@varnish-cache.org> #633: varnishncsa segfaults ---------------------+------------------------------------------------------ Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------+------------------------------------------------------ Comment(by jdzst): I think I have the same problem with varnishncsa, I run it with "rotatelogs" and after a while it dumps a "Segmentation Fault". I have inspected the core with GDB and the stacktrace is: {{{ Core was generated by `/export/home/web1/varnish/bin/varnishncsa'. Program terminated with signal 11, Segmentation fault. [New process 87281 ] #0 0xfefb1d70 in strlen () from /lib/libc.so.1 (gdb) bt #0 0xfefb1d70 in strlen () from /lib/libc.so.1 #1 0xff01b038 in _ndoprnt () from /lib/libc.so.1 #2 0xff01d048 in fprintf () from /lib/libc.so.1 #3 0x000123e0 in h_ncsa (priv=0x23660, tag=SLT_ReqEnd, fd=5, len=79, spec=1, ptr=0xfa15b35b
) at varnishncsa.c:439 #4 0xff102d00 in VSL_Dispatch (vd=0x4df88, func=0x11e28 , priv=0x23660) at shmlog.c:383 #5 0x00012ba4 in main (argc=1, argv=0xffbffa0c) at varnishncsa.c:598 (gdb) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 18 14:48:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 May 2010 14:48:14 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.c01a2052a5b27c6a5ad454a30b6b7736@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): I've analyzed today a core dump of a varnish process panicking with {{{ Assert error in vca_add(), cache_acceptor_ports.c line 63: Condition((port_associate(solaris_dport, 4, fd, 0x0001, data)) == 0) not true. errno = 11 (Resource temporarily unavailable) }}} This issue should only occur after Varnish has been running for a long time under high load (with many parallel connections) and besides the panic it ''should'' not have negative side effects. In the original notes for the fix, I had mentioned this point: No need to call vca_del once we've received an event for the respective fd Apparently, my understanding was wrong. I am waiting for confirmation in http://opensolaris.org/jive/thread.jspa?threadID=129476&tstart=0 but for the meantime, I'll attach a fixed version of the acceptor. This newer version also implements improved timeout handling, resulting in less port_getn() calls on low traffic sites plus options to tune the acceptor for even better throughput trading in additional latency (by setting nevents > 1 in the code). Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 18 14:52:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 May 2010 14:52:20 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.3a0eed81bcba36ab84784b8bff21ec70@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): BTW, TIM_t2ts() is in {630} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 18 14:52:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 May 2010 14:52:48 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.bb8462590f45aeb8f4eea8ac53a5f2c8@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): TIM_t2ts() is in #630 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 18 15:27:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 May 2010 15:27:40 -0000 Subject: [Varnish] #681: problems using regular expressions with varnishlog In-Reply-To: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org> References: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org> Message-ID: <059.124b38ac44f94ed71499294e9d6a5a65@varnish-cache.org> #681: problems using regular expressions with varnishlog ---------------------------+------------------------------------------------ Reporter: danielpicolli | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishlog | Version: Severity: critical | Keywords: regular expressions varnishlog ---------------------------+------------------------------------------------ Comment(by rkferreira): Hi, In my tests, this is a simple mistake at VSL_NextLog function in "lib/libvarnishapi/shmlog.c" at line 350. I changed that, and it works fine. < i = VRE_exec(vd->regexcl, --- > i = VRE_exec(vd->regincl, Att., Rodrigo Kellermann Ferreira -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 13:54:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 13:54:13 -0000 Subject: [Varnish] #690: Allow for a negative grace period for internal crawler In-Reply-To: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> References: <047.d98dd591f621c43b8fc647a1d5f25dbc@varnish-cache.org> Message-ID: <056.84157a2d8b06de2511b76744074b87ec@varnish-cache.org> #690: Allow for a negative grace period for internal crawler -------------------------+-------------------------------------------------- Reporter: mikeytown2 | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Resolution: wontfix | Keywords: grace -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: Actually closing it this time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 14:07:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 14:07:53 -0000 Subject: [Varnish] #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) In-Reply-To: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> References: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> Message-ID: <054.ee8a0b42178c2e74ee2e43a78486eb8f@varnish-cache.org> #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) ----------------------+----------------------------------------------------- Reporter: osterman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Keywords: | ----------------------+----------------------------------------------------- Comment(by phk): Can you try to apply r4630, and see if that solves the problem for you ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 19:40:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 19:40:34 -0000 Subject: [Varnish] #701: Parameters to limit URI / header sizes In-Reply-To: <042.493cf661d63924842b246786a8245a7c@varnish-cache.org> References: <042.493cf661d63924842b246786a8245a7c@varnish-cache.org> Message-ID: <051.73bf6bc10b630d72d2ba3bf4bb96a85e@varnish-cache.org> #701: Parameters to limit URI / header sizes ------------------------------------------------+--------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: max_hdr_len max_uri_len limit size | ------------------------------------------------+--------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: We already have a length check on the total request: half the workspace. That should probably become a parameter. Further checks should be in VCL, and while it is easy to do {{{ if (length(req.http) > 200) {...} }}} it is harder with req.http.* since you may not know which headers are there. A combination with a header-washing function is relevant here. I have moved this to the PostTwoShoppingList wiki page. (We only use tickets to track actual bugs, not feature requests). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 19:54:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 19:54:08 -0000 Subject: [Varnish] #700: Response Reason-Phrase can contain SP In-Reply-To: <042.348b46dfda00d59b349769e65b19cd10@varnish-cache.org> References: <042.348b46dfda00d59b349769e65b19cd10@varnish-cache.org> Message-ID: <051.cb6f1e0811a914f772ac2e928adf0187@varnish-cache.org> #700: Response Reason-Phrase can contain SP ---------------------+------------------------------------------------------ Reporter: slink | 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 [4829]) Allow TAB in the 3rd field of the first line of HTTP requests and responses. Fixes: #700 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 20:16:29 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 20:16:29 -0000 Subject: [Varnish] #682: hash maps In-Reply-To: <047.b6895b33e6460a13ca874a4205f65ea0@varnish-cache.org> References: <047.b6895b33e6460a13ca874a4205f65ea0@varnish-cache.org> Message-ID: <056.80505a8fbde2b5e0aeac7c3e15ced6c4@varnish-cache.org> #682: hash maps -----------------------------------+---------------------------------------- Reporter: rosenfield | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: hash, hashtable, maps | -----------------------------------+---------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This is the kind of stuff where I have to point at inline-C and say "do it yourself". We cannot be everything for everybody by default, that is why I added inline-C so that people would never be stuck trying to do stuff like this. We plan to offer a "module" version of inline-C, where you precompile your code to a library, and this may be a good candidate for such a module. I'm closing this ticket, and moving the subject to our PostTwoShoppingList, tickets are only used for geniune bugs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 20:55:37 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 20:55:37 -0000 Subject: [Varnish] #693: Assert error in WS_Release(), cache_ws.c line 175 In-Reply-To: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> References: <041.b7912eca71133476ac9664dc07a8c8c2@varnish-cache.org> Message-ID: <050.a62e1772ffceda3dbb5d0e8dcf8f6600@varnish-cache.org> #693: Assert error in WS_Release(), cache_ws.c line 175 ---------------------+------------------------------------------------------ Reporter: tore | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4830]) Fix an off-by one error in vrt_assemble_string() when we use up exactly the number of bytes in the workspace. This is the most obscure test-case I have written so far, and I wonder how portable it is. I may have to drop it if it does not work on systems with different width/alignment requirements. Fixes: #693 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 21:02:57 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 21:02:57 -0000 Subject: [Varnish] #695: Varnish trunk 4516 segmentation fault in FreeBSD In-Reply-To: <043.0c8af4e7ee3cb80191b04279eace67a7@varnish-cache.org> References: <043.0c8af4e7ee3cb80191b04279eace67a7@varnish-cache.org> Message-ID: <052.65fa4600bad959b8165f2c4aba8e5c39@varnish-cache.org> #695: Varnish trunk 4516 segmentation fault in FreeBSD ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): Just for reference, it is this assert: {{{ 786 if (oc == NULL) { 787 /* 788 * We lost the session to a busy object, disembark the 789 * worker thread. The hash code to restart the session, 790 * still in STP_LOOKUP, later when the busy object isn't. 791 */ 792 AZ(sp->wrk); 793 return (1); 794 } }}} And I have absolutely no idea how that could happen, but will keep an eye out for it. I do notice that you are running an earlier version of -hcritbit and wonder if that could be involved. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed May 19 21:05:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 May 2010 21:05:55 -0000 Subject: [Varnish] #683: varnishd usage output out of date In-Reply-To: <045.159da22a2165a289f563b20ba189dd1a@varnish-cache.org> References: <045.159da22a2165a289f563b20ba189dd1a@varnish-cache.org> Message-ID: <054.45c93e4602e558b5c6e033ac61d80771@varnish-cache.org> #683: varnishd usage output out of date ----------------------+----------------------------------------------------- Reporter: dormando | 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 [4831]) add -hcritbit and -spersist to usage. Fixes: #683 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 12:19:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 12:19:27 -0000 Subject: [Varnish] #702: Bad Content-Length when Range support is enabled Message-ID: <040.9b4b78cfba6b6316328629430e1a30b2@varnish-cache.org> #702: Bad Content-Length when Range support is enabled -------------------+-------------------------------------------------------- Reporter: luc | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Testing varnish 2.1.2 When the client ask for a range greater than the size of the file, the content length is set off by one of the real size, so the client is stuck waiting for more data. I can reproduce it easily with curl: pontis.js size: 10629 bytes {{{ curl -v \ -H 'Host: s1.s-sfr.fr' \ -H 'Range: bytes=0-20000'\ http://93.17.156.118/js/pontis.js }}} Curl sends: {{{ > GET /js/pontis.js HTTP/1.1 > User-Agent: curl/7.20.0 (i486-pc-linux-gnu) libcurl/7.20.0 OpenSSL/0.9.8n zlib/1.2.3.4 libidn/1.15 libssh2/1.2.4 > Accept: */* > Host: s1.s-sfr.fr > Range: bytes=10000-20000 }}} Varnish response: {{{ < HTTP/1.1 206 Partial Content < Server: Apache/2.2.13 (Fedora) < Last-Modified: Mon, 19 Apr 2010 13:15:23 GMT < Via: http3 < Cache-Control: public < Expires: Thu, 20 May 2010 12:04:03 GMT < Vary: Accept-Encoding < Content-Type: text/javascript < Accept-Ranges: bytes < Date: Thu, 20 May 2010 11:59:24 GMT < X-Varnish: 221598756 210156964 < Age: 3669 < Via: 1.1 varnish < Connection: keep-alive < Content-Range: bytes 0-10629/10629 < Content-Length: 10630 }}} The content-length is clearly incorrect, and the client wait for 10630 bytes, and varnish only send 10629. Others case can be: {{{ curl -v -H 'Host: s1.s-sfr.fr' http://93.17.156.118/js/pontis.js -H 'Range: bytes=10628-10629' < Content-Range: bytes 10628-10629/10629 < Content-Length: 2 }}} Should be 1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 13:20:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 13:20:25 -0000 Subject: [Varnish] #703: varnish segfaults on arm Message-ID: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> #703: varnish segfaults on arm --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- When trying to run varnish on a sheevaplug it segfaults. gdb on the core: Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l 10000000'. Program terminated with signal 11, Segmentation fault. [New process 1578] #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 408 loghead->master_pid = getpid(); (gdb) bt #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 #1 0x0004e694 in main (argc=, argv=) at varnishd.c:669 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 13:21:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 13:21:32 -0000 Subject: [Varnish] #703: varnish segfaults on arm In-Reply-To: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> References: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> Message-ID: <051.051e4cab0294b73ae41d9039f9e5e516@varnish-cache.org> #703: varnish segfaults on arm --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > When trying to run varnish on a sheevaplug it segfaults. gdb on the core: > > Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l > 10000000'. > Program terminated with signal 11, Segmentation fault. > [New process 1578] > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > 408 loghead->master_pid = getpid(); > (gdb) bt > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > #1 0x0004e694 in main (argc=, argv= out>) at varnishd.c:669 New description: When trying to run varnish on a sheevaplug it segfaults. gdb on the core: {{{ Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l 10000000'. Program terminated with signal 11, Segmentation fault. [New process 1578] #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 408 loghead->master_pid = getpid(); (gdb) bt #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 #1 0x0004e694 in main (argc=, argv=) at varnishd.c:669 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 13:22:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 13:22:21 -0000 Subject: [Varnish] #703: varnish segfaults on arm In-Reply-To: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> References: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> Message-ID: <051.b2a5884be7980ed1acaf80570eb8e46e@varnish-cache.org> #703: varnish segfaults on arm --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > When trying to run varnish on a sheevaplug it segfaults. gdb on the core: > {{{ > Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l > 10000000'. > Program terminated with signal 11, Segmentation fault. > [New process 1578] > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > 408 loghead->master_pid = getpid(); > (gdb) bt > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > #1 0x0004e694 in main (argc=, argv= out>) at varnishd.c:669 > }}} New description: When trying to run varnish on a sheevaplug it segfaults. gdb on the core: {{{ Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l 10000000'. Program terminated with signal 11, Segmentation fault. [New process 1578] #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 408 loghead->master_pid = getpid(); (gdb) bt #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 #1 0x0004e694 in main (argc=, argv=) at varnishd.c:669 }}} The plug is running ubuntu 9.04. 512M ram and 512M flash on jffs2. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 13:23:07 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 13:23:07 -0000 Subject: [Varnish] #703: varnish segfaults on arm In-Reply-To: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> References: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> Message-ID: <051.d49a5c187875dcaed4d7b468e892587f@varnish-cache.org> #703: varnish segfaults on arm --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by perbu: Old description: > When trying to run varnish on a sheevaplug it segfaults. gdb on the core: > {{{ > Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l > 10000000'. > Program terminated with signal 11, Segmentation fault. > [New process 1578] > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > 408 loghead->master_pid = getpid(); > (gdb) bt > #0 VSL_MgtInit (fn=, size=) at > shmlog.c:408 > #1 0x0004e694 in main (argc=, argv= out>) at varnishd.c:669 > }}} > > The plug is running ubuntu 9.04. 512M ram and 512M flash on jffs2. New description: When trying to run varnish on a sheevaplug it segfaults. gdb on the core: {{{ Core was generated by `varnishd -b localhost:8080 -d -s malloc,100M -l 10000000'. Program terminated with signal 11, Segmentation fault. [New process 1578] #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 408 loghead->master_pid = getpid(); (gdb) bt #0 VSL_MgtInit (fn=, size=) at shmlog.c:408 #1 0x0004e694 in main (argc=, argv=) at varnishd.c:669 }}} The plug is running ubuntu 9.04. 512M ram and 512M flash on jffs2. {{{ Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl GNU/Linux }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 17:15:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 17:15:26 -0000 Subject: [Varnish] #704: Incorrect Range support for the last n bytes Message-ID: <040.af42aa00b4b49c6c36e4d5aa07ff066f@varnish-cache.org> #704: Incorrect Range support for the last n bytes -------------------+-------------------------------------------------------- Reporter: luc | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- According to the spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1, {{{ - The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500 }}} But varnish return the first n characters, because low is set to 0. {{{ curl -s -v -H 'Host: s1.s-sfr.fr' http://93.17.156.118/js/pontis.js -H 'Range: bytes=-1' > GET /js/pontis.js HTTP/1.1 > User-Agent: curl/7.20.0 (i486-pc-linux-gnu) > Accept: */* > Host: s1.s-sfr.fr > Range: bytes=-1 > < HTTP/1.1 206 Partial Content < Server: Apache-Coyote/www1 < Last-Modified: Mon, 19 Apr 2010 13:15:23 GMT < Content-Type: text/javascript < Via: 1.1 www.s-sfr.fr < Cache-Control: public < Expires: Thu, 20 May 2010 17:50:49 GMT < Vary: Accept-Encoding < Via: http1 < Accept-Ranges: bytes < Date: Thu, 20 May 2010 15:50:49 GMT < X-Varnish: 2115996372 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive < Content-Range: bytes 0-1/10629 < Content-Length: 2 }}} This patch try to fix it, and must by apply after the #702 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu May 20 20:57:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 May 2010 20:57:55 -0000 Subject: [Varnish] #705: ESI - turning off Accept-Encoding for ESI includes Message-ID: <045.db41b12b070cf1e3ed417c284aa1b90b@varnish-cache.org> #705: ESI - turning off Accept-Encoding for ESI includes -------------------------+-------------------------------------------------- Reporter: askalski | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.1 Severity: normal | Keywords: esi gzip -------------------------+-------------------------------------------------- I'm configuring ESI for specific pages within my site, and ran into difficulty with disabling gzip compression for both the main request, and all includes. {{{ sub vcl_recv { if (req.url == "/file/with/esi/includes.css") { # Prevent the backend from compressing the main file, # otherwise it can't be ESI-processed. # # However, because the session 'req.http' workspace gets # rolled back before each include, this setting will # get obliterated, and each of the included chunks will # come back compressed by the backend. # unset req.http.Accept-Encoding; } } sub vcl_fetch { if (req.url == "/file/with/esi/includes.css") { # Run ESI processing on the special ESI-enabled file(s) esi; } } }}} As far as I can tell, there is no flag that I can check in vcl_recv() to determine if it's processing an ESI include: {{{ if (req.is_esi_include) { # hypothetical flag unset req.http.Accept-Encoding; } }}} And there doesn't seem to be any way to access/modify the master copy (sp->http0) without dropping into C (and even that might not be possible without varnishd's private includes. {{{ unset req.http0.Accept-Encoding; }}} {{{ C{ http_Unset(sp->http0, H_Accept_Encoding); }C ./vcl.N9K6Q6Az.c: In function ?VGC_function_vcl_recv?: ./vcl.N9K6Q6Az.c:789: error: dereferencing pointer to incomplete type ./vcl.N9K6Q6Az.c:790: error: ?H_Accept_Encoding? undeclared (first use in this function) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri May 21 18:29:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 May 2010 18:29:38 -0000 Subject: [Varnish] #706: Request to http_header Message-ID: <048.a8797f73f60398c4bed82c26f5afb8aa@varnish-cache.org> #706: Request to http_header -------------------------+-------------------------------------------------- Reporter: diego.silva | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------------------------------------- How can do request to http_header. The default request is IP, but for IIS server is necessary the http_header. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 24 12:31:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 May 2010 12:31:36 -0000 Subject: [Varnish] #707: "Write error, len = 64860/120095, errno = Success" Message-ID: <042.8140cfcaf6a4d21443b5a3493ff891dd@varnish-cache.org> #707: "Write error, len = 64860/120095, errno = Success" ----------------------+----------------------------------------------------- Reporter: erans | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- While Varnish is running and I run "varnishlog -i debug" every X "herding" rows I see: "Write error, len = 64860/120095, errno = Success" I'm setting it on "trunk" because there is no 2.1.2 Version in trac. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue May 25 08:13:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 May 2010 08:13:41 -0000 Subject: [Varnish] #707: "Write error, len = 64860/120095, errno = Success" In-Reply-To: <042.8140cfcaf6a4d21443b5a3493ff891dd@varnish-cache.org> References: <042.8140cfcaf6a4d21443b5a3493ff891dd@varnish-cache.org> Message-ID: <051.5d166f5bcc0f99082c706a6f32607c32@varnish-cache.org> #707: "Write error, len = 64860/120095, errno = Success" ----------------------+----------------------------------------------------- Reporter: erans | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by anakin): We have noticed that as well. Using Varnish 2.1 for serving large (20M) file causes clients to be have connection reset quite often. While testing with wget/curl with download limit i.e. 100 B/s Varnish stops serving file with "Write error" like above every time, on exactly the same time and bytes served every time. Increasing speed just changes these values but download is still stopped. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 07:41:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 07:41:42 -0000 Subject: [Varnish] #707: "Write error, len = 64860/120095, errno = Success" In-Reply-To: <042.8140cfcaf6a4d21443b5a3493ff891dd@varnish-cache.org> References: <042.8140cfcaf6a4d21443b5a3493ff891dd@varnish-cache.org> Message-ID: <051.5dbbe7600155592fba59a9c0c6aa70e4@varnish-cache.org> #707: "Write error, len = 64860/120095, errno = Success" ----------------------+----------------------------------------------------- Reporter: erans | 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 is the socket timeout: if the client does not accept the data fast enough, we time it out. How patient we are, is controlled by the {{{send_timeout}}} paramter which defaults to 10 minutes. When we talked on irc, I thought you showed a case where the number before the slash were one higher than the number after the slash, that would be a real bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 07:42:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 07:42:20 -0000 Subject: [Varnish] #706: Request to http_header In-Reply-To: <048.a8797f73f60398c4bed82c26f5afb8aa@varnish-cache.org> References: <048.a8797f73f60398c4bed82c26f5afb8aa@varnish-cache.org> Message-ID: <057.bb4566b6bee8ed3ce95261cd5885e2b0@varnish-cache.org> #706: Request to http_header --------------------------+------------------------------------------------- Reporter: diego.silva | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: invalid | Keywords: --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: I don't understand the question, sorry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 07:46:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 07:46:06 -0000 Subject: [Varnish] #705: ESI - turning off Accept-Encoding for ESI includes In-Reply-To: <045.db41b12b070cf1e3ed417c284aa1b90b@varnish-cache.org> References: <045.db41b12b070cf1e3ed417c284aa1b90b@varnish-cache.org> Message-ID: <054.f2985b70ba9286bae68732fb89220e53@varnish-cache.org> #705: ESI - turning off Accept-Encoding for ESI includes -------------------------+-------------------------------------------------- Reporter: askalski | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.1 Severity: normal | Resolution: fixed Keywords: esi gzip | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: You should be able to tell the included sub-requests apart using {{{req.restarts > 0}}} We should probably expose a dedicated variable for this purpose. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:00:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:00:49 -0000 Subject: [Varnish] #702: Bad Content-Length when Range support is enabled In-Reply-To: <040.9b4b78cfba6b6316328629430e1a30b2@varnish-cache.org> References: <040.9b4b78cfba6b6316328629430e1a30b2@varnish-cache.org> Message-ID: <049.7b3c1ca419106f6c27dfeafd841f9623@varnish-cache.org> #702: Bad Content-Length when Range support is enabled ---------------------+------------------------------------------------------ Reporter: luc | 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 r4865. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:45:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:45:16 -0000 Subject: [Varnish] #703: varnish segfaults on arm In-Reply-To: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> References: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org> Message-ID: <051.d5423a29cfe180b9a875dcd703032bbe@varnish-cache.org> #703: varnish segfaults on arm --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Are you sure you can even mmap 80MB for the shmfile on that platform ? Try giving a much smaller -l argument. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:50:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:50:41 -0000 Subject: [Varnish] #704: Incorrect Range support for the last n bytes In-Reply-To: <040.af42aa00b4b49c6c36e4d5aa07ff066f@varnish-cache.org> References: <040.af42aa00b4b49c6c36e4d5aa07ff066f@varnish-cache.org> Message-ID: <049.171d52c4ed16751794ab50472781a10b@varnish-cache.org> #704: Incorrect Range support for the last n bytes ---------------------+------------------------------------------------------ Reporter: luc | 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 [4866]) I have no idea how I overlooked that a "bytes=-100" range was from the end of the object, but I did. Fixes #704. Reported by: Luc Saillard -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:51:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:51:49 -0000 Subject: [Varnish] #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) In-Reply-To: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> References: <045.3e0e01d3cc2e6863585a178ddda12ec9@varnish-cache.org> Message-ID: <054.5fcfbd96f2e80493e8c8e204e6edae86@varnish-cache.org> #699: Varnishncsa Will Not Log Certain Requests Due to Out of Sequence (ReqEnd, SessionClose) -----------------------+---------------------------------------------------- Reporter: osterman | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: major Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I think this is fixed in r4630. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:52:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:52:58 -0000 Subject: [Varnish] #698: High load after upgrade from 2.1.0 to 2.1.2 In-Reply-To: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org> References: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org> Message-ID: <061.4fc2c37e1ed924089254af157fee39e1@varnish-cache.org> #698: High load after upgrade from 2.1.0 to 2.1.2 -----------------------------+---------------------------------------------- Reporter: lukasz.jagiello | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Comment(by phk): I think this is a misjudgment in the critbit hasher, we're working on a fix. In the meantime use -hclassic -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:53:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:53:33 -0000 Subject: [Varnish] #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! In-Reply-To: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> References: <044.5487128356ddb1f28535007984ee483e@varnish-cache.org> Message-ID: <053.d013268096320fc42fa187e1e44b7408@varnish-cache.org> #697: I updated from Varnis 2.0.4 to 2.1.2 and nothing working! ----------------------+----------------------------------------------------- Reporter: Rodrigo | Owner: phk Type: defect | Status: closed Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timed out, no reply. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 08:55:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 08:55:14 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.b54e99a66f3e82d65297ebc4cf4c11d1@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: worksforme Keywords: hang stop responding | ----------------------------------+----------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 11:31:59 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 11:31:59 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris In-Reply-To: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> References: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> Message-ID: <053.cfc4b7d88ac631835011dca28be01ba3@varnish-cache.org> #649: Varnish LINGER crash on Solaris ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Comment(by phk): See also r4868 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 11:32:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 11:32:32 -0000 Subject: [Varnish] #649: Varnish LINGER crash on Solaris In-Reply-To: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> References: <044.dba636e1bee79572f4a6f51b8506083e@varnish-cache.org> Message-ID: <053.433eebe3454c537a380e3d47e7d726b9@varnish-cache.org> #649: Varnish LINGER crash on Solaris ----------------------+----------------------------------------------------- Reporter: victori | 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: sorry, forgot to set ticket state in previous update. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 12:17:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 12:17:06 -0000 Subject: [Varnish] #708: XML display is not documented Message-ID: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org> #708: XML display is not documented ---------------------------+------------------------------------------------ Reporter: jerome | Owner: phk Type: documentation | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: minor | Keywords: varnishstat ---------------------------+------------------------------------------------ Varnishstat support the '-x' argument which makes it display the statistics in XML. This feature is not document in varnishstat.1 I wrote the missing documentation part in varnishstat.1, the patch is attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 18:30:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 18:30:43 -0000 Subject: [Varnish] #709: After SessionClose c EOF there is a second ReqEnd c 0 Message-ID: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org> #709: After SessionClose c EOF there is a second ReqEnd c 0 ----------------------+----------------------------------------------------- Reporter: jdzst | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am testing Varnish (r4576) in Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000. It seems that when a session is closed because of a "SessionClose c EOF" there is always a second "ReqEnd" but empty, without XID: varnishncsa output: {{{ 87.111.62.154 - - [31/May/2010:16:04:48 +0200] "GET " 304 0 (BOGUS REQUEST) => In r4576 varnishncsa it generates a coredump in Solaris 85.112.8.250 - - [31/May/2010:16:04:49 +0200] "GET " 200 13715 }}} varnishlog output (extract): {{{ 15 SessionOpen c 87.111.62.154 50132 :8000 15 ReqStart c 87.111.62.154 50132 397508944 15 RxRequest c GET 15 VCL_call c recv 15 VCL_return c lookup 15 VCL_call c hash 15 VCL_return c hash 15 Hit c 397508913 15 VCL_call c hit 15 VCL_return c deliver 15 Length c 0 15 VCL_call c deliver 15 VCL_return c deliver 15 TxProtocol c HTTP/1.1 15 TxStatus c 304 15 TxResponse c Not Modified 15 TxHeader c Date: Mon, 31 May 2010 14:04:48 GMT 15 TxHeader c Last-Modified: Wed, 17 Sep 2008 14:19:30 GMT 15 TxHeader c Cache-Control: max-age=345600 15 TxHeader c Expires: Fri, 04 Jun 2010 14:04:48 GMT 15 TxHeader c Connection: keep-alive 15 TxHeader c X-Cache: HIT 15 ReqEnd c 397508944 1275314688.964520454 1275314688.965110540 0.000231504 0.000289917 0.000300169 15 SessionClose c EOF 15 ReqEnd c 0 1275314689.074620008 1275314689.074620008 0.109509468 0.000000000 0.000000000 15 StatSess c 87.111.62.154 50132 0 1 1 0 0 0 285 0 15 SessionOpen c 85.112.8.250 60478 :8000 15 ReqStart c 85.112.8.250 60478 397508952 15 RxRequest c GET 15 VCL_call c recv 15 VCL_return c lookup }}} At least, it generates problems in varnishncsa -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 18:39:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 18:39:20 -0000 Subject: [Varnish] #709: After SessionClose c EOF there is a second ReqEnd c 0 In-Reply-To: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org> References: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org> Message-ID: <051.b9c3caec207de073516275611f82da83@varnish-cache.org> #709: After SessionClose c EOF there is a second ReqEnd c 0 ----------------------+----------------------------------------------------- Reporter: jdzst | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by jdzst): The varnishncsa are explained in tickets #633 and #685 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 18:43:54 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 18:43:54 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.951b7936c144dc15c1025a2e0d9ad0bb@varnish-cache.org> #633: varnishncsa segfaults ---------------------+------------------------------------------------------ Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------+------------------------------------------------------ Comment(by jdzst): Hello, I think both tickets #633 and #685 are related with same problem. I have tested again the problem in production with enviroment: => I am testing Varnish (r4576) in Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000. the problem is that in this Request '''lp->df_m , lp->df_Uq, lp->df_H and lp->df_s are NULL''' I have Removing the #if 0/#endif around line 390 and segfaults stopped as a workaround After that, I have changed varnishncsa.c to retrieve more information and print all BOGUS requests in log with "BOGUS REQUEST INFO [%s] XID [%u]\n" , my testing file is in the previous attachment, and those are the results: (example) varnishncsa output: {{{ 87.111.62.154 - - [31/May/2010:16:04:48 +0200] "GET " 304 0 - - - [31/May/2010:16:04:49 +0200] BOGUS REQUEST INFO [-] XID [0] ====> ERROR (This trace is print in my varnishncsa.c code when bogus==1, see attachment) 85.112.8.250 - - [31/May/2010:16:04:49 +0200] "GET " 200 13715 }}} varnishlog output (extract): {{{ 15 SessionOpen c 87.111.62.154 50132 :8000 15 ReqStart c 87.111.62.154 50132 397508944 15 RxRequest c GET 15 VCL_call c recv 15 VCL_return c lookup 15 VCL_call c hash 15 VCL_return c hash 15 Hit c 397508913 15 VCL_call c hit 15 VCL_return c deliver 15 Length c 0 15 VCL_call c deliver 15 VCL_return c deliver 15 TxProtocol c HTTP/1.1 15 TxStatus c 304 15 TxResponse c Not Modified 15 TxHeader c Date: Mon, 31 May 2010 14:04:48 GMT 15 TxHeader c Last-Modified: Wed, 17 Sep 2008 14:19:30 GMT 15 TxHeader c Cache-Control: max-age=345600 15 TxHeader c Expires: Fri, 04 Jun 2010 14:04:48 GMT 15 TxHeader c Connection: keep-alive 15 TxHeader c X-Cache: HIT 15 ReqEnd c 397508944 1275314688.964520454 1275314688.965110540 0.000231504 0.000289917 0.000300169 15 SessionClose c EOF 15 ReqEnd c 0 1275314689.074620008 1275314689.074620008 0.109509468 0.000000000 0.000000000 15 StatSess c 87.111.62.154 50132 0 1 1 0 0 0 285 0 15 SessionOpen c 85.112.8.250 60478 :8000 15 ReqStart c 85.112.8.250 60478 397508952 15 RxRequest c GET 15 VCL_call c recv 15 VCL_return c lookup }}} It seems that the root of all problems is when a session is closed because of a "SessionClose c EOF" there is always a second "ReqEnd" but empty, without XID: {{{ 15 ReqEnd c 397508944 1275314688.964520454 1275314688.965110540 0.000231504 0.000289917 0.000300169 15 SessionClose c EOF 15 ReqEnd c 0 1275314689.074620008 1275314689.074620008 0.109509468 0.000000000 0.000000000 }}} I think it must be changed the "varnishncsa" logic, retrieve the XID from ReqEnd and ignore request if the xid== 0 avoiding print bad ReqEnd entries. It would be interesting to print (in standard error) wrong request that has bogus==1 but xid!=0 I will prepare some code and post it in this ticket in order to fix varnishncsa ignoring ReqEnd without xid and dumping wrong request in stderr. The real problem, (when a session is closed because of a "SessionClose c EOF" there is always a second "ReqEnd") it is opened in a new ticket #709 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon May 31 18:48:15 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 31 May 2010 18:48:15 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.4062d4244080e0bca10f801be490f520@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by jdzst): Hello, I think both tickets #633 and #685 are related with similar problems, a empty ReqEnd that is processed by varnishncsa In Solaris 10, instead printing "(null) (null) (null)" (null) - "-" "-" varnishncsa generates a coredump: {{{ Core was generated by `/export/home/web1/varnish/bin/varnishncsa'. Program terminated with signal 11, Segmentation fault. [New process 87281 ] #0 0xfefb1d70 in strlen () from /lib/libc.so.1 (gdb) bt #0 0xfefb1d70 in strlen () from /lib/libc.so.1 #1 0xff01b038 in _ndoprnt () from /lib/libc.so.1 #2 0xff01d048 in fprintf () from /lib/libc.so.1 #3 0x000123e0 in h_ncsa (priv=0x23660, tag=SLT_ReqEnd, fd=5, len=79, spec=1, ptr=0xfa15b35b
) at varnishncsa.c:439 #4 0xff102d00 in VSL_Dispatch (vd=0x4df88, func=0x11e28 , priv=0x23660) at shmlog.c:383 #5 0x00012ba4 in main (argc=1, argv=0xffbffa0c) at varnishncsa.c:598 (gdb) }}} More information in #633 and #709. -- Ticket URL: Varnish The Varnish HTTP Accelerator