From varnish-bugs at varnish-cache.org Fri Jul 1 08:22:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 08:22:15 -0000 Subject: [Varnish] #950: varnishncsa with %{X}x-parameters crashes on error 405 Message-ID: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> #950: varnishncsa with %{X}x-parameters crashes on error 405 -------------------+-------------------------------------------------------- Reporter: ljorg | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Starting varnishncsa with -F "%h %l %u %t \"%m %U %H\" %s %b \"%{Referer}i\" \"%{User-agent}i\" %{Varnish:handling}x" makes varnishncsa crash with a segmentation fault when varnishd issues a 405 (in conjunction with attempted access to a restricted area on a cached website). Removing "%{Varnish:handling}x" fixes the problem, but then I can't see hit/miss/pass/pipe-status in the log -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 08:23:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 08:23:52 -0000 Subject: [Varnish] #950: varnishncsa with %{X}x-parameters crashes on error 405 In-Reply-To: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> References: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> Message-ID: <051.d00bfdb85c65345e7b8e18bdef5d3db8@varnish-cache.org> #950: varnishncsa with %{X}x-parameters crashes on error 405 -------------------+-------------------------------------------------------- Reporter: ljorg | Type: defect Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by ljorg): May be a duplicate of ticket #944 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 14:32:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 14:32:29 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls Message-ID: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ scenario: - overall request rate to varnish close to 1000req/s or more - tens of thousands active clients browsing user sites - most requested UNCACHEABLE url's get stuck - varnish never(that is a few minutes at least) return response - webservers DO NOT get hit after its stuck for that url - several requests per second to these urls - high probability they get hit almost simultaneusly by several users - i suspect some form of race condition /deadlock - slow responding web servers - for every request they may take up to several seconds to process - hard to catch the moment it gets stuck as log volume is too high to log everything - n_sess grows with every stuck request, eating system ram - OS: centos 5.6 x64, varnish-2.1.5-1 rpms - request path: haproxy->varnish->haproxy->apache->php - no swapping in normal operation, entire cache in ram cmdline: {{{ /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish -g varnish -S /etc/varnish/secret -w 1300,4000,60 -p thread_pool_add_delay 3 -s malloc,8G -p session_max 400000 -p cli_timeout 20 -p listen_depth 2048 -a 192.168.1.202:6080,127.0.0.1:6080 }}} example log AFTER its stuck: {{{ 88148 SessionOpen c 192.168.1.217 40177 192.168.1.202:6080 88148 ReqStart c 192.168.1.217 40177 741240382 88148 RxRequest c GET 88148 RxURL c / 88148 RxProtocol c HTTP/1.1 88148 RxHeader c Host: xxxxxxxx.xxx.xx 88148 RxHeader c Accept: application/vnd.wap.xhtml+xml, application/xhtml+xml, text/html, application/vnd.wap.wmlc, image/vnd.wap.wbmp, image/png, image/jpeg, image/gif, image/bmp, text/vnd.wap.wml, text/vnd.wap.wmlscript, application/vnd.oma.dd+xml, text/vnd.sun.j2me.app 88148 RxHeader c Accept-Language: vi 88148 RxHeader c Accept-Charset: utf-8;q=1.0,utf-16;q=1.0,iso-8859-1;q=0.6,*;q=0.1 88148 RxHeader c x-wap-profile: "http://wap.samsungmobile.com/uaprof/GT-C3510.xml" 88148 RxHeader c User-Agent: SAMSUNG-GT-C3510/1.0 NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1 88148 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 88148 RxHeader c X-Forwarded-For: yyy.yyy.yyy.yyy 88148 RxHeader c Connection: close 88148 VCL_call c recv 88148 VCL_return c lookup 88148 VCL_call c hash 88148 VCL_return c hash }}} thats it, no more log entries for 88148 in near future at least - question: is there a way to check the state of the stuck threads? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 16:06:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 16:06:37 -0000 Subject: [Varnish] #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax Message-ID: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Error message is... 'obj.http.set-cookie': cannot be unset in method 'vcl_fetch'. At: ('input' Line 16 Pos 23) unset obj.http.set-cookie; I'm new to Varnish. Someone let me know what this changed to in 3.0 and also how best to look this up in the docs. Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 16:31:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 16:31:07 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.92e8d3f2c5ab49e10c80e38a9c237352@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by tttt): actually i was wrong, some requests do get thru for the stuck url, haproxy log stats: {{{ 82 200 ---- GET xxx # got thru 1480 -1 CH-- GET xxx # client cancel, that mostly means people click cancel, but also might include some slow 200 responses 2884 504 sH-- GET xxx # timeout on waiting for varnish }}} in the roughly same timeframe apache servers report around 600 hits with status 200 on this same url theres also few 500/503 apache responses - under pressure apache/php will spit out few errors for granted. i'm sure its not apache problem as i have haproxy that stands before and after varnish in request path - and haproxy is rock solid in my experience. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 16:50:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 16:50:08 -0000 Subject: [Varnish] #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax In-Reply-To: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> References: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> Message-ID: <052.cf5614a5b6e7341d8a3dd4f721d3c58e@varnish-cache.org> #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by dfavor): https://www.varnish-cache.org/trac/wiki/VarnishAndWordpress is full URL to page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 21:20:40 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 21:20:40 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.d6add752be9172347912f917d038c70f@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by kb): I believe this is actually expected behavior. Varnish wants to download these objects and store them in cache before letting subsequent requests "in" to the object. This is common in two situations I've seen: 1. Your web server takes longer to respond than your .first_byte_timeout, and thus never makes it into Varnish. All requests pile up on a linear line of requests that each take .first_byte_timeout seconds. 2. Your web server is taking a "long time" to reply, and the object is not cacheable. A similar serialization takes place, orthogonal to .first_byte_timeout. Varnish doesn't know whether the object is cacheable or not until it receives the response, and I don't know of a way to tell Varnish whether an object is cacheable /before/ the request happens. My only suggestion for a "fix" would be to add something like this to your vcl_recv(): if ( req.url ~ "/your/very/slow/URLs" ) { set req.hash_ignore_busy = true; } That should allow incoming requests to open new requests to your backend (removing the serialization). But honestly, if you have painfully slow, non-cacheable resources, it might be better to route those directly to the backend(s) rather than clutter up Varnish. Or perhaps separate those requests into different servers along functional lines. FWIW, Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 1 22:54:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Jul 2011 22:54:49 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.ef0032e99293443f01f6b594338932d4@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by dfavor): This may be the same issue as #952. My .vlc file has no directives at all. In other words, no caching. Many times ab simply hangs an netstat returns no connections. Other times many connections are in TIME_WAIT state. Hitting apache directly works fine. Only Varnish seems to hang. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jul 2 07:52:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Jul 2011 07:52:02 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.606d1772548e39e40826c882051d13d4@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by tttt): Replying to [comment:2 kb]: > I believe this is actually expected behavior. Varnish wants to download these objects and store them in cache before letting subsequent requests "in" to the object. This is common in two situations I've seen: > > 1. Your web server takes longer to respond than your .first_byte_timeout, and thus never makes it into Varnish. All requests pile up on a linear line of requests that each take .first_byte_timeout seconds. [[BR]] i have first_byte_timeout set at 51s and its highly unlikely that apache responds routinely that slow. in fact, if i skip varnish in the request path, the affected url is handled by apache just fine. apache processes can get stuck under pressure, so its certainly reasonable to assume that varnish gets all sorts of timeouts or random trash response from time to time. varnish is expected to handle that. #942 describes one case where varnish may be failing to perform correctly. [[BR]] > 2. Your web server is taking a "long time" to reply, and the object is not cacheable. A similar serialization takes place, orthogonal to .first_byte_timeout. > > Varnish doesn't know whether the object is cacheable or not until it receives the response, and I don't know of a way to tell Varnish whether an object is cacheable /before/ the request happens. > > My only suggestion for a "fix" would be to add something like this to your vcl_recv(): > > if ( req.url ~ "/your/very/slow/URLs" ) { > set req.hash_ignore_busy = true; > } > > That should allow incoming requests to open new requests to your backend (removing the serialization). [[BR]] I wasn't aware of this option, thanks. Actually, i have set it globally now for a test and it seems to break the stall (i'm aware that it also should break request pileup protection). we'll see how this affects operation at peak. [[BR]] > > But honestly, if you have painfully slow, non-cacheable resources, it might be better to route those directly to the backend(s) rather than clutter up Varnish. Or perhaps separate those requests into different servers along functional lines. [[BR]] Its not that simple in our case. We have millions of user generated files that might be cacheable or not, depending on the file content and context (logged in or not, account has forced ads or not); response time also depends on external ad sources, so its not really that predictable. The expected behaviour for me would be that when varnish gets uncacheable response for url it marks that url as non-waitable until it gets a cacheable response from it (again) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jul 2 08:02:24 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Jul 2011 08:02:24 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.f51fe87d42951609ab681c10189ac4f3@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by tttt): Lets make it clear once again: - serialization is only needed to protect backend from request pileup on cache expire. - if cache can't use backend response multiple times serialization is not needed or desired. if you know other reasons, please object. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jul 2 15:24:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Jul 2011 15:24:52 -0000 Subject: [Varnish] #953: Leak in the TransientStorage? Message-ID: <043.d411d994202d179d7348bd87ecffbaea@varnish-cache.org> #953: Leak in the TransientStorage? --------------------+------------------------------------------------------- Reporter: elurin | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- I have some billions objects on then storage and cache server with varnish. In 3.0 memory has to end. I set malloc storage to 100M (for tests) and saw as TransientStorage grow to 48G (my server's memory size) {{{ SMA.s0.nreq 163557 323.88 Allocator requests SMA.s0.nobj 14218 . Outstanding allocations SMA.s0.nbytes 104857305 . Outstanding bytes SMA.s0.balloc 114128697 . Bytes allocated SMA.s0.bfree 9271392 . Bytes free SMA.Transient.nreq 302596 599.20 Allocator requests SMA.Transient.nobj 278306 . Outstanding allocations SMA.Transient.nbytes 2051140026 . Outstanding bytes SMA.Transient.balloc 2063401785 . Bytes allocated SMA.Transient.bfree 12261759 . Bytes free }}} some minutes later {{{ SMA.s0.nreq 176486 322.05 Allocator requests SMA.s0.nobj 14218 . Outstanding allocations SMA.s0.nbytes 104857305 . Outstanding bytes SMA.s0.balloc 114128697 . Bytes allocated SMA.s0.bfree 9271392 . Bytes free SMA.Transient.nreq 329916 602.04 Allocator requests SMA.Transient.nobj 302766 . Outstanding allocations SMA.Transient.nbytes 2234767584 . Outstanding bytes SMA.Transient.balloc 2248472213 . Bytes allocated SMA.Transient.bfree 13704629 . Bytes free }}} May i control TransientStorage size? I'm turn off http_gzip_support, but it has no effect on the problem. Critbit hash type -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jul 2 15:49:03 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Jul 2011 15:49:03 -0000 Subject: [Varnish] #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax In-Reply-To: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> References: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> Message-ID: <052.4221732f35a39d4b7bc910e38a6c5cdd@varnish-cache.org> #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by dfavor): Bump... Anyone know how to fix this? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Jul 2 17:31:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Jul 2011 17:31:38 -0000 Subject: [Varnish] #954: Varnish 3.0 breaks beresp.cacheable VCL syntax Message-ID: <043.f5cf6a574532e116664932074b978913@varnish-cache.org> #954: Varnish 3.0 breaks beresp.cacheable VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- I'm new to Varnish... and the manual for 3.0 says at link... https://www.varnish-cache.org/docs/3.0/reference/vcl.html that beresp.cacheable... "True if the request resulted in a cacheable response. in vcl_fetch referencing this variable throws an error... Message from VCC-compiler: Symbol not found: 'beresp.cacheable' (expected type BOOL): ('input' Line 55 Pos 12) if ( ! beresp.cacheable ) { -----------################---- Running VCC-compiler failed, exit 1 VCL compilation failed Someone let me know how to fix this. Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jul 3 18:16:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Jul 2011 18:16:52 -0000 Subject: [Varnish] #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax In-Reply-To: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> References: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> Message-ID: <052.30519fd49262dd93734adcf62acca1db@varnish-cache.org> #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by mattiasgeniar): The syntax has changed, it's now: unset beresp.http.cookie; -- Ticket URL: Varnish The Varnish HTTP Accelerator From lee.doolan at gmail.com Sun Jul 3 20:15:02 2011 From: lee.doolan at gmail.com (Lee Doolan) Date: Sun, 3 Jul 2011 13:15:02 -0700 Subject: Bug in varnishstat? Message-ID: We are running 3.0.0 Some of the new fields in varnishstat have commas (eg. VBE.production[43](172.21.4.107,,80).vcls VBE.production[43](172.21.4.107,,80).happy VBE.production[44](172.21.4.108,,80).vcls ...) but the -f comand line option takes a comma separated list of field names to display. Escaping ',' and shell special characters (like '(' ) seems to be ignored. -- ? ? tel:? 415/729-4509 From varnish-bugs at varnish-cache.org Mon Jul 4 10:42:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jul 2011 10:42:36 -0000 Subject: [Varnish] #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax In-Reply-To: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> References: <043.b811f066ceebd9728a880cd12d9151b7@varnish-cache.org> Message-ID: <052.eb15e283b39b0181cb5d00f608770673@varnish-cache.org> #952: Varnish 3.0 breaks VarnishAndWordpress VCL syntax ----------------------+----------------------------------------------------- Reporter: dfavor | Type: defect Status: closed | Priority: normal Milestone: | Component: documentation Version: 3.0.0 | Severity: normal Resolution: wontfix | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => wontfix Comment: New syntax documented in comments. Closing ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 4 10:46:02 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jul 2011 10:46:02 -0000 Subject: [Varnish] #950: varnishncsa with %{X}x-parameters crashes on error 405 In-Reply-To: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> References: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> Message-ID: <051.3faaa92bc5f34213620652dcf7ada7b6@varnish-cache.org> #950: varnishncsa with %{X}x-parameters crashes on error 405 -------------------------+-------------------------------------------------- Reporter: ljorg | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 4 10:47:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jul 2011 10:47:06 -0000 Subject: [Varnish] #947: varnishncsa dies on SIGHUP In-Reply-To: <042.abc7c4a4622a2fd6353b2c785d04e210@varnish-cache.org> References: <042.abc7c4a4622a2fd6353b2c785d04e210@varnish-cache.org> Message-ID: <051.4f5b256c9387c082277cb15bddb18c70@varnish-cache.org> #947: varnishncsa dies on SIGHUP -------------------------+-------------------------------------------------- Reporter: ljorg | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 4 12:47:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Jul 2011 12:47:43 -0000 Subject: [Varnish] #955: Redhat spec file still has 3.0.0 beta2 Message-ID: <048.c7dcd7eacda9e87c9d81fbba08d9a76e@varnish-cache.org> #955: Redhat spec file still has 3.0.0 beta2 -------------------------+-------------------------------------------------- Reporter: andreacampi | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | -------------------------+-------------------------------------------------- Building an RPM has been failing since b0fb05b4dd284bcb641110dd2e17e6fcc254d333 (I think) because {{{make dist}}} creates a varnish-trunk.tar.gz file, but {{{rpmbuild}}} still looks for the beta tar. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 5 10:09:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 05 Jul 2011 10:09:37 -0000 Subject: [Varnish] #954: Varnish 3.0 breaks beresp.cacheable VCL syntax In-Reply-To: <043.f5cf6a574532e116664932074b978913@varnish-cache.org> References: <043.f5cf6a574532e116664932074b978913@varnish-cache.org> Message-ID: <052.e11e6d44d2b5bf5c567cbdf9f8010c07@varnish-cache.org> #954: Varnish 3.0 breaks beresp.cacheable VCL syntax --------------------+------------------------------------------------------- Reporter: dfavor | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | --------------------+------------------------------------------------------- Comment(by kriller): beresp.cacheable was removed in 3.0. test the value of beresp.ttl instead. ttl higher than 0 means cacheable. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 6 07:27:31 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 06 Jul 2011 07:27:31 -0000 Subject: [Varnish] #956: Value of obj.ttl in vcl_hit Message-ID: <044.2a08cb9c53d237bb5ca8919e3e5bfe1f@varnish-cache.org> #956: Value of obj.ttl in vcl_hit ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ On a server running squeeze with the package varnish.3.0.0-1~squeeze1 from varnish-cache.org debian repo. In the default vcl config file, I only modify vcl_hit with the following lines: {{{ import std; sub vcl_hit { std.log("Obj.ttl : " + obj.ttl); return (deliver); } }}} The manpage of vcl indicate that : '''obj.ttl''': ''The object's remaining time to live, in seconds. obj.ttl is writable. '' with varnish 2.1.5 this is the case but with varnish 3.0.0 the previous line display in the log the initial TTL. Is obj.ttl deprecated under varnish 3.0.0? Where can I access the value of the remaining TTL of an object? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 8 09:48:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 08 Jul 2011 09:48:11 -0000 Subject: [Varnish] #941: beresp.ttl not honred when set in vcl_fetch In-Reply-To: <042.621b2af1ec17465de36ac30afe14bc71@varnish-cache.org> References: <042.621b2af1ec17465de36ac30afe14bc71@varnish-cache.org> Message-ID: <051.3f65cd12a97d2009cbab4604c65deccf@varnish-cache.org> #941: beresp.ttl not honred when set in vcl_fetch --------------------+------------------------------------------------------- Reporter: david | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by Geoff Simmons ): (In [e1406a833de77d1088ea596c57749ebf4ad5a47b]) Resolves conflict between 90b7074b4cad090743f5a9797007ab448fa95a39 (fix #941) and experimental-ims experimental-ims needs left- and right-side macros/functions for updating timeouts in cache_vrt_var.c since stale_obj is read-only Conflicts: bin/varnishd/cache_vrt_var.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 07:50:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 07:50:45 -0000 Subject: [Varnish] #949: %b format gives wrong outbut for zero-size content In-Reply-To: <042.210d1826f0c6be0ec5841b5f6325035b@varnish-cache.org> References: <042.210d1826f0c6be0ec5841b5f6325035b@varnish-cache.org> Message-ID: <051.d98af2606adb3381aab82052c33f43ed@varnish-cache.org> #949: %b format gives wrong outbut for zero-size content ---------------------+------------------------------------------------------ Reporter: ljorg | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [fe7e315cb98ffdc2e4f510e43c7b54bc1af840c1]) Print 0, not - for zero- byte replies Fixes: #949 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 07:55:51 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 07:55:51 -0000 Subject: [Varnish] #947: varnishncsa dies on SIGHUP In-Reply-To: <042.abc7c4a4622a2fd6353b2c785d04e210@varnish-cache.org> References: <042.abc7c4a4622a2fd6353b2c785d04e210@varnish-cache.org> Message-ID: <051.45b6c1670e7c38d483e5f9be3d02d27a@varnish-cache.org> #947: varnishncsa dies on SIGHUP -------------------------+-------------------------------------------------- Reporter: ljorg | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [3a0d628c1e2dff4b7a15253739f7cecdff8ec19c]) Don't assert on sleep failure due to signals in VSL library (some utils expect to receive SIGHUP). Fixes: #947 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 08:44:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 08:44:10 -0000 Subject: [Varnish] #950: varnishncsa with %{X}x-parameters crashes on error 405 In-Reply-To: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> References: <042.0ece7f1c865735159bd1154f7f0fc076@varnish-cache.org> Message-ID: <051.6c0e68b0b9e1af550ad7dd5f20604033@varnish-cache.org> #950: varnishncsa with %{X}x-parameters crashes on error 405 -------------------------+-------------------------------------------------- Reporter: ljorg | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [c11ac805b50dcf77aac5d4ba3d210207924250bf]) Avoid segfaulting if hitmiss or handling hasn't been set yet Fall back to "-" if the handling has not been decided yet. Fixes: #950 Fixes: #944 Fixes: #918 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 08:44:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 08:44:10 -0000 Subject: [Varnish] #944: varnishncsa crash In-Reply-To: <043.9d9198dcc891ca943c00cd33918f2967@varnish-cache.org> References: <043.9d9198dcc891ca943c00cd33918f2967@varnish-cache.org> Message-ID: <052.931bb0f7633d77247af083d6989b92f0@varnish-cache.org> #944: varnishncsa crash -------------------------------+-------------------------------------------- Reporter: 191919 | Owner: tfheen Type: defect | Status: closed Priority: high | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: critical | Resolution: fixed Keywords: varnishncsa crash | -------------------------------+-------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [c11ac805b50dcf77aac5d4ba3d210207924250bf]) Avoid segfaulting if hitmiss or handling hasn't been set yet Fall back to "-" if the handling has not been decided yet. Fixes: #950 Fixes: #944 Fixes: #918 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 08:44:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 08:44:12 -0000 Subject: [Varnish] #918: Segfault in varnishncsa (3.0.0-beta1) In-Reply-To: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> References: <041.335050a3b64438d5a5f6c71c03dac3d4@varnish-cache.org> Message-ID: <050.a82a08b04b1ee833ff78f5fef68b75b8@varnish-cache.org> #918: Segfault in varnishncsa (3.0.0-beta1) -------------------------+-------------------------------------------------- Reporter: olli | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishncsa | Version: Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: reopened => closed * resolution: => fixed Comment: (In [c11ac805b50dcf77aac5d4ba3d210207924250bf]) Avoid segfaulting if hitmiss or handling hasn't been set yet Fall back to "-" if the handling has not been decided yet. Fixes: #950 Fixes: #944 Fixes: #918 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 08:49:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 08:49:05 -0000 Subject: [Varnish] #954: Varnish 3.0 breaks beresp.cacheable VCL syntax In-Reply-To: <043.f5cf6a574532e116664932074b978913@varnish-cache.org> References: <043.f5cf6a574532e116664932074b978913@varnish-cache.org> Message-ID: <052.d5ed29e218428f33b9359363eb99b4cf@varnish-cache.org> #954: Varnish 3.0 breaks beresp.cacheable VCL syntax ---------------------+------------------------------------------------------ Reporter: dfavor | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: The documentation for this was updated in: commit 91023bb8dca3d8dba6ec4799be4256fcef83ed12 Author: Per Buer Date: Wed Jun 29 23:14:22 2011 +0200 obj and beresp.cacheable are gone -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 10:11:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 10:11:00 -0000 Subject: [Varnish] #956: Value of obj.ttl in vcl_hit In-Reply-To: <044.2a08cb9c53d237bb5ca8919e3e5bfe1f@varnish-cache.org> References: <044.2a08cb9c53d237bb5ca8919e3e5bfe1f@varnish-cache.org> Message-ID: <053.f8d9fecc65a709745070bbceef85f4e9@varnish-cache.org> #956: Value of obj.ttl in vcl_hit ----------------------+----------------------------------------------------- Reporter: pmialon | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 10:27:57 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 10:27:57 -0000 Subject: [Varnish] #951: varnish stalls connections on high traffic to non-cacheable urls In-Reply-To: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> References: <041.b0e12d879eedb94a6deebe2f0af76fa7@varnish-cache.org> Message-ID: <050.3cb01db99e2b850432c953fefbd6c17c@varnish-cache.org> #951: varnish stalls connections on high traffic to non-cacheable urls ---------------------------------+------------------------------------------ Reporter: tttt | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: major Keywords: | ---------------------------------+------------------------------------------ Comment(by martin): Could you please provide some varnishlog data for a request that isn't stuck, but would be stuck later, if possible? This would allow us to see if anything is strange about these objects at that time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 10:34:24 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 10:34:24 -0000 Subject: [Varnish] #955: Redhat spec file still has 3.0.0 beta2 In-Reply-To: <048.c7dcd7eacda9e87c9d81fbba08d9a76e@varnish-cache.org> References: <048.c7dcd7eacda9e87c9d81fbba08d9a76e@varnish-cache.org> Message-ID: <057.603631ec9746e2d512b587d62252a557@varnish-cache.org> #955: Redhat spec file still has 3.0.0 beta2 -------------------------+-------------------------------------------------- Reporter: andreacampi | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 11 18:25:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Jul 2011 18:25:42 -0000 Subject: [Varnish] #957: Bug in varnishstat related to the -f option Message-ID: <044.e4232cd601fb5cee9f252bcdd1aa3d85@varnish-cache.org> #957: Bug in varnishstat related to the -f option ---------------------+------------------------------------------------------ Reporter: leed25d | Type: defect Status: new | Priority: normal Milestone: | Component: varnishstat Version: 3.0.0 | Severity: major Keywords: | ---------------------+------------------------------------------------------ We are running 3.0.0 Some of the new fields in varnishstat have commas {{{ (eg. VBE.production[43](172.21.4.107,,80).vcls VBE.production[43](172.21.4.107,,80).happycVBE.production[44](172.21.4.108,,80).vcls ...) }}} but the -f comand line option takes a comma separated list of field names to display. Escaping ',' and shell special characters (like '(' ) seems to be ignored. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 12 06:49:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Jul 2011 06:49:25 -0000 Subject: [Varnish] #958: Transient Storage memleak? Message-ID: <042.0d328ed4c5bf692db0b6192b0f39bfb1@varnish-cache.org> #958: Transient Storage memleak? ---------------------+------------------------------------------------------ Reporter: fdy84 | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: memleak | ---------------------+------------------------------------------------------ I set ?s malloc,4G but varnish eat all my mem(12G), and use swap! In varnishstat , I saw SMA.s0.nbytes is 4G is right, but SMA.Transient.nbytes is almost 6G! What is SMA.Transient and why it can?t be free? And how can I control transient storage size? {{{ SMA.s0.nreq 2343385 74.98 Allocator requests SMA.s0.nobj 353562 . Outstanding allocations SMA.s0.nbytes 4294967257 . Outstanding bytes SMA.s0.balloc 23949971661 . Bytes allocated SMA.s0.bfree 19655004404 . Bytes free SMA.Transient.nreq 600545 19.21 Allocator requests SMA.Transient.nobj 487027 . Outstanding allocations SMA.Transient.nbytes 6709806097 . Outstanding bytes SMA.Transient.balloc 9203517551 . Bytes allocated SMA.Transient.bfree 2493711454 . Bytes free }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 13 14:12:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Jul 2011 14:12:45 -0000 Subject: [Varnish] #959: Src packages don't compile on debian squeeze for varnish 3.0.0 Message-ID: <044.27558ba8ccd77cd0292e1020af9da81a@varnish-cache.org> #959: Src packages don't compile on debian squeeze for varnish 3.0.0 ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: blocker Keywords: | ---------------------+------------------------------------------------------ With an updated squeeze and following lines added at sources.list: {{{ deb-src http://repo.varnish-cache.org/debian/ squeeze varnish-3.0 }}} dpkg-buildpackage fails: {{{ # top TEST ./tests/g00003.vtc passed (0.534) **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/root/build/varnish-3.0.0/bin/varnishtest **** top 0.0 macro def topbuild=/root/build/varnish-3.0.0/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.2864.6c4a90d2 * top 0.0 TEST ./tests/m00000.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Test std vmod *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=28444 **** s1 0.0 macro def s1_sock=127.0.0.1 28444 * s1 0.0 Listen on 127.0.0.1 28444 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 28444 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.2864.6c4a90d2/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.2864.6c4a90d2/v1/_S -M '127.0.0.1 17279' -P /tmp/vtc.2864.6c4a90d2/v1/varnishd.pid -sfile,/tmp/vtc.2864.6c4a90d2/v1,10M *** v1 0.0 CMD: cd /root/build/varnish-3.0.0/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.2864.6c4a90d2/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.2864.6c4a90d2/v1/_S -M '127.0.0.1 17279' -P /tmp/vtc.2864.6c4a90d2/v1/varnishd.pid -sfile,/tmp/vtc.2864.6c4a90d2/v1,10M *** v1 0.0 PID: 9160 *** v1 0.0 debug| SMF.s0: filename: /tmp/vtc.2864.6c4a90d2/v1/varnish.CepO3i size 10 MB.\n *** v1 0.0 debug| Platform: Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 240 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 6 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| gljekwmubzhqyfdqmhlxzdinggbcfqvm\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 209693213d13775321f57c82bef150d931f7ff33d5712711c6d085d0f784913b\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 6 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| gljekwmubzhqyfdqmhlxzdinggbcfqvm\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 209693213d13775321f57c82bef150d931f7ff33d5712711c6d085d0f784913b\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "28444"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \timport std from "/root/build/varnish-3.0.0/bin/varnishtest/../../lib/libvmod_std/.libs/libvmod_std.so" ;\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_deliver {\n **** v1 0.1 CLI TX| \t\tset resp.http.foo = std.toupper(resp.http.foo);\n **** v1 0.1 CLI TX| \t\tset resp.http.bar = std.tolower(resp.http.bar);\n **** v1 0.1 CLI TX| \t\tset resp.http.who = std.author(phk);\n **** v1 0.1 CLI TX| \t\tstd.log("VCL initiated log");\n **** v1 0.1 CLI TX| \t\tstd.syslog(8 + 7, "Somebody runs varnishtest");\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| VCL compiled. **** v1 0.2 CLI TX| vcl.use vcl1 *** v1 0.2 CLI RX 200 ** v1 0.2 Start **** v1 0.2 CLI TX| start *** v1 0.3 debug| child (9249) Started\n *** v1 0.3 debug| Pushing vcls failed: CLI communication error (hdr)\n *** v1 0.3 CLI RX 200 **** v1 0.3 CLI TX| debug.xid 1000 *** v1 0.3 debug| Stopping Child\n *** v1 0.3 debug| Child (9249) died signal=6\n *** v1 0.3 debug| Child (9249) Panic message: Assert error in VRT_Vmod_Init(), cache_vrt_vmod.c line 86:\n *** v1 0.3 debug| Condition((v->hdl) != 0) not true.\n *** v1 0.3 debug| thread = (cache-main)\n *** v1 0.3 debug| ident = Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit,no_waiter\n *** v1 0.3 debug| Backtrace:\n *** v1 0.3 debug| 0x42d488: pan_ic+b8\n *** v1 0.3 debug| 0x43a194: VRT_Vmod_Init+2e4\n *** v1 0.3 debug| 0x2b938d102cc3: _end+2b938ca8d7cb\n *** v1 0.3 debug| 0x4338ed: ccf_config_load+1dd\n *** v1 0.3 debug| 0x2b93888c4f0e: _end+2b938824fa16\n *** v1 0.3 debug| 0x2b93888c53ed: _end+2b938824fef5\n *** v1 0.3 debug| 0x2b93888c81b1: _end+2b9388252cb9\n *** v1 0.3 debug| 0x2b93888c41... *** v1 0.3 CLI RX 101 **** v1 0.3 CLI RX| Unknown request in manager process (child not running).\n **** v1 0.3 CLI RX| Type 'help' for more info. ---- v1 0.3 CLI debug.xid command failed: 101 Unknown request in manager process (child not running). Type 'help' for more info. **** v1 0.3 CLI TX| debug.listen_address *** v1 0.4 CLI RX 101 **** v1 0.4 CLI RX| Unknown request in manager process (child not running).\n **** v1 0.4 CLI RX| Type 'help' for more info. * top 0.4 RESETTING after ./tests/m00000.vtc ** s1 0.4 Waiting for server **** s1 0.4 macro undef s1_addr **** s1 0.4 macro undef s1_port **** s1 0.4 macro undef s1_sock ** v1 1.4 Wait ** v1 1.4 R 9160 Status: 0000 * top 1.4 TEST ./tests/m00000.vtc FAILED # top TEST ./tests/m00000.vtc FAILED (1.372) }}} The same test don't pass with the latest git clone. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 13 14:23:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Jul 2011 14:23:58 -0000 Subject: [Varnish] #960: Test suite not working on a single cpu host on linux Message-ID: <044.245b526f140a9829b75db17f895978d1@varnish-cache.org> #960: Test suite not working on a single cpu host on linux ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ the following command will fail with a single CPU (KVM) under debian squeeze amd64 using latest git source. {{{ ./varnishtest -i -j3 ./tests/*.vtc [...] # top TEST ./tests/c00005.vtc passed (1.508) **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/root/varnish-cache/bin/varnishtest **** top 0.0 macro def topbuild=/root/varnish- cache/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.16778.497ee3c7 * top 0.0 TEST ./tests/c00002.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Check that all thread pools all get started and get minimum threads *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=32617 **** s1 0.0 macro def s1_sock=127.0.0.1 32617 * s1 0.0 Listen on 127.0.0.1 32617 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 32617 *** top 0.0 varnish ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.16778.497ee3c7/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.16778.497ee3c7/v1/_S -M '127.0.0.1 33876' -P /tmp/vtc.16778.497ee3c7/v1/varnishd.pid -sfile,/tmp/vtc.16778.497ee3c7/v1,10M -p thread_pool_min=2 -p thread_pool_max=8 -p thread_pools=4 -p thread_pool_purge_delay=10 *** v1 0.0 CMD: cd /root/varnish-cache/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.16778.497ee3c7/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.16778.497ee3c7/v1/_S -M '127.0.0.1 33876' -P /tmp/vtc.16778.497ee3c7/v1/varnishd.pid -sfile,/tmp/vtc.16778.497ee3c7/v1,10M -p thread_pool_min=2 -p thread_pool_max=8 -p thread_pools=4 -p thread_pool_purge_delay=10 *** v1 0.0 PID: 19068 *** v1 0.4 debug| SMF.s0: filename: /tmp/vtc.16778.497ee3c7/v1/varnish.0miJ86 size 10 MB.\n *** v1 0.4 debug| Platform: Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n *** v1 0.4 debug| 200 240 \n *** v1 0.4 debug| -----------------------------\n *** v1 0.4 debug| Varnish Cache CLI 1.0\n *** v1 0.4 debug| -----------------------------\n *** v1 0.4 debug| Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n *** v1 0.4 debug| \n *** v1 0.4 debug| Type 'help' for command list.\n *** v1 0.4 debug| Type 'quit' to close CLI session.\n *** v1 0.4 debug| Type 'start' to launch worker process.\n *** v1 0.4 debug| \n **** v1 0.5 CLIPOLL 1 0x1 0x0 *** v1 0.5 CLI connection fd = 6 *** v1 0.5 CLI RX 107 **** v1 0.5 CLI RX| jqvtgditfsvwtpgqgetgzowufuvulqaw\n **** v1 0.5 CLI RX| \n **** v1 0.5 CLI RX| Authentication required.\n **** v1 0.5 CLI TX| auth 1898c9f143fe0f2f1de712e99618a8147342f62ca0bc43bd617d5049ca5a0f48\n *** v1 0.5 CLI RX 200 **** v1 0.5 CLI RX| -----------------------------\n **** v1 0.5 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.5 CLI RX| -----------------------------\n **** v1 0.5 CLI RX| Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit\n **** v1 0.5 CLI RX| \n **** v1 0.5 CLI RX| Type 'help' for command list.\n **** v1 0.5 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.5 CLI RX| Type 'start' to launch worker process.\n **** v1 0.5 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.5 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "32617"; }\n **** v1 0.5 CLI TX| \n **** v1 0.5 CLI TX| \n **** v1 0.5 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 1.0 CLI RX 200 **** v1 1.0 CLI RX| VCL compiled. **** v1 1.0 CLI TX| vcl.use vcl1 *** v1 1.0 CLI RX 200 ** v1 1.0 Start **** v1 1.0 CLI TX| start *** v1 1.0 debug| child (19137) Started\n *** v1 1.0 CLI RX 200 **** v1 1.0 CLI TX| debug.xid 1000 *** v1 1.0 debug| Child (19137) said Child starts\n *** v1 1.0 debug| Child (19137) said SMF.s0 mmap'ed 10485760 bytes of 10485760\n *** v1 1.1 CLI RX 200 **** v1 1.1 CLI RX| XID is 1000 **** v1 1.1 CLI TX| debug.listen_address *** v1 1.1 CLI RX 200 **** v1 1.1 CLI RX| 127.0.0.1 42597\n ** v1 1.1 Listen on 127.0.0.1 42597 **** v1 1.1 macro def v1_addr=127.0.0.1 **** v1 1.1 macro def v1_port=42597 **** v1 1.1 macro def v1_sock=127.0.0.1 42597 *** top 1.1 client ** c1 1.1 Starting client ** c1 1.1 Waiting for client *** c1 1.1 Connect to 127.0.0.1 42597 *** c1 1.1 connected fd 9 from 127.0.0.1 60805 to 127.0.0.1 42597 *** c1 1.1 txreq **** c1 1.1 txreq| GET / HTTP/1.1\r\n **** c1 1.1 txreq| \r\n *** s1 1.1 accepted fd 4 *** s1 1.1 rxreq **** s1 1.1 rxhdr| GET / HTTP/1.1\r\n **** s1 1.1 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 1.1 rxhdr| X-Varnish: 1001\r\n **** s1 1.1 rxhdr| Accept-Encoding: gzip\r\n **** s1 1.1 rxhdr| Host: 127.0.0.1\r\n **** s1 1.1 rxhdr| \r\n **** s1 1.1 http[ 0] | GET **** s1 1.1 http[ 1] | / **** s1 1.1 http[ 2] | HTTP/1.1 **** s1 1.1 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 1.1 http[ 4] | X-Varnish: 1001 **** s1 1.1 http[ 5] | Accept-Encoding: gzip **** s1 1.1 http[ 6] | Host: 127.0.0.1 **** s1 1.1 bodylen = 0 *** s1 1.1 txresp **** s1 1.1 txresp| HTTP/1.1 200 Ok\r\n **** s1 1.1 txresp| Connection: close\r\n **** s1 1.1 txresp| Content-Length: 7\r\n **** s1 1.1 txresp| \r\n **** s1 1.1 txresp| 012345\n *** s1 1.1 shutting fd 4 ** s1 1.1 Ending *** c1 1.1 rxresp **** c1 1.1 rxhdr| HTTP/1.1 200 Ok\r\n **** c1 1.1 rxhdr| Content-Length: 7\r\n **** c1 1.1 rxhdr| Accept-Ranges: bytes\r\n **** c1 1.1 rxhdr| Date: Wed, 13 Jul 2011 14:22:52 GMT\r\n **** c1 1.1 rxhdr| X-Varnish: 1001\r\n **** c1 1.1 rxhdr| Age: 0\r\n **** c1 1.1 rxhdr| Via: 1.1 varnish\r\n **** c1 1.1 rxhdr| Connection: keep-alive\r\n **** c1 1.1 rxhdr| \r\n **** c1 1.1 http[ 0] | HTTP/1.1 **** c1 1.1 http[ 1] | 200 **** c1 1.1 http[ 2] | Ok **** c1 1.1 http[ 3] | Content-Length: 7 **** c1 1.1 http[ 4] | Accept-Ranges: bytes **** c1 1.1 http[ 5] | Date: Wed, 13 Jul 2011 14:22:52 GMT **** c1 1.1 http[ 6] | X-Varnish: 1001 **** c1 1.1 http[ 7] | Age: 0 **** c1 1.1 http[ 8] | Via: 1.1 varnish **** c1 1.1 http[ 9] | Connection: keep-alive **** c1 1.1 body| 012345\n **** c1 1.1 bodylen = 7 *** c1 1.1 expect **** c1 1.1 EXPECT resp.status (200) == 200 (200) match *** c1 1.1 closing fd 9 ** c1 1.1 Ending *** top 1.1 varnish ---- v1 2.1 Not true: n_wrk (14) == 8 (8) * top 2.1 RESETTING after ./tests/c00002.vtc ** s1 2.1 Waiting for server **** s1 2.1 macro undef s1_addr **** s1 2.1 macro undef s1_port **** s1 2.1 macro undef s1_sock ** v1 3.1 Wait ** v1 3.1 R 19068 Status: 0000 * top 3.1 TEST ./tests/c00002.vtc FAILED # top TEST ./tests/c00002.vtc FAILED (3.112) }}} but if we launch : {{{ ./varnishtest -i ./tests/*.vtc }}} The suite test pass. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 14 15:37:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Jul 2011 15:37:32 -0000 Subject: [Varnish] #961: Parameter parsing bug in esi include. Message-ID: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> #961: Parameter parsing bug in esi include. -----------------------+---------------------------------------------------- Reporter: dharrigan | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: major Keywords: esi | -----------------------+---------------------------------------------------- Hello, We are using esi includes to replace content in our pages. We seem to have come across a bug when the esi include (src) contains parameters: i.e., we have three esi tags on one page: {{{ }}} When I tail the varnishlog using this command: {{{ varnishlog -i TxUrl }}} I see this in the log: {{{ 13 BackendOpen b default 127.0.0.1 59363 127.0.0.1 8080 13 TxURL b /article/6573/style/1?position=0 13 BackendReuse b default 13 BackendClose b default 13 BackendOpen b default 127.0.0.1 59365 127.0.0.1 8080 13 TxURL b /article/6573/style/2?position=1&e/1?position=0 13 BackendReuse b default 13 BackendClose b default 13 BackendOpen b default 127.0.0.1 59367 127.0.0.1 8080 13 TxURL b /article/6573/style/3?position=2&s=Y }}} This breaks our functionality of passing parameters back into the system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 09:56:18 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 09:56:18 -0000 Subject: [Varnish] #949: %b format gives wrong outbut for zero-size content In-Reply-To: <042.210d1826f0c6be0ec5841b5f6325035b@varnish-cache.org> References: <042.210d1826f0c6be0ec5841b5f6325035b@varnish-cache.org> Message-ID: <051.23d6960a62e8a5624e459613bcde2490@varnish-cache.org> #949: %b format gives wrong outbut for zero-size content ---------------------+------------------------------------------------------ Reporter: ljorg | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by Tollef Fog Heen ): (In [61b0dcfb45c972c9319a7208c1aa4a308710568b]) Revert "Print 0, not - for zero-byte replies" "-" is correct according to the Apache LogFormat documentation on http://httpd.apache.org/docs/current/mod/mod_log_config.html This reverts commit fe7e315cb98ffdc2e4f510e43c7b54bc1af840c1. See #949 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 10:19:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 10:19:32 -0000 Subject: [Varnish] #959: Src packages don't compile on debian squeeze for varnish 3.0.0 In-Reply-To: <044.27558ba8ccd77cd0292e1020af9da81a@varnish-cache.org> References: <044.27558ba8ccd77cd0292e1020af9da81a@varnish-cache.org> Message-ID: <053.fdf1341fff57eecce4fb6681340cc5ff@varnish-cache.org> #959: Src packages don't compile on debian squeeze for varnish 3.0.0 ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: blocker Keywords: | ---------------------+------------------------------------------------------ Comment(by tfheen): This works fine for me, have you done anything odd like mounted /var or /tmp noexec? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 10:21:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 10:21:35 -0000 Subject: [Varnish] #955: Redhat spec file still has 3.0.0 beta2 In-Reply-To: <048.c7dcd7eacda9e87c9d81fbba08d9a76e@varnish-cache.org> References: <048.c7dcd7eacda9e87c9d81fbba08d9a76e@varnish-cache.org> Message-ID: <057.cd7808550f0ec80f8c4066b02478e67b@varnish-cache.org> #955: Redhat spec file still has 3.0.0 beta2 -------------------------+-------------------------------------------------- Reporter: andreacampi | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [2061b6e21ee799aeed9091d80c9f8397fece1b81]) Adjust paths in spec file for trunk builds Switch back from beta2 to trunk meaning RPMs can be built directly from the tarballs again. Fixes: #955 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 10:24:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 10:24:56 -0000 Subject: [Varnish] #939: Error 400 if a single header exceeds 2048 characters In-Reply-To: <042.040f5d1e4f9b5d1da3859fd4e9ea4778@varnish-cache.org> References: <042.040f5d1e4f9b5d1da3859fd4e9ea4778@varnish-cache.org> Message-ID: <051.db3b2dfcf7f750decdee6c6c392a5f92@varnish-cache.org> #939: Error 400 if a single header exceeds 2048 characters -------------------+-------------------------------------------------------- Reporter: david | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by Tollef Fog Heen ): (In [d7c7c39abd8c56a7bce04991c7a8c35b58940dca]) Increase http_resp_hdr_len and http_req_hdr_len We're seeing at least up to 4k in the wild, so increase the limit somewhat. See: #939 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 10:36:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 10:36:15 -0000 Subject: [Varnish] #959: Src packages don't compile on debian squeeze for varnish 3.0.0 In-Reply-To: <044.27558ba8ccd77cd0292e1020af9da81a@varnish-cache.org> References: <044.27558ba8ccd77cd0292e1020af9da81a@varnish-cache.org> Message-ID: <053.542c735d135c8fb08720d250b13811e4@varnish-cache.org> #959: Src packages don't compile on debian squeeze for varnish 3.0.0 ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: blocker Keywords: | ---------------------+------------------------------------------------------ Comment(by pmialon): Replying to [comment:1 tfheen]: > This works fine for me, have you done anything odd like mounted /var or /tmp noexec? no nothing, I have tried on a freshly build vm and on a dedicated server. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 15 11:02:25 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Jul 2011 11:02:25 -0000 Subject: [Varnish] #962: Persistent storage don't work on Linux with Address space layout randomization Message-ID: <044.84a8ca3ebbf5734f4d5e6e14f868313f@varnish-cache.org> #962: Persistent storage don't work on Linux with Address space layout randomization ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Debian Squeeze, Fedora 15 and RHEL 6 uses Adress space layout randomization by default: {{{ # sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 }}} This breaks persistent storage: {{{ # varnishd -d -a :80 -f /etc/varnish/default.vcl -s persistent,/var/lib/varnish/instance/A.shm,10M ... CHK(0x7fbfcc1330a0 SILO 0x7fbfcb0e1000 SILO) = 3 ... Platform: Linux,2.6.32-5-amd64,x86_64,-spersistent,-smalloc,-hcritbit ... }}} By disabling ASLR (sysctl kernel.randomize_va_space=0), it works again. In source:bin/varnishd/storage_persistent_mgt.c, smp_mgt_init(): {{{ sc->base = mmap(NULL, sc->mediasize, PROT_READ|PROT_WRITE, MAP_NOCORE | MAP_NOSYNC | MAP_SHARED, sc->fd, 0); ... smp_def_sign(sc, &sc->idn, 0, "SILO"); ... i = smp_valid_silo(sc); }}} mmap(2) may return a random address. This address is stored in sc->idn->ss and written to the mmap()'d file in smp_reset_sign(): {{{ ctx->ss->mapped = (uintptr_t)ctx->ss; }}} This is ok with the very first run because the file is created and the mmap address stored. But with following run, smp_valid_silo() calls smp_chk_sign() (source:bin/varnishd/storage_persistent_subr.c) which compares addresses from mmap(2) and the file: {{{ if ((uintptr_t)ctx->ss != ctx->ss->mapped) r = 3 }}} This causes the silo to be reset. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 09:33:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 09:33:43 -0000 Subject: [Varnish] #961: Parameter parsing bug in esi include. In-Reply-To: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> References: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> Message-ID: <055.194a20b394b952659c195852146938d3@varnish-cache.org> #961: Parameter parsing bug in esi include. -----------------------+---------------------------------------------------- Reporter: dharrigan | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: major Keywords: esi | -----------------------+---------------------------------------------------- Comment(by dharrigan): Just tested this patch against varnish 3 (rebuilt the lucid deb package with the patch applied) and I'm pleased to report the patch works. I'm now getting this output: {{{ TxURL b /article/6573/style/2?position=1&headline=head%20line%202&previewText=preview%20text%202&showPreviewLinks=Y }}} Hope the patch can make it into the next point release :-) Big thanks to Scoof for the quick fix :-) -=david= -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:22:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:22:00 -0000 Subject: [Varnish] #960: Test suite not working on a single cpu host on linux In-Reply-To: <044.245b526f140a9829b75db17f895978d1@varnish-cache.org> References: <044.245b526f140a9829b75db17f895978d1@varnish-cache.org> Message-ID: <053.53be3a94275cdc0d57c18b09ebcaea2d@varnish-cache.org> #960: Test suite not working on a single cpu host on linux ---------------------+------------------------------------------------------ Reporter: pmialon | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:25:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:25:35 -0000 Subject: [Varnish] #957: Bug in varnishstat related to the -f option In-Reply-To: <044.e4232cd601fb5cee9f252bcdd1aa3d85@varnish-cache.org> References: <044.e4232cd601fb5cee9f252bcdd1aa3d85@varnish-cache.org> Message-ID: <053.7eeefd91bfaf09d62426b5679e7ce9bb@varnish-cache.org> #957: Bug in varnishstat related to the -f option -------------------------+-------------------------------------------------- Reporter: leed25d | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: 3.0.0 Severity: major | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:28:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:28:37 -0000 Subject: [Varnish] #961: Parameter parsing bug in esi include. In-Reply-To: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> References: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> Message-ID: <055.91871591dbfc7b604c5360e3c058b90d@varnish-cache.org> #961: Parameter parsing bug in esi include. -----------------------+---------------------------------------------------- Reporter: dharrigan | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.0 Severity: major | Keywords: esi -----------------------+---------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: I'll look at this when I get a moment. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:29:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:29:06 -0000 Subject: [Varnish] #962: Persistent storage don't work on Linux with Address space layout randomization In-Reply-To: <044.84a8ca3ebbf5734f4d5e6e14f868313f@varnish-cache.org> References: <044.84a8ca3ebbf5734f4d5e6e14f868313f@varnish-cache.org> Message-ID: <053.9f58d2b4fdc49edf001d5365596c269a@varnish-cache.org> #962: Persistent storage don't work on Linux with Address space layout randomization ----------------------+----------------------------------------------------- Reporter: pmialon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: I need to add some code which attempts to remap to right address for this (and other cases) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:30:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:30:07 -0000 Subject: [Varnish] #958: Transient Storage memleak? In-Reply-To: <042.0d328ed4c5bf692db0b6192b0f39bfb1@varnish-cache.org> References: <042.0d328ed4c5bf692db0b6192b0f39bfb1@varnish-cache.org> Message-ID: <051.85e08c14e6f4b6f239875847302dae7f@varnish-cache.org> #958: Transient Storage memleak? ----------------------+----------------------------------------------------- Reporter: fdy84 | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: memleak ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk Comment: I'll try to hunt this down. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:30:40 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:30:40 -0000 Subject: [Varnish] #953: Leak in the TransientStorage? In-Reply-To: <043.d411d994202d179d7348bd87ecffbaea@varnish-cache.org> References: <043.d411d994202d179d7348bd87ecffbaea@varnish-cache.org> Message-ID: <052.c4b4fcac8937567b8de337ad28da166d@varnish-cache.org> #953: Leak in the TransientStorage? ----------------------+----------------------------------------------------- Reporter: elurin | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: Looks like dup with #958. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 10:35:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 10:35:37 -0000 Subject: [Varnish] #939: Error 400 if a single header exceeds 2048 characters In-Reply-To: <042.040f5d1e4f9b5d1da3859fd4e9ea4778@varnish-cache.org> References: <042.040f5d1e4f9b5d1da3859fd4e9ea4778@varnish-cache.org> Message-ID: <051.2fb9729572bd2a3f13f80087ca77456f@varnish-cache.org> #939: Error 400 if a single header exceeds 2048 characters -------------------+-------------------------------------------------------- Reporter: david | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by phk): Per discussions on the httpbis WG I have changed the reponse code to 413 instead of 400. The limit has been raised to 4k. I belive the ticket can be closed now ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 14:25:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 14:25:35 -0000 Subject: [Varnish] #961: Parameter parsing bug in esi include. In-Reply-To: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> References: <046.cd516cdc50585cef7ae27755521994f0@varnish-cache.org> Message-ID: <055.f217de5fc0f6a4ca62ee6048ff827f99@varnish-cache.org> #961: Parameter parsing bug in esi include. -----------------------+---------------------------------------------------- Reporter: dharrigan | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.0 Severity: major | Resolution: fixed Keywords: esi | -----------------------+---------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [4172f9888077d42d8c0148a353d6940764d46154]) Fix a bug in the entity- replacement code in the ESI-parser. Patch by: scoof Fixes #961 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 18 19:03:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Jul 2011 19:03:34 -0000 Subject: [Varnish] #957: Bug in varnishstat related to the -f option In-Reply-To: <044.e4232cd601fb5cee9f252bcdd1aa3d85@varnish-cache.org> References: <044.e4232cd601fb5cee9f252bcdd1aa3d85@varnish-cache.org> Message-ID: <053.826bf864ebbc4687aaa8355ed093158f@varnish-cache.org> #957: Bug in varnishstat related to the -f option -------------------------+-------------------------------------------------- Reporter: leed25d | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: 3.0.0 Severity: major | Keywords: -------------------------+-------------------------------------------------- Comment(by scoof): varnishstat is able to parse commas and parenthesis properly if you quote them: '"VBE.default(127.0.0.1,,8080).vcls"' But this doesn't solve the issue, since it splits the name into class/ident/name on . (vsc_sf_arg in lib/libvarnishapi/vsc.c) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 19 11:36:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jul 2011 11:36:36 -0000 Subject: [Varnish] #963: hsh_rush not waking exponentially Message-ID: <043.b65620d53d58410fe9c4b705207dd9eb@varnish-cache.org> #963: hsh_rush not waking exponentially --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- In Varnish 3.0 (also tested against trunk) hsh_rush fails to wake exponentially. When an object is unbusied, only rush_exponent sessions are woken, but these sessions never wakes any additional sessions on the waitinglist. See attached varnishtest file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 19 16:04:39 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jul 2011 16:04:39 -0000 Subject: [Varnish] #964: varnish is loosing session data Message-ID: <047.f73ad54aee10de8567510bfb13271915@varnish-cache.org> #964: varnish is loosing session data ------------------------+--------------------------------------------------- Reporter: pravenjohn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: critical Keywords: | ------------------------+--------------------------------------------------- I've setup a varnish server (3.0) with an apache-tomcat server on the backend... My default.vcl is backend ige_static1 { .host = "XXXXXXX"; .port = "80"; .connect_timeout = 600s; .first_byte_timeout = 600s; .between_bytes_timeout = 600s; } backend ige_dynamic { .host = "XXXXXX"; .port = "80"; .connect_timeout = 600s; .first_byte_timeout = 600s; .between_bytes_timeout = 600s; } sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } ban(req.url == req.url); error 200 "Purging Done"; } if (req.request == "POST") { return(pipe); } if (req.url ~ "^/portal|^/saml") { set req.backend = ige_dynamic; return(pass); } set req.backend = ige_static1; return(lookup); } sub vcl_fetch { if (req.url ~ "\.(png|gif|jpg|swf|css|js|html|txt|pdf)$") { unset beresp.http.set-cookie; } } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } sub vcl_hit { if (req.request == "PURGE") { ban (req.url == req.url); error 200 "Purged."; } } sub vcl_miss { if (req.request == "PURGE") { ban (req.url == req.url); error 200 "Not in cache"; } } sub vcl_pipe { set bereq.http.connection = "close"; } But for some reason, I seem to be loosing Java session dat along the way. I set some data on the JAVA side, and after 2-3 pages interaction, the data disappears... I checked the same againist my backend apache-tomcat server and it works fine over there... Any suggestions you can provide would be great... Unless we can fix this issue, we'll probably have to migrate out to some other caching solution... Regards Praven John -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 19 16:42:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 19 Jul 2011 16:42:07 -0000 Subject: [Varnish] #964: varnish is loosing session data In-Reply-To: <047.f73ad54aee10de8567510bfb13271915@varnish-cache.org> References: <047.f73ad54aee10de8567510bfb13271915@varnish-cache.org> Message-ID: <056.9d414267041c560e4f01850e23aeb464@varnish-cache.org> #964: varnish is loosing session data ------------------------+--------------------------------------------------- Reporter: pravenjohn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: critical Keywords: | ------------------------+--------------------------------------------------- Comment(by pravenjohn): Please note, we seem to be passing a LOT of data via session, when this error arises. Could that be the porblem? Is there a way to increase the amount of session data, varnish can pass to the backend? Praven -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 20 16:31:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jul 2011 16:31:13 -0000 Subject: [Varnish] #964: varnish is loosing session data In-Reply-To: <047.f73ad54aee10de8567510bfb13271915@varnish-cache.org> References: <047.f73ad54aee10de8567510bfb13271915@varnish-cache.org> Message-ID: <056.ea37c7d0565e83d3642ffaaeacfbbbbd@varnish-cache.org> #964: varnish is loosing session data ------------------------+--------------------------------------------------- Reporter: pravenjohn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: critical Keywords: | ------------------------+--------------------------------------------------- Comment(by pravenjohn): we seem to have got a work around for the time being... removing- if (req.request == "POST") { return(pipe); } sub vcl_pipe { set bereq.http.connection = "close"; } Seems to have solved the issue for now... Was the waay I configured it wrong? or is this a bug with the pipe? Praven -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 20 22:49:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Jul 2011 22:49:09 -0000 Subject: [Varnish] #965: Restarting a request in vcl_miss causes Varnish client crash. Message-ID: <042.7a34951b806a6025ec80b0b6379c27a4@varnish-cache.org> #965: Restarting a request in vcl_miss causes Varnish client crash. -------------------+-------------------------------------------------------- Reporter: david | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Hello! I've done extensive testing on this, and I believe I've found a bug in Varnish. The VCL below loads correctly, but causes the Varnish client to crash after 1-2 requests. The backstory is available in the forums here https://www.varnish-cache.org/forum/topic/65 - if you have any questions that are not answered in that post, please ask away; I'd love to explain and make more sense of what I'm trying to do. This isn't the exact VCL I'd use in production, it is a minimalistic version that is able to reproduce the crash: sub vcl_recv { if (!req.http.X-Forwarded-For) { set req.http.X-Forwarded-For = client.ip; } if (req.http.X-Banned == "check") { remove req.http.X-Banned; } elseif (req.restarts == 0) { set req.http.X-Banned = "check"; return (lookup); } } sub vcl_hash { ## Check if they have a ban in the cache, or if they are going to be banned in cache. if (req.http.X-Banned) { hash_data(req.http.X-Forwarded-For); return (hash); } } sub vcl_error { if (obj.status == 988) { return (restart); } } sub vcl_miss { if (req.http.X-Banned == "check") { error 988 "restarting"; } } This is a successful request. After this request, the second request will not work (Varnish restarts): 0 Debug - "VCL_error(988, restarting)" 9 BackendOpen b production[47] 172.21.4.182 41813 172.21.4.111 80 9 TxRequest b GET 9 TxURL b http://www.site.com/ 9 TxProtocol b HTTP/1.1 9 TxHeader b User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 9 TxHeader b Host: www.site.com 9 TxHeader b Accept: */* 9 TxHeader b Proxy-Connection: Keep-Alive 9 TxHeader b X-Forwarded-For: 127.0.0.1 9 TxHeader b X-Varnish: 746583022 9 TxHeader b Accept-Encoding: gzip 9 RxProtocol b HTTP/1.1 9 RxStatus b 200 9 RxResponse b OK 9 RxHeader b Date: Thu, 16 Jun 2011 23:45:54 GMT 9 RxHeader b Server: Apache/2.2.3 (CentOS) 9 RxHeader b Cache-Control: private, proxy-revalidate 9 RxHeader b ETag: "9658bc1e80033b21277323e725948c91" 9 RxHeader b Content-Encoding: gzip 9 RxHeader b Vary: Accept-Encoding 9 RxHeader b Content-length: 11452 9 RxHeader b Content-Type: text/html; charset=utf-8 9 RxHeader b Content-Language: en 9 Fetch_Body b 4 0 1 9 Length b 11452 9 BackendReuse b production[47] 3 SessionOpen c 127.0.0.1 1204 :80 3 ReqStart c 127.0.0.1 1204 746583022 3 RxRequest c HEAD 3 RxURL c http://www.site.com/ 3 RxProtocol c HTTP/1.1 3 RxHeader c User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 3 RxHeader c Host: www.site.com 3 RxHeader c Accept: */* 3 RxHeader c Proxy-Connection: Keep-Alive 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c 127.0.0.1 3 VCL_return c hash 3 VCL_call c miss error 3 VCL_call c error restart 3 VCL_call c recv lookup 3 VCL_call c hash 3 Hash c http://www.site.com/ 3 Hash c www.site.com 3 VCL_return c hash 3 VCL_call c miss fetch 3 Backend c 9 production production[47] 3 TTL c 746583022 RFC 300 1308267955 0 0 0 0 3 VCL_call c fetch deliver 3 ObjProtocol c HTTP/1.1 3 ObjResponse c OK 3 ObjHeader c Date: Thu, 16 Jun 2011 23:45:54 GMT 3 ObjHeader c Server: Apache/2.2.3 (CentOS) 3 ObjHeader c Cache-Control: private, proxy-revalidate 3 ObjHeader c ETag: "9658bc1e80033b21277323e725948c91" 3 ObjHeader c Content-Encoding: gzip 3 ObjHeader c Vary: Accept-Encoding 3 ObjHeader c Content-Type: text/html; charset=utf-8 3 ObjHeader c Content-Language: en 3 Gzip c u F - 11452 46817 80 80 91551 3 VCL_call c deliver deliver 3 TxProtocol c HTTP/1.1 3 TxStatus c 200 3 TxResponse c OK 3 TxHeader c Server: Apache/2.2.3 (CentOS) 3 TxHeader c Cache-Control: private, proxy-revalidate 3 TxHeader c ETag: "9658bc1e80033b21277323e725948c91" 3 TxHeader c Vary: Accept-Encoding 3 TxHeader c Content-Type: text/html; charset=utf-8 3 TxHeader c Content-Language: en 3 TxHeader c Date: Thu, 16 Jun 2011 23:45:54 GMT 3 TxHeader c X-Varnish: 746583022 3 TxHeader c Age: 0 3 TxHeader c Via: 1.1 varnish 3 TxHeader c Connection: keep-alive 3 Length c 0 3 ReqEnd c 746583022 1308267954.333659887 1308267954.527986050 0.000048876 0.194267035 0.000059128 3 Debug c herding 3 SessionClose c no request 3 StatSess c 127.0.0.1 1204 0 1 1 0 0 1 344 0 0 Backend_health - production[33] Still healthy ------- 4 3 8 0.000000 0.000272 3 SessionOpen c 172.21.4.16 57711 :80 3 SessionClose c EOF Regards, -david -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 22 07:16:16 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Jul 2011 07:16:16 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> References: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> Message-ID: <054.88491374b32c87b139eed6ff121331a9@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu ----------------------+----------------------------------------------------- Reporter: askalski | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: sess_mem leak n_sess race condition ----------------------+----------------------------------------------------- Comment(by abienvenu): I run a website serving one million pages per day, and I noticed "N struct sess" grows steadily, day after day, when Varnish 2.1.5 runs on an hyperthreaded server. The memory leak was about 200MB per day. See this memory usage graph from cacti (I restarted Varnish on July 12th). [[Image(http://data.imagup.com/10/1125983924.png)]] From the previous patch of askalski, I made a patch for Varnish 2.1.5, and it works perfectly well. I would really like these patches to make their path through the official Varnish releases. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 22 12:22:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Jul 2011 12:22:20 -0000 Subject: [Varnish] #966: Varnish Header Message-ID: <045.a09638ec6a9784d78e37f64576048f44@varnish-cache.org> #966: Varnish Header ----------------------+----------------------------------------------------- Reporter: frozts91 | Type: defect Status: new | Priority: highest Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Hello. i have a problem with varnish. in my server, sometimes one of thread varnish in my server use 100% load. how can i fix this? it looks like when recycling the threads, it looping without end. second, in my server, i have varnish and nginx installed. but there was a problem. when i upload a file it always show bad gateway 502, i check it from log, it says recv() failed (104: Connection reset by peer) while reading response from headers. it looks like varnish change the headers, how to set varnish not change the headers? thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 22 19:19:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 22 Jul 2011 19:19:46 -0000 Subject: [Varnish] #848: varnishlog -r seems broken In-Reply-To: <042.f4d125bf7db6e317d56c6e53ae887681@varnish-cache.org> References: <042.f4d125bf7db6e317d56c6e53ae887681@varnish-cache.org> Message-ID: <051.0ae6f1e9040ec45e9fc7474906451569@varnish-cache.org> #848: varnishlog -r seems broken ------------------------+--------------------------------------------------- Reporter: perbu | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: varnishlog ------------------------+--------------------------------------------------- Comment(by dbaker): Is there any additional info I can provide on this problem? It is causing a fair bit of hurt for me to not work. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 25 13:26:05 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 25 Jul 2011 13:26:05 -0000 Subject: [Varnish] #967: Assert error in object_cmp(), cache_expire.c line 449: Condition((bb) != NULL) not true. thread = (cache-timeout) Message-ID: <044.1798b199401153df82dd03112e822cf1@varnish-cache.org> #967: Assert error in object_cmp(), cache_expire.c line 449: Condition((bb) != NULL) not true. thread = (cache-timeout) ---------------------+------------------------------------------------------ Reporter: pmialon | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: | ---------------------+------------------------------------------------------ This panic occurred with approximately 17M of objects in cache. We experimented it on three different servers, they all run Debian 6.0 with debian package of varnish from repo.varnish-cache.org. {{{ Last panic at: Wed, 20 Jul 2011 19:03:06 GMT Assert error in object_cmp(), cache_expire.c line 449: Condition((bb) != NULL) not true. thread = (cache-timeout) ident = Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: /usr/sbin/varnishd() bin/varnishd/cache_panic.c:273 pan_backtrace /usr/sbin/varnishd() bin/varnishd/cache_expire.c:378 object_cmp /usr/lib/libvarnish.so.1 lib/libvarnish/binary_heap.c:269 binheap_trickledown /usr/lib/libvarnish.so.1 lib/libvarnish/binary_heap.c:370 binheap_delete /usr/sbin/varnishd() bin/varnishd/cache_expire.c:281 exp_timer /usr/sbin/varnishd() bin/varnishd/cache_pool.c:574 wrk_bgthread /lib/libpthread.so.0(+0x68ba) [0x7fa33062f8ba] /lib/libc.so.6(clone+0x6d) [0x7fa32fefd02d] }}} We obtain the address with a recompiled package that didn't strip the binary and addr2line. We have exactly the same error using varnish 2.1 and 3.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 26 18:44:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 26 Jul 2011 18:44:55 -0000 Subject: [Varnish] #968: "Resource temporarily unavailable" error when backend responds with Transfer-Encoding: chunked Message-ID: <041.a50a0a6d6d797e6900b6e7fc153284ff@varnish-cache.org> #968: "Resource temporarily unavailable" error when backend responds with Transfer-Encoding: chunked ------------------------------------------------+--------------------------- Reporter: sctb | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: chunked hang transfer-encoding 503 | ------------------------------------------------+--------------------------- Here the varnishlog output from a session that exhibits this problem: {{{ 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705005 1.0 14 BackendOpen b default 127.0.0.1 54918 127.0.0.1 8000 14 TxRequest b POST 14 TxURL b /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 14 TxProtocol b HTTP/1.1 14 TxHeader b content-length: 103 14 TxHeader b X-Forwarded-For: 68.145.230.90 14 TxHeader b X-Varnish: 1688028143 14 TxHeader b Host: 127.0.0.1 14 RxProtocol b HTTP/1.1 14 RxStatus b 200 14 RxResponse b OK 14 RxHeader b Connection: keep-alive 14 RxHeader b Transfer-Encoding: chunked 14 Fetch_Body b 3 0 1 14 Length b 40 14 BackendReuse b default 13 SessionOpen c 68.145.230.90 58615 0.0.0.0:8001 13 ReqStart c 68.145.230.90 58615 1688028143 13 RxRequest c POST 13 RxURL c /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 13 RxProtocol c HTTP/1.1 13 RxHeader c content-length: 103 13 RxHeader c Connection: close 13 VCL_call c recv pass 13 VCL_call c hash 13 Hash c /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 13 Hash c 10.97.29.183 13 VCL_return c hash 13 VCL_call c pass pass 13 Backend c 14 default default 13 TTL c 1688028143 RFC 120 1311705007 0 0 0 0 13 VCL_call c fetch hit_for_pass 13 ObjProtocol c HTTP/1.1 13 ObjResponse c OK 13 VCL_call c deliver deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 200 13 TxResponse c OK 13 TxHeader c Content-Length: 40 13 TxHeader c Accept-Ranges: bytes 13 TxHeader c Date: Tue, 26 Jul 2011 18:30:07 GMT 13 TxHeader c X-Varnish: 1688028143 13 TxHeader c Age: 0 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: close 13 Length c 40 13 ReqEnd c 1688028143 1311705007.461123228 1311705007.468569756 0.000087023 0.007403135 0.000043392 13 SessionClose c Connection: close 13 StatSess c 68.145.230.90 58615 0 1 1 0 1 1 166 40 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705008 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705011 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705014 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705017 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705020 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705023 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705026 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705029 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705032 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705035 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705038 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705041 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705044 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705047 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705050 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705053 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705056 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705059 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705062 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705065 1.0 14 TxRequest b POST 14 TxURL b /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 14 TxProtocol b HTTP/1.1 14 TxHeader b content-length: 66 14 TxHeader b X-Forwarded-For: 68.145.230.90 14 TxHeader b X-Varnish: 1688028144 14 TxHeader b Host: 127.0.0.1 14 BackendClose b default 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705068 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705071 1.0 14 BackendOpen b default 127.0.0.1 57673 127.0.0.1 8000 14 TxRequest b POST 14 TxURL b /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 14 TxProtocol b HTTP/1.1 14 TxHeader b content-length: 66 14 TxHeader b X-Forwarded-For: 68.145.230.90 14 TxHeader b X-Varnish: 1688028144 14 TxHeader b Host: 127.0.0.1 14 BackendClose b default 13 SessionOpen c 68.145.230.90 58616 0.0.0.0:8001 13 ReqStart c 68.145.230.90 58616 1688028144 13 RxRequest c POST 13 RxURL c /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 13 RxProtocol c HTTP/1.1 13 RxHeader c content-length: 66 13 RxHeader c Connection: close 13 VCL_call c recv pass 13 VCL_call c hash 13 Hash c /simplest- calc?bkey=247004fee56c9473094474859361c37c9053264a 13 Hash c 10.97.29.183 13 VCL_return c hash 13 VCL_call c pass pass 13 Backend c 14 default default 13 FetchError c http first read error: -1 11 (Resource temporarily unavailable) 13 Backend c 14 default default 13 FetchError c backend write error: 11 (Resource temporarily unavailable) 13 VCL_call c error deliver 13 VCL_call c deliver deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 503 13 TxResponse c Service Unavailable 13 TxHeader c Server: Varnish 13 TxHeader c Content-Type: text/html; charset=utf-8 13 TxHeader c Retry-After: 5 13 TxHeader c Content-Length: 419 13 TxHeader c Accept-Ranges: bytes 13 TxHeader c Date: Tue, 26 Jul 2011 18:31:12 GMT 13 TxHeader c X-Varnish: 1688028144 13 TxHeader c Age: 65 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: close 13 Length c 419 13 ReqEnd c 1688028144 1311705007.643313646 1311705072.642966986 0.000086546 64.999594212 0.000059128 13 SessionClose c error 13 StatSess c 68.145.230.90 58616 65 1 1 0 1 0 258 419 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1311705074 1.0 0 CLI - Rd ping }}} If I configure the backend to set Content-Length rather than Transfer-Encoding, the request is served as expected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 27 15:05:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Jul 2011 15:05:20 -0000 Subject: [Varnish] #969: init.d stop() function improvement Message-ID: <048.1a4b58ae1889d78fdbc19c4917c74b3a@varnish-cache.org> #969: init.d stop() function improvement ---------------------------+------------------------------------------------ Reporter: David Busby | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: init.d stop() | ---------------------------+------------------------------------------------ If you have need to run multiple varnish instances on the same machine and still maintain an init.d script for each, the default stop() function can lead to problems due to {{{ killproc $prog }}} This will infact kill all running varnishd processes, where if you run multiple instances on a single host, can be very bad. In this case a replacement {{{ killproc -p ${pidfile} -d 10 $prog }}} Or similar can be used, the above is an adaption of the httpd init file (Replaceing $httpd with $prod). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 27 15:13:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Jul 2011 15:13:11 -0000 Subject: [Varnish] #969: init.d stop() function improvement In-Reply-To: <048.1a4b58ae1889d78fdbc19c4917c74b3a@varnish-cache.org> References: <048.1a4b58ae1889d78fdbc19c4917c74b3a@varnish-cache.org> Message-ID: <057.2478c1dd341f652caa9058225c098c48@varnish-cache.org> #969: init.d stop() function improvement ---------------------------+------------------------------------------------ Reporter: David Busby | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Keywords: init.d stop() | ---------------------------+------------------------------------------------ Comment(by David Busby): rh_status alos needs to be amended in this case {{{ rh_status() { status -p ${pidfile} $prog } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator