From varnish-bugs at varnish-cache.org Fri Feb 3 14:34:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 03 Feb 2012 14:34:48 -0000 Subject: [Varnish] #1089: Error in wiki page VCLExampleNormalizeUserAgent Message-ID: <046.5179d2d0c3a7b48a33797cd687708e46@varnish-cache.org> #1089: Error in wiki page VCLExampleNormalizeUserAgent ----------------------+----------------------------------------------------- Reporter: semiosis | Type: defect Status: new | Priority: normal Milestone: | Component: website Version: | Severity: normal Keywords: | ----------------------+----------------------------------------------------- This code in the wiki page [wiki:VCLExampleNormalizeUserAgent VCLExampleNormalizeUserAgent] has a bug... {{{ sub vcl_fetch { ... # If you want to see it in the delivered object headers too set obj.http.X-UA = req.http.X-UA; # set beresp.http.X-UA for 2.1+ # Vary by X-UA, so varnish will keep distinct object copies by X-UA value set obj.http.Vary = "X-UA"; # set beresp.http.X-UA for 2.1+ ... } }}} The commented code for 2.1+ is the same on both lines! The second line's comment should set beresp.http.Vary, as in... {{{ set obj.http.Vary = "X-UA"; # set beresp.http.Vary for 2.1+ }}} Thank you for Varnish & keep up the great work :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 6 09:49:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 06 Feb 2012 09:49:43 -0000 Subject: [Varnish] #1090: Latency for streaming using byte range requests Message-ID: <044.ff94d8062c769e8e6c3c1db0a75736c6@varnish-cache.org> #1090: Latency for streaming using byte range requests --------------------+------------------------------------------------------- Reporter: helmer | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | --------------------+------------------------------------------------------- This ticket regards the streaming support, the version used is from the streaming branch, 3.0.2-streaming.2 (Dec 8). We have been looking at using the new streaming support in Varnish to accelerate Widevine content. A Widevine player gets content roughly in the following fashion: The player first makes a regular http GET for the file, reads the first (approx) 100k bytes, closes the connection and then makes a new http request, specifying a byte range starting somewhere in the file and with an open ending. To mimic this we tried: {{{ > curl -o /dev/null -s -m 1 http://test_server/blob.wvm }}} where the media file blob.wvm is about 650 MB (the complete file won't be transferred to Varnish within the 1 second limit used by curl, -m 1), and then: {{{ > curl -o /dev/null -s -H 'Range: bytes=1234567-' http://test_server/blob.wvm }}} This results in two GET to the origin server for the complete file. Since Varnish asks the origin for the complete file, users will experience a (sometimes considerable) latency when the file is not in cache. For this use case support for byte range requests to the origin would be of great value (to our understanding not implemented, suggested enhancement). Information about our environment: CentoS 5.5, we compiled the source "plain vanilla" with gcc 4.1.2. The default.vcl was used with streaming enabled: {{{ sub vcl_fetch { set beresp.do_stream = true; } }}} We started varnishd with {{{ /usr/local/sbin/varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,256M -s persistent,/var/varnish/varnish.cache,2048M -p default_ttl=7200 -T 127.0.0.1:2000 -a 0.0.0.0:8080 }}} I added Martin as cc, since he has been working on this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 6 11:59:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 06 Feb 2012 11:59:51 -0000 Subject: [Varnish] #1090: Latency for streaming using byte range requests In-Reply-To: <044.ff94d8062c769e8e6c3c1db0a75736c6@varnish-cache.org> References: <044.ff94d8062c769e8e6c3c1db0a75736c6@varnish-cache.org> Message-ID: <053.5ffba98164930346a8f43a9e295d2750@varnish-cache.org> #1090: Latency for streaming using byte range requests ----------------------+----------------------------------------------------- Reporter: helmer | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: In Varnish 3.0.2s, when a range request is made, the do_stream flag is turned off. So the request becomes just like a normal range request without any streaming. That is probably the cause of the latency you are experiencing, where the entire object will have to be fetched into Varnish before the range request can be delivered to the client. When the streaming support is released in the main branch of Varnish, we plan on having range support for the requests also when doing streaming delivery. This will then mean that the requesting client will have a streaming delivery of the requested range as the bytes of this range becomes available in the cache. The backend(/origin) request will still be for the full object. There is a patch available for the Varnish 3.0S that was posted on the varnish-dev mailing list some time ago by Thomas Souvignet that implements this mode as well. Your requested feature of byte range requests against the origin server is not something that is being worked on, as this would require support for partial objects which Varnish doesn't have. So Varnish will continue to request the full object from the origin also when streaming. As this is a feature request and we only use trac for bugs, I will close this ticket. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 6 16:02:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 06 Feb 2012 16:02:16 -0000 Subject: [Varnish] #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED In-Reply-To: <043.7d44150fbc3dd3157622b7be111ed9b0@varnish-cache.org> References: <043.7d44150fbc3dd3157622b7be111ed9b0@varnish-cache.org> Message-ID: <052.e38877c29d93118e34a20c7b270a02b2@varnish-cache.org> #865: Opensolaris/snv_134 and others: CNT_Session - TCP_blocking failing with ECONNREFUSED --------------------------+------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: port:solaris | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Changes (by slink): * status: assigned => closed * resolution: => fixed Comment: late update of this bug, I believe this is fixed: * There was a race condition in the varnishtest code which I confused with the actual issue. This is fixed in [3b73cf0e92f432c23387ca498d7783f1d1b18bee] * Contrary to other OSes, Solaris returns previous TCP_errors for setsockopt and other socket calls, so Varnish needs to relax assertion checks. This is fixed in ** [e600a75ed5d35db87b36bf64d45940e50c0d25c7] ** [ac666733b7985436b77f10f5276909e7e65933c9] ** [31636e68029195142aee28b5fefb00841b3990a2] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 7 08:39:40 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Feb 2012 08:39:40 -0000 Subject: [Varnish] #1091: saint mode and directors doesn't seem to work Message-ID: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> #1091: saint mode and directors doesn't seem to work ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- I would expect saint mode on an object to mean that it would fall back to the next backend in the director, which it doesn't seem to do. VCL: {{{ backend b1 { .host = "127.0.0.1"; .port = "8081"; .saintmode_threshold = 10; .probe = {} } backend b2 { .host = "127.0.0.1"; .port = "8081"; .saintmode_threshold = 10; .probe = {} } director default fallback { { .backend = b1; } { .backend = b2; } } sub vcl_recv { set req.backend = default; set req.grace = 1h; } sub vcl_fetch { if(req.restarts < 1) { set beresp.saintmode = 1h; return(restart); } } }}} docs say: Varnish will then retry other backends to try to fetch the object again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 10 10:44:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Feb 2012 10:44:16 -0000 Subject: [Varnish] #1092: esi:remove does not remove HTML comments completely Message-ID: <045.bd8cca6e9385d617fd4d65afb90de0d4@varnish-cache.org> #1092: esi:remove does not remove HTML comments completely --------------------------------+------------------------------------------- Reporter: derjohn | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: esi remove derjohn | --------------------------------+------------------------------------------- Hello, if I put a HTML comment between the esi_remove, varnish removes everything except " I regards this as a bug. Funny is that, the the Rest of the HTML page will not be rendered anymore, because the browser thinks, it's commented out :) rgds, derjohn -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 12 06:41:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 12 Feb 2012 06:41:00 -0000 Subject: [Varnish] #1093: Installation on Ubuntu uses curl Message-ID: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> #1093: Installation on Ubuntu uses curl -----------------------------------------------+---------------------------- Reporter: wido | Type: enhancement Status: new | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: normal Keywords: ubuntu,apt,curl,wget,installation | -----------------------------------------------+---------------------------- Page: https://www.varnish-cache.org/installation/ubuntu On clean Ubuntu systems cURL is not installed by default, so it's an extra step to setup cuRL before installing Varnish. I'd recommend changing the installation instructions to: wget -O - http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add - echo "deb http://repo.varnish-cache.org/ubuntu/ lucid varnish-3.0" > /etc/apt/sources.list.d/varnish.list apt-get update apt-get install varnish This uses wget and also places the Varnish source in it's own apt file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 13 11:14:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Feb 2012 11:14:52 -0000 Subject: [Varnish] #1092: esi:remove does not remove HTML comments completely In-Reply-To: <045.bd8cca6e9385d617fd4d65afb90de0d4@varnish-cache.org> References: <045.bd8cca6e9385d617fd4d65afb90de0d4@varnish-cache.org> Message-ID: <054.72b645a946254a6a3cd276d1968750a1@varnish-cache.org> #1092: esi:remove does not remove HTML comments completely ----------------------+----------------------------------------------------- Reporter: derjohn | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Keywords: esi remove derjohn ----------------------+----------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 13 11:15:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Feb 2012 11:15:44 -0000 Subject: [Varnish] #1093: Installation on Ubuntu uses curl In-Reply-To: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> References: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> Message-ID: <051.95dd15abc13f2c684a2f63b6f6bda29d@varnish-cache.org> #1093: Installation on Ubuntu uses curl ----------------------+----------------------------------------------------- Reporter: wido | Type: enhancement Status: closed | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: normal Resolution: wontfix | Keywords: ubuntu,apt,curl,wget,installation ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: I prefer curl over wget and it's useful to have it on the system anyway, so I don't want to change that part. As for varnish.list vs sources.list, lots of documentation refers to sources.list and so it's more discoverable to keep it there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 13 11:21:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Feb 2012 11:21:49 -0000 Subject: [Varnish] #1089: Error in wiki page VCLExampleNormalizeUserAgent In-Reply-To: <046.5179d2d0c3a7b48a33797cd687708e46@varnish-cache.org> References: <046.5179d2d0c3a7b48a33797cd687708e46@varnish-cache.org> Message-ID: <055.71ead9fbeef1c1ca42187fcd7ae45e51@varnish-cache.org> #1089: Error in wiki page VCLExampleNormalizeUserAgent -----------------------+---------------------------------------------------- Reporter: semiosis | Type: defect Status: closed | Priority: normal Milestone: | Component: website Version: | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 13 12:11:15 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Feb 2012 12:11:15 -0000 Subject: [Varnish] #1091: saint mode and directors doesn't seem to work In-Reply-To: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> References: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> Message-ID: <052.23040c952281514cfe9c309893d076da@varnish-cache.org> #1091: saint mode and directors doesn't seem to work ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by scoof): Test case attached -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 13 14:46:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Feb 2012 14:46:02 -0000 Subject: [Varnish] #1091: saint mode and directors doesn't seem to work In-Reply-To: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> References: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> Message-ID: <052.749ffb41322670b4275ad0dea6893287@varnish-cache.org> #1091: saint mode and directors doesn't seem to work ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by martin): Saintmode works by having a list of objhead's per backend that should not be used for delivery. In this test case the object isn't stored, which frees the objhead. On the second pass a new objhead is created, which ofc isn't on the trouble list. Should saint-mode trouble list entries keep a ref on the objhead to prevent this? Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 14 15:03:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 14 Feb 2012 15:03:48 -0000 Subject: [Varnish] #1092: esi:remove does not remove HTML comments completely In-Reply-To: <045.bd8cca6e9385d617fd4d65afb90de0d4@varnish-cache.org> References: <045.bd8cca6e9385d617fd4d65afb90de0d4@varnish-cache.org> Message-ID: <054.0436786981fd4798da47add1234020cc@varnish-cache.org> #1092: esi:remove does not remove HTML comments completely --------------------------------+------------------------------------------- Reporter: derjohn | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: esi remove derjohn | --------------------------------+------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [a434ce46a6362f1dc930d783982a8eda67cb99d6]) Honor remove-flag also when processing comments in ESI parsing. Fixes: #1092 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 15 16:19:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Feb 2012 16:19:55 -0000 Subject: [Varnish] #1093: Installation on Ubuntu uses curl In-Reply-To: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> References: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> Message-ID: <051.710308feb8ed51c81397fe46651c92a7@varnish-cache.org> #1093: Installation on Ubuntu uses curl -----------------------+---------------------------------------------------- Reporter: wido | Type: enhancement Status: reopened | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: normal Resolution: | Keywords: ubuntu,apt,curl,wget,installation -----------------------+---------------------------------------------------- Changes (by wido): * status: closed => reopened * resolution: wontfix => Comment: Fair enough. The Debian installation however uses a varnish.list: https://www.varnish-cache.org/installation/debian What's the difference there? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 15 17:09:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Feb 2012 17:09:21 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix Message-ID: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> #1094: var directory not placed one directory above prefix ----------------------+----------------------------------------------------- Reporter: bmaltzan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Hi, I compiled and installed like this: $ ./configure --prefix=/myprojectdir/varnish I added the var you see here: $ ls /myprojectdir/varnish . .. bin etc include lib sbin share var These are going into my project, not the varnish prefix directory: $ ls /myprojectdir/var/varnish/myserver/ . .. vcl.JTGH5n_K.so _.vsm Thanks, Brian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 15 17:16:30 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Feb 2012 17:16:30 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix In-Reply-To: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> References: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> Message-ID: <055.6eb01f3b5dc01aade99f766f6182dd47@varnish-cache.org> #1094: var directory not placed one directory above prefix ----------------------+----------------------------------------------------- Reporter: bmaltzan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by bmaltzan): That should have been: var directory placed one directory above --prefix directory -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 16 18:54:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 16 Feb 2012 18:54:37 -0000 Subject: [Varnish] #1056: obj.* should be available in vcl_deliver In-Reply-To: <043.fdc9eba85b012a610536d23ce7035134@varnish-cache.org> References: <043.fdc9eba85b012a610536d23ce7035134@varnish-cache.org> Message-ID: <052.e5c751bae21f848c926f0b2867f1e85e@varnish-cache.org> #1056: obj.* should be available in vcl_deliver ----------------------+----------------------------------------------------- Reporter: scoof | Owner: scoof Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Andreas Plesner Jacobsen ): * status: new => closed * resolution: => fixed Comment: (In [7d164e06e42dd6524b12acaa87a84c2aaf0404db]) Most of these variables are not available in vcl_deliver Fixes #1056 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 16 18:57:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 16 Feb 2012 18:57:37 -0000 Subject: [Varnish] #1088: Problem with download large file In-Reply-To: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> References: <049.41021218962618ac1fc58fb319c85891@varnish-cache.org> Message-ID: <058.c09c0f8423a6a8ef09179d3e18c87a49@varnish-cache.org> #1088: Problem with download large file --------------------------+------------------------------------------------- Reporter: advancehost | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: invalid | Keywords: big file, large file, download --------------------------+------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: You should use return(pass) to avoid caching an object. Since nothing indicates that this is a bug, I will close this ticket. Please use mailing lists or IRC for support questions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 17 09:24:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Feb 2012 09:24:31 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: Message-ID: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Just got all 5 varnish nodes down with the same message. Due to a problem on the web server pool varnishes got tons of 503. When problems were resolved NOC tried to ban those objects from cache using ban obj.http.status == . Naturally it did not work, but the thing is that varnishes went down 10 minutes after. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 17 11:46:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Feb 2012 11:46:06 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: In-Reply-To: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> References: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> Message-ID: <061.a7ab1ff3666e626902149dee21c359ce@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Comment(by alex.goncharov): ah, right: 2.6.32-5-amd64, debian 6.0.3 /etc/default/varnish NFILES=131072 MEMLOCK=82000 DAEMON_OPTS="-a :80 \ -f /etc/varnish/mp-varnish.vcl \ -T :6082 \ -s ram=malloc,90G \ -p thread_pool_add_delay=2 \ -p http_gzip_support=on \ -p thread_pools=24 \ -p default_ttl=7200 \ -p thread_pool_min=40 \ -p thread_pool_max=4000 \ -p session_linger=50 \ -p sess_workspace=1048576 \ -p shm_workspace=8192 \ -p 'cc_command=exec cc -fpic -shared -Wl,-x -L/usr/include/varnish/varnishapi.h -lvarnishapi -o %o %s' " MemTotal: 99197296 kB at the moment of crash varnish was doing around 3k req/s with 98% hitrate. SMA mem free ~30G, mem used according to snmp statistics 82G, swap not used. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 17 13:18:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Feb 2012 13:18:32 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: In-Reply-To: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> References: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> Message-ID: <061.1e4d16347516294ce0c9c189176c0df2@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Comment(by alex.goncharov): And it's 3.0.2, can't seem to change it in a proper place varnishd (varnish-3.0.2 revision cbf1284) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 11:21:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 11:21:01 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: In-Reply-To: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> References: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> Message-ID: <061.f97221f4129239a410b91651690088df@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Comment(by martin): You wouldn't happen to have some varnishstat output of the system at around the time this happened? Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 11:24:32 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 11:24:32 -0000 Subject: [Varnish] #1093: Installation on Ubuntu uses curl In-Reply-To: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> References: <042.110ba194576e4dee00362c3a9e81bd20@varnish-cache.org> Message-ID: <051.721a7e2efee015d29b17af64d324c219@varnish-cache.org> #1093: Installation on Ubuntu uses curl ---------------------+------------------------------------------------------ Reporter: wido | Type: enhancement Status: closed | Priority: normal Milestone: | Component: website Version: 3.0.0 | Severity: normal Resolution: fixed | Keywords: ubuntu,apt,curl,wget,installation ---------------------+------------------------------------------------------ Changes (by tfheen): * status: reopened => closed * resolution: => fixed Comment: I've fixed them to be the same now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 11:27:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 11:27:45 -0000 Subject: [Varnish] #1095: Assert error in SMS_Finish(), storage_synth.c line 114: In-Reply-To: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> References: <052.583a0880dd82471b8c0861a3310d6cc8@varnish-cache.org> Message-ID: <061.9983978cf9c605443b4f2eb6646217bb@varnish-cache.org> #1095: Assert error in SMS_Finish(), storage_synth.c line 114: ---------------------------------+------------------------------------------ Reporter: alex.goncharov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: critical Keywords: varnishd SMS_Finish | ---------------------------------+------------------------------------------ Comment(by alex.goncharov): Unfortunately no, just rrd graphs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 11:47:11 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 11:47:11 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix In-Reply-To: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> References: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> Message-ID: <055.338e678e51c57fa00b2ff5e6945a6378@varnish-cache.org> #1094: var directory not placed one directory above prefix ----------------------+----------------------------------------------------- Reporter: bmaltzan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): I can't reproduce this, can you please provide the output of your configure run? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 15:49:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 15:49:59 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix In-Reply-To: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> References: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> Message-ID: <055.1f88047bdfc7bb7a13c63dafecd47be5@varnish-cache.org> #1094: var directory not placed one directory above prefix ----------------------+----------------------------------------------------- Reporter: bmaltzan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by bmaltzan): This log is my second run of configure, the first did not use localstatedir. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 20 17:29:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Feb 2012 17:29:01 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix In-Reply-To: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> References: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> Message-ID: <055.cc341cd28476b49bd1ae46fc0ab0301e@varnish-cache.org> #1094: var directory not placed one directory above prefix ----------------------+----------------------------------------------------- Reporter: bmaltzan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by bmaltzan): I deleted, unzipped a fresh copy, installed, and it's now writing to the correct var directory. I had been having a little trouble getting it to compile with pcre, maybe it was a quirk there, or maybe I changed the prefix directory between install attempts, and it didn't like that? Thanks, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 21 08:22:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Feb 2012 08:22:13 -0000 Subject: [Varnish] #1096: Varnish Crashes with a lot of Firebug logging Message-ID: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> #1096: Varnish Crashes with a lot of Firebug logging ----------------------+----------------------------------------------------- Reporter: sukerman | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Varnish crashes if there is a lot of firebug output. Firebug adds its log line into the http headers so I guess this is something to do with it. You need firefox and firebug installed. Test here: http://www.blackbox-ims.co.uk/varnish_firebug.php Test here, bypassing varnish works: http://www.blackbox-ims.co.uk:8080/varnish_firebug.php Code: Cheers, S. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 21 08:25:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Feb 2012 08:25:03 -0000 Subject: [Varnish] #1096: Varnish Crashes with a lot of Firebug logging In-Reply-To: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> References: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> Message-ID: <055.ae3ab5f26e84b3539bf5e9b8ef55b839@varnish-cache.org> #1096: Varnish Crashes with a lot of Firebug logging ----------------------+----------------------------------------------------- Reporter: sukerman | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by sukerman): Sorry - I've but this under 'build' and I can't seem to change it -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 21 08:28:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Feb 2012 08:28:56 -0000 Subject: [Varnish] #1096: Varnish Crashes with a lot of Firebug logging In-Reply-To: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> References: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> Message-ID: <055.77adee0406292888ae79003f5baf7fe4@varnish-cache.org> #1096: Varnish Crashes with a lot of Firebug logging ----------------------+----------------------------------------------------- Reporter: sukerman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Changes (by scoof): * component: build => varnishd Comment: Please supply varnishlog, syslog and panic.show output -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 21 10:23:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Feb 2012 10:23:39 -0000 Subject: [Varnish] #1094: var directory not placed one directory above prefix In-Reply-To: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> References: <046.dc77b3bb37ce229f38a42be6152beca7@varnish-cache.org> Message-ID: <055.bf42d42cd3db5065444f0944900e58ea@varnish-cache.org> #1094: var directory not placed one directory above prefix -------------------------+-------------------------------------------------- Reporter: bmaltzan | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => worksforme Comment: PCRE should not have anything to do with it, but you might have tickled autoconf in a way that caused it to cache the localstatedir to be the wrong value. I'm closing this bug now, but if you are able to reproduce it, please reopen and I'll take a look again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 21 16:54:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Feb 2012 16:54:08 -0000 Subject: [Varnish] #1097: cacti plugin for varnish 3.x Message-ID: <044.1bad9c5bc8579847d70b4cbaa103afad@varnish-cache.org> #1097: cacti plugin for varnish 3.x -----------------------------+---------------------------------------------- Reporter: egamez | Type: defect Status: new | Priority: high Milestone: Varnish 3.0 dev | Component: varnishstat Version: 3.0.0 | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Hi, I want to know if exist any plugin for monitorice varnish 3.x throug cacti. In this case, i want to know how to install and configure on my cacti server. Thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 22 16:06:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 22 Feb 2012 16:06:06 -0000 Subject: [Varnish] #1087: Requests dropped due to long headers are invisible In-Reply-To: <046.51b5f88fa91d9e1805a2c1d9b6719239@varnish-cache.org> References: <046.51b5f88fa91d9e1805a2c1d9b6719239@varnish-cache.org> Message-ID: <055.a5abb4476998730714d6d9b994de9c19@varnish-cache.org> #1087: Requests dropped due to long headers are invisible ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by martin): This is part of the logs. In 3.0 there will be a SLT_SessionClose log entry with the value "blast" when this happens. In trunk the message is more descriptive and can include both "EOF" and "overflow". Should be sufficient IMHO. Close this issue? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 23 09:45:40 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 23 Feb 2012 09:45:40 -0000 Subject: [Varnish] #1097: cacti plugin for varnish 3.x In-Reply-To: <044.1bad9c5bc8579847d70b4cbaa103afad@varnish-cache.org> References: <044.1bad9c5bc8579847d70b4cbaa103afad@varnish-cache.org> Message-ID: <053.555df35172f1279d0700995ed6165350@varnish-cache.org> #1097: cacti plugin for varnish 3.x -----------------------------+---------------------------------------------- Reporter: egamez | Type: defect Status: new | Priority: high Milestone: Varnish 3.0 dev | Component: varnishstat Version: 3.0.0 | Severity: normal Keywords: | -----------------------------+---------------------------------------------- Comment(by jhalfmoon): Please repost the question on the varnish-misc mailinglist, where it belongs, and I might be able to help you out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 23 10:45:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 23 Feb 2012 10:45:04 -0000 Subject: [Varnish] #1087: Requests dropped due to long headers are invisible In-Reply-To: <046.51b5f88fa91d9e1805a2c1d9b6719239@varnish-cache.org> References: <046.51b5f88fa91d9e1805a2c1d9b6719239@varnish-cache.org> Message-ID: <055.e902a9a3bb0de6c39fbb50dfb6f1dcc4@varnish-cache.org> #1087: Requests dropped due to long headers are invisible ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: After a discussion with Kristian we came to the conclusion that the necessary information is part of the shm log, and that this is not an issue. Closing this ticket as 'worksforme'. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 24 12:21:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 24 Feb 2012 12:21:51 -0000 Subject: [Varnish] #1096: Varnish Crashes with a lot of Firebug logging In-Reply-To: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> References: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> Message-ID: <055.3d9218f6f3fe345c2cf18f6102db7097@varnish-cache.org> #1096: Varnish Crashes with a lot of Firebug logging ----------------------+----------------------------------------------------- Reporter: sukerman | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Comment(by sukerman): CLI says; panic.show 300 48 Child has not panicked or panic has been cleared 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1330085582 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1330085585 1.0 13 BackendClose - default 13 BackendOpen b default 127.0.0.1 41373 127.0.0.1 8080 13 TxRequest b GET 13 TxURL b /varnish_firebug.php 13 TxProtocol b HTTP/1.1 13 TxHeader b Host: www.blackbox-ims.co.uk 13 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/8.0 SLOG FirePHP/0.7.0 13 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 13 TxHeader b Accept-Language: en-us,en;q=0.5 13 TxHeader b x-insight: activate 13 TxHeader b Cache-Control: max-age=0 13 TxHeader b X-Forwarded-For: 87.194.167.64 13 TxHeader b Cookie: PHPSESSID=noo4vitq3qhm6q5cp6lo9nqi67 13 TxHeader b Accept-Encoding: gzip 13 TxHeader b X-Varnish: 1240756623 13 BackendClose b default 12 SessionOpen c 87.194.167.64 64971 :80 12 ReqStart c 87.194.167.64 64971 1240756623 12 RxRequest c GET 12 RxURL c /varnish_firebug.php 12 RxProtocol c HTTP/1.1 12 RxHeader c Host: www.blackbox-ims.co.uk 12 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/8.0 SLOG FirePHP/0.7.0 12 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 12 RxHeader c Accept-Language: en-us,en;q=0.5 12 RxHeader c Accept-Encoding: gzip, deflate 12 RxHeader c Connection: keep-alive 12 RxHeader c Cookie: PHPSESSID=noo4vitq3qhm6q5cp6lo9nqi67 12 RxHeader c x-insight: activate 12 RxHeader c Cache-Control: max-age=0 12 VCL_call c recv lookup 12 VCL_call c hash 12 Hash c /varnish_firebug.php 12 Hash c www.blackbox-ims.co.uk 12 VCL_return c hash 12 HitPass c 1240756616 12 VCL_call c pass pass 12 Backend c 13 default default 12 FetchError c http first read error: -2 0 (No error recorded) 12 VCL_call c error deliver 12 VCL_call c deliver deliver 12 TxProtocol c HTTP/1.1 12 TxStatus c 503 12 TxResponse c Service Unavailable 12 TxHeader c Server: Varnish 12 TxHeader c Content-Type: text/html; charset=utf-8 12 TxHeader c Retry-After: 5 12 TxHeader c Content-Length: 419 12 TxHeader c Accept-Ranges: bytes 12 TxHeader c Date: Fri, 24 Feb 2012 12:13:06 GMT 12 TxHeader c X-Varnish: 1240756623 12 TxHeader c Age: 0 12 TxHeader c Via: 1.1 varnish 12 TxHeader c Connection: close 12 Length c 419 12 ReqEnd c 1240756623 1330085586.364315987 1330085586.470052958 0.000083923 0.105669975 0.000066996 12 SessionClose c error 12 StatSess c 87.194.167.64 64971 0 1 1 0 1 0 257 419 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1330085588 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1330085591 1.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 24 16:22:47 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 24 Feb 2012 16:22:47 -0000 Subject: [Varnish] #1098: Return HTTP 416 for unsatisfiable byte-range requests Message-ID: <046.d36edf075ecb09f13af5a5bf04c34628@varnish-cache.org> #1098: Return HTTP 416 for unsatisfiable byte-range requests ----------------------+----------------------------------------------------- Reporter: jmeacham | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Please consider returning HTTP 416 for unsatisfiable byte-range requests (as recommended in section 10.4.17 of RFC 2616) rather than returning the entire object with HTTP 200. I understand that this is not a required in the HTTP 1.1 spec. However, I believe that implementing this 'proper' behavior would be of value, given the increased usage of byte-range requests in multimedia streaming applications. Thank you for your consideration and your continued work. Example requests to Varnish and backend storage for unsatisfiable ranges are included below. Request to Varnish cache: $curl -o /dev/null -s -H 'Range: bytes=1234567-' http://cache001.dc2/11001/index.html 10.20.31.179 - - [24/Feb/2012:16:12:54 +0000] "GET http://cache001.dc2/11001/index.html HTTP/1.1" 200 109 "-" "curl/7.24.0 (x86_64-apple-darwin11.2.0) libcurl/7.24.0 OpenSSL/1.0.0g zlib/1.2.6 libidn/1.22" Request to backend storage: $ curl -s -H 'Range: bytes=1234567-' http://cfs001-1.af1/11001/index.html 416 Requested Range Not Satisfiable

Requested Range Not Satisfiable

None of the range-specifier values in the Range request-header field overlap the current extent of the selected resource.

10.20.31.179 - - [24/Feb/2012:16:14:16 +0000] "GET /11001/index.html HTTP/1.1" 416 314 "-" "curl/7.24.0 (x86_64-apple-darwin11.2.0) libcurl/7.24.0 OpenSSL/1.0.0g zlib/1.2.6 libidn/1.22" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 25 02:01:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 25 Feb 2012 02:01:53 -0000 Subject: [Varnish] #1099: Varnish ESI Panic Message-ID: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> #1099: Varnish ESI Panic --------------------+------------------------------------------------------- Reporter: zellja | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.2 | Severity: major Keywords: | --------------------+------------------------------------------------------- We're seeing this in our logs every ~30 minutes or so: Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) died signal=6 Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) Panic message: Missing errorhandling code in vfp_esi_end(), cache_esi_fetch.c line 388: Condition((vef->error) == 0) not true.thread = (cache-worker) ident = Linux,2.6.18-238.9.1.el5xen,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42c7a6: /usr/sbin/varnishd [0x42c7a6] 0x41b2e8: /usr/sbin/varnishd [0x41b2e8] 0x4215fd: /usr/sbin/varnishd(FetchBody+0x3fd) [0x4215fd] 0x4153e8: /usr/sbin/varnishd [0x4153e8] 0x417ab6: /usr/sbin/varnishd(CNT_Session+0x9f6) [0x417ab6] 0x41f5cd: /usr/sbin/varnishd(ESI_Deliver+0x93d) [0x41f5cd] 0x42fc88: /usr/sbin/varnishd(RES_WriteObj+0x5b8) [0x42fc88] 0x4157cb: /usr/sbin/varnishd [0x4157cb] 0x417827: /usr/sbin/varnishd(CNT_Session+0x767) [0x417827] 0x42efb8: /usr/sbin/varnishd [0x42efb8] sp = 0x2aaaaab82008 { fd = 29, id = 29, xid = 1755500721, client = 173.231.151.52 22726, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 1 flags = When this happens, the manager thread restarts the worker and serving continues until the next time it happens; unfortunately the cache is emptied each time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 25 18:34:07 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 25 Feb 2012 18:34:07 -0000 Subject: [Varnish] #1096: Varnish Crashes with a lot of Firebug logging In-Reply-To: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> References: <046.d106430a6cd80935ed25d0d6133cffc6@varnish-cache.org> Message-ID: <055.234edcd2ad300c864529b5b30152c79c@varnish-cache.org> #1096: Varnish Crashes with a lot of Firebug logging -----------------------+---------------------------------------------------- Reporter: sukerman | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: This is not a crash, and not a bug. You're hitting configured limits. You need to change these runtime parameters to fit your headers: http_resp_size and http_max_hdr -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 25 18:47:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 25 Feb 2012 18:47:17 -0000 Subject: [Varnish] #1100: Assert error in stv_alloc(), stevedore.c line 144 Message-ID: <042.63d2077ebde3a5ab8b3d16b5f7a5e9eb@varnish-cache.org> #1100: Assert error in stv_alloc(), stevedore.c line 144 -------------------+-------------------------------------------------------- Reporter: Roze | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- After filling up the file storage varnish child gets killed and restarted (with empty cache). Varnish is started with: {{{ ./varnishd -f etc/varnish/default.vcl -T 127.0.0.1:8000 -s file,/mnt/ssd1/cache,100G -s file,/mnt/ssd2/cache,100G -h critbit -p connect_timeout=600 -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=5000 -thread_pool_add_delay=2 -p cli_timeout=50 -p session_linger=120 -p lru_interval=20 }}} Log: {{{ Feb 25 15:55:44 is50 varnishd[26994]: Child (26995) not responding to CLI, killing it. Feb 25 15:55:44 is50 varnishd[26994]: Child (26995) died signal=6 Feb 25 15:55:44 is50 varnishd[26994]: Child (26995) Panic message: Assert error in stv_alloc(), stevedore.c line 144: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,3.2.0-rc2-2-default,x86_64,-sfile,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4284a8: pan_ic+b8 0x43f9fd: STV_alloc+17d 0x41e057: vfp_nop_begin+97 0x41ea11: FetchBody+291 0x4164fd: CNT_Session+1c8d 0x429c28: wrk_do_cnt_sess+b8 0x42a059: wrk_thread_real+379 0x7f46ce5f2a4f: _end+7f46cdf81937 0x7f46ce35c91d: _end+7f46cdceb805 sp = 0x7f1275f46008 { fd = 2043, id = 2043, xid = 2002093578, client = 10.10.0.1 2077, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f1275f46080 { id = "sess", {s,f,r,e} = {0x7f1275f46cd8,+592,(nil),+65536}, }, http[req] = { ws = 0x7f1275f46080[sess] "GET", "/a31023120084f800da6fdb8642ba0a8b/975/160/v1/l_230975160.jpg", "HTTP/1.1", "Host: i0.imgdomain.com", "Connection: keep-alive", "User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11", "Accept: */*", "Accept-Language: en-US,en;q=0.8", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3", }, worker = 0x7f11ec8febb0 { ws = 0x7f11ec8fed38 { id = "wrk", {s,f,r,e} = {0x7f11ec8ecb40,+2920,(nil),+65536}, }, http[bereq] = { ws = 0x7f11ec8fed38[wrk] "GET", "/a31023120084f800da6fdb8642ba0a8b/975/160/v1/l_230975160.jpg", "HTTP/1.1", "Host: i0.imgdomain.com", "User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11", "Accept: */ Feb 25 15:55:44 is50 varnishd[26994]: Child cleanup complete Feb 25 15:55:44 is50 varnishd[26994]: child (16686) Started Feb 25 15:55:44 is50 varnishd[26994]: Child (16686) said Feb 25 15:55:44 is50 varnishd[26994]: Child (16686) said Child starts Feb 25 15:55:44 is50 varnishd[26994]: Child (16686) said SMF.s0 mmap'ed 107374182400 bytes of 107374182400 Feb 25 15:55:44 is50 varnishd[26994]: Child (16686) said SMF.s1 mmap'ed 107374182400 bytes of 107374182400 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 09:40:15 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 09:40:15 -0000 Subject: [Varnish] #1101: Varnish cannot use accept filters accf_http Message-ID: <048.689cc74aa903d51f116eba209a34f9e7@varnish-cache.org> #1101: Varnish cannot use accept filters accf_http -------------------------------------+-------------------------------------- Reporter: allan.jude | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: minor Keywords: accept_filter httpready | -------------------------------------+-------------------------------------- Varnish cannot use FreeBSD accf_http httpready accept filter It seems the issue is that setsockopt() is called before listen(), so the accept filter returns EINVAL {{{ 45411 initial thread CALL socket(PF_INET,SOCK_STREAM,IPPROTO_TCP) 45411 initial thread RET socket 6 45411 initial thread CALL setsockopt(0x6,SOL_SOCKET,SO_REUSEADDR,0xbfbfde48,0x4) 45411 initial thread RET setsockopt 0 45411 initial thread CALL bind(0x6,0x28317310,0x10) 45411 initial thread STRU struct sockaddr { AF_INET, 64.120.14.107:80 } 45411 initial thread RET bind 0 45411 initial thread CALL ioctl(0x6,FIONBIO,0xbfbfde48) 45411 initial thread RET ioctl 0 45411 initial thread CALL setsockopt(0x6,SOL_SOCKET,SO_ACCEPTFILTER,0xbfbfdd4c,0x100) 45411 initial thread RET setsockopt -1 errno 22 Invalid argument }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:13:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:13:05 -0000 Subject: [Varnish] #1099: Varnish ESI Panic In-Reply-To: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> References: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> Message-ID: <053.295af0e0b9c1192e5253d1003f4b887a@varnish-cache.org> #1099: Varnish ESI Panic --------------------+------------------------------------------------------- Reporter: zellja | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.2 | Severity: major Keywords: | --------------------+------------------------------------------------------- Description changed by kristian: Old description: > We're seeing this in our logs every ~30 minutes or so: > > Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) died signal=6 > Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) Panic message: > Missing errorhandling code in vfp_esi_end(), cache_esi_fetch.c line 388: > Condition((vef->error) == 0) not true.thread = (cache-worker) ident = > Linux,2.6.18-238.9.1.el5xen,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: 0x42c7a6: /usr/sbin/varnishd [0x42c7a6] 0x41b2e8: > /usr/sbin/varnishd [0x41b2e8] 0x4215fd: > /usr/sbin/varnishd(FetchBody+0x3fd) [0x4215fd] 0x4153e8: > /usr/sbin/varnishd [0x4153e8] 0x417ab6: > /usr/sbin/varnishd(CNT_Session+0x9f6) [0x417ab6] 0x41f5cd: > /usr/sbin/varnishd(ESI_Deliver+0x93d) [0x41f5cd] 0x42fc88: > /usr/sbin/varnishd(RES_WriteObj+0x5b8) [0x42fc88] 0x4157cb: > /usr/sbin/varnishd [0x4157cb] 0x417827: > /usr/sbin/varnishd(CNT_Session+0x767) [0x417827] 0x42efb8: > /usr/sbin/varnishd [0x42efb8] sp = 0x2aaaaab82008 { fd = 29, id = 29, > xid = 1755500721, client = 173.231.151.52 22726, step = > STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esi_level = 1 flags = > > When this happens, the manager thread restarts the worker and serving > continues until the next time it happens; unfortunately the cache is > emptied each time. New description: We're seeing this in our logs every ~30 minutes or so: {{{ Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) died signal=6 Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) Panic message: Missing errorhandling code in vfp_esi_end(), cache_esi_fetch.c line 388: Condition((vef->error) == 0) not true.thread = (cache-worker) ident = Linux,2.6.18-238.9.1.el5xen,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42c7a6: /usr/sbin/varnishd [0x42c7a6] 0x41b2e8: /usr/sbin/varnishd [0x41b2e8] 0x4215fd: /usr/sbin/varnishd(FetchBody+0x3fd) [0x4215fd] 0x4153e8: /usr/sbin/varnishd [0x4153e8] 0x417ab6: /usr/sbin/varnishd(CNT_Session+0x9f6) [0x417ab6] 0x41f5cd: /usr/sbin/varnishd(ESI_Deliver+0x93d) [0x41f5cd] 0x42fc88: /usr/sbin/varnishd(RES_WriteObj+0x5b8) [0x42fc88] 0x4157cb: /usr/sbin/varnishd [0x4157cb] 0x417827: /usr/sbin/varnishd(CNT_Session+0x767) [0x417827] 0x42efb8: /usr/sbin/varnishd [0x42efb8] sp = 0x2aaaaab82008 { fd = 29, id = 29, xid = 1755500721, client = 173.231.151.52 22726, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 1 flags = }}} When this happens, the manager thread restarts the worker and serving continues until the next time it happens; unfortunately the cache is emptied each time. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:14:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:14:38 -0000 Subject: [Varnish] #1099: Varnish ESI Panic In-Reply-To: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> References: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> Message-ID: <053.05604363f0edf4972157089c85536778@varnish-cache.org> #1099: Varnish ESI Panic --------------------+------------------------------------------------------- Reporter: zellja | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.2 | Severity: major Keywords: | --------------------+------------------------------------------------------- Description changed by kristian: Old description: > We're seeing this in our logs every ~30 minutes or so: > > {{{ > Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) died signal=6 > Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) Panic message: > Missing errorhandling code in vfp_esi_end(), cache_esi_fetch.c line 388: > Condition((vef->error) == 0) not true.thread = (cache-worker) ident = > Linux,2.6.18-238.9.1.el5xen,x86_64,-sfile,-smalloc,-hcritbit,epoll > Backtrace: 0x42c7a6: /usr/sbin/varnishd [0x42c7a6] 0x41b2e8: > /usr/sbin/varnishd [0x41b2e8] 0x4215fd: > /usr/sbin/varnishd(FetchBody+0x3fd) [0x4215fd] 0x4153e8: > /usr/sbin/varnishd [0x4153e8] 0x417ab6: > /usr/sbin/varnishd(CNT_Session+0x9f6) [0x417ab6] 0x41f5cd: > /usr/sbin/varnishd(ESI_Deliver+0x93d) [0x41f5cd] 0x42fc88: > /usr/sbin/varnishd(RES_WriteObj+0x5b8) [0x42fc88] 0x4157cb: > /usr/sbin/varnishd [0x4157cb] 0x417827: > /usr/sbin/varnishd(CNT_Session+0x767) [0x417827] 0x42efb8: > /usr/sbin/varnishd [0x42efb8] sp = 0x2aaaaab82008 { fd = 29, id = 29, > xid = 1755500721, client = 173.231.151.52 22726, step = > STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = > (null), restarts = 0, esi_level = 1 flags = > > }}} > > When this happens, the manager thread restarts the worker and serving > continues until the next time it happens; unfortunately the cache is > emptied each time. New description: We're seeing this in our logs every ~30 minutes or so: {{{ Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) died signal=6 Feb 25 01:22:25 tsgcsvnsh01 varnishd[15417]: Child (16120) Panic message: Missing errorhandling code in vfp_esi_end(), cache_esi_fetch.c line 388: Condition((vef->error) == 0) not true. thread = (cache-worker) ident = Linux,2.6.18-238.9.1.el5xen,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x42c7a6: /usr/sbin/varnishd [0x42c7a6] 0x41b2e8: /usr/sbin/varnishd [0x41b2e8] 0x4215fd: /usr/sbin/varnishd(FetchBody+0x3fd) [0x4215fd] 0x4153e8: /usr/sbin/varnishd [0x4153e8] 0x417ab6: /usr/sbin/varnishd(CNT_Session+0x9f6) [0x417ab6] 0x41f5cd: /usr/sbin/varnishd(ESI_Deliver+0x93d) [0x41f5cd] 0x42fc88: /usr/sbin/varnishd(RES_WriteObj+0x5b8) [0x42fc88] 0x4157cb: /usr/sbin/varnishd [0x4157cb] 0x417827: /usr/sbin/varnishd(CNT_Session+0x767) [0x417827] 0x42efb8: /usr/sbin/varnishd [0x42efb8] sp = 0x2aaaaab82008 { fd = 29, id = 29, xid = 1755500721, client = 173.231.151.52 22726, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 1 flags = }}} When this happens, the manager thread restarts the worker and serving continues until the next time it happens; unfortunately the cache is emptied each time. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:16:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:16:05 -0000 Subject: [Varnish] #1101: Varnish cannot use accept filters accf_http In-Reply-To: <048.689cc74aa903d51f116eba209a34f9e7@varnish-cache.org> References: <048.689cc74aa903d51f116eba209a34f9e7@varnish-cache.org> Message-ID: <057.8bba89a91c089a06822bc2652ac74925@varnish-cache.org> #1101: Varnish cannot use accept filters accf_http -------------------------+-------------------------------------------------- Reporter: allan.jude | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: minor Resolution: fixed | Keywords: accept_filter httpready -------------------------+-------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [4d047a90b19f8821262567b793e535639b1b701a]) Accept-filters on FreeBSD has been broken for ages, fix them. Add accept-filter param which controls if we attempt kernel filteringer. Apply filters after listen() when we do. Report failuers with VSL(SLT_Error) Disable filters in pipe-lining test-case. Fixes #1101 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:21:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:21:03 -0000 Subject: [Varnish] #1049: Unbalanced {} in varnishncsa init script In-Reply-To: <043.b2723c63d08ceda97a3718abd8394083@varnish-cache.org> References: <043.b2723c63d08ceda97a3718abd8394083@varnish-cache.org> Message-ID: <052.507dc7be6d3aa263bc27bb78dfc4ee4c@varnish-cache.org> #1049: Unbalanced {} in varnishncsa init script -----------------------+---------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: low | Milestone: Component: packaging | Version: 3.0.2 Severity: normal | Keywords: -----------------------+---------------------------------------------------- Comment(by akuznecov): Still not fixed/updated for 4 months -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:25:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:25:08 -0000 Subject: [Varnish] #1100: Assert error in stv_alloc(), stevedore.c line 144 In-Reply-To: <042.63d2077ebde3a5ab8b3d16b5f7a5e9eb@varnish-cache.org> References: <042.63d2077ebde3a5ab8b3d16b5f7a5e9eb@varnish-cache.org> Message-ID: <051.7255341b6a8490c2ecf8142e8e468a1c@varnish-cache.org> #1100: Assert error in stv_alloc(), stevedore.c line 144 -------------------+-------------------------------------------------------- Reporter: Roze | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by martin): Hi, Could you provide the panic.show CLI command output from after the crash has happened, and the 'varnishstat -1' output please? Also the ticket says you are running trunk. What is the SHA value of your current HEAD? Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:25:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:25:16 -0000 Subject: [Varnish] #1099: Varnish ESI Panic In-Reply-To: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> References: <044.1a2d299f02a49b238c169695c553dbf7@varnish-cache.org> Message-ID: <053.939bb7ad459be48d00349afba40d8509@varnish-cache.org> #1099: Varnish ESI Panic ------------------------+--------------------------------------------------- Reporter: zellja | Type: defect Status: closed | Priority: high Milestone: | Component: varnishd Version: 3.0.2 | Severity: major Resolution: duplicate | Keywords: ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: This seems to be a duplicate of #1044. The fix will be merged for 3.0.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:26:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:26:43 -0000 Subject: [Varnish] #1097: cacti plugin for varnish 3.x In-Reply-To: <044.1bad9c5bc8579847d70b4cbaa103afad@varnish-cache.org> References: <044.1bad9c5bc8579847d70b4cbaa103afad@varnish-cache.org> Message-ID: <053.4e9735eade98276794949e7200583ede@varnish-cache.org> #1097: cacti plugin for varnish 3.x ------------------------------+--------------------------------------------- Reporter: egamez | Type: defect Status: closed | Priority: high Milestone: Varnish 3.0 dev | Component: varnishstat Version: 3.0.0 | Severity: normal Resolution: invalid | Keywords: ------------------------------+--------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: (Not a bug, so closing. Thanks to jhalfmoon for responding.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 11:41:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 11:41:17 -0000 Subject: [Varnish] #1091: Saintmode breaks when objhead is deleted (was: saint mode and directors doesn't seem to work) In-Reply-To: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> References: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> Message-ID: <052.f6b6daa485d7dfc11c4e8b8c8157c5f7@varnish-cache.org> #1091: Saintmode breaks when objhead is deleted ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 12:42:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 12:42:35 -0000 Subject: [Varnish] #1091: Saintmode breaks when objhead is deleted In-Reply-To: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> References: <043.c8ec0e54e300b0ced34bd41052e99c61@varnish-cache.org> Message-ID: <052.7b497b7bdbf44d69e21de5bee03c59d3@varnish-cache.org> #1091: Saintmode breaks when objhead is deleted ----------------------+----------------------------------------------------- Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [21e653c3a3e0686232646b9f933de72b6536fb50]) Use the hash digest as identification instead of the neutered objhead pointer, in order to not have dependency between trouble entry and objhead lifetime. Fixes #1091 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 12:42:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 12:42:37 -0000 Subject: [Varnish] #1082: Deadlock? In-Reply-To: <044.6b4b94b09356d8e31852997b7f4e1bd5@varnish-cache.org> References: <044.6b4b94b09356d8e31852997b7f4e1bd5@varnish-cache.org> Message-ID: <053.d682d9f1088caecd4bf1bb5f121f970a@varnish-cache.org> #1082: Deadlock? ----------------------+----------------------------------------------------- Reporter: philip | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: 3.0.0 | Severity: normal Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: Closing due to lack of information -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 27 17:01:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Feb 2012 17:01:51 -0000 Subject: [Varnish] #1100: Assert error in stv_alloc(), stevedore.c line 144 In-Reply-To: <042.63d2077ebde3a5ab8b3d16b5f7a5e9eb@varnish-cache.org> References: <042.63d2077ebde3a5ab8b3d16b5f7a5e9eb@varnish-cache.org> Message-ID: <051.32afba21cfd488352cf8aa15051506c8@varnish-cache.org> #1100: Assert error in stv_alloc(), stevedore.c line 144 -------------------+-------------------------------------------------------- Reporter: Roze | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by Roze): I had checked out the 5773 revision (2011-01-20 09:07:38 +0200 (Thu, 20 Jan 2011)) (since the stable release had similar issues). After the restart I am not able to see the panic.show ouput (I guess its because the master process kills the child): {{{ CLI connected to 127.0.0.1:8000 200 213 ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,3.2.0-rc2-2-default,x86_64,-sfile,-sfile,-smalloc,-hcritbit Type 'help' for command list. Type 'quit' to close CLI session. panic.show 101 44 Unknown request. }}} Varnishstat output kinda resets on each child restart. The interesting thing is I was able to reproduce this even with a small file storage (like 10MB) but then after some SVN checkout it went away, but now it still triggers when the storage is big(ger) and since it happens only when it fills 100% it's hard to catch the right moment. The current output: {{{ client_conn 77600805 422.14 Client connections accepted client_drop 18915 0.10 Connection dropped, no sess/wrk client_req 94600173 514.61 Client requests received cache_hit 90765387 493.75 Cache hits cache_hitpass 112181 0.61 Cache hits for pass cache_miss 3885947 21.14 Cache misses backend_conn 373957 2.03 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 0 0.00 Backend conn. too many backend_fail 194947 1.06 Backend conn. failures backend_reuse 3443070 18.73 Backend conn. reuses backend_toolate 272840 1.48 Backend conn. was closed backend_recycle 3715939 20.21 Backend conn. recycles backend_unused 0 0.00 Backend conn. unused backend_retry 14101 0.08 Backend conn. retry fetch_head 0 0.00 Fetch head fetch_length 3791440 20.62 Fetch with Length fetch_chunked 0 0.00 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 0 0.00 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 0 0.00 Fetch failed fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 0 0.00 Fetch no body (304) n_sess_mem 21987 . N struct sess_mem n_sess 18247 . N struct sess n_object 3459291 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 3460308 . N struct objectcore n_objecthead 3460484 . N struct objecthead n_waitinglist 63846 . N struct waitinglist n_vbc 12 . N struct vbc n_wrk 1030 . N worker threads n_wrk_create 9482 0.05 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 48776 0.27 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 620633 3.38 N queued work requests n_wrk_drop 21564 0.12 N dropped work requests n_backend 1 . N backends n_expired 169782 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_moved 51162886 . N LRU moved objects losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 92153039 501.30 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 77581773 422.03 Total Sessions s_req 94600173 514.61 Total Requests s_pipe 82 0.00 Total pipe s_pass 112209 0.61 Total pass s_fetch 3791440 20.62 Total fetch s_hdrbytes 25728025086 139956.29 Total header bytes s_bodybytes 1262279919691 6866598.41 Total body bytes sess_closed 2211949 12.03 Session Closed sess_pipeline 69946 0.38 Session Pipeline sess_readahead 28511 0.16 Session Read Ahead sess_linger 93978889 511.23 Session Linger sess_herd 99705857 542.38 Session herd shm_records 3738829095 20338.62 SHM records shm_writes 435239256 2367.63 SHM writes shm_flushes 0 0.00 SHM flushes due to overflow shm_cont 4901047 26.66 SHM MTX contention shm_cycles 1427 0.01 SHM cycles through buffer sms_nreq 0 0.00 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 0 . SMS bytes allocated sms_bfree 0 . SMS bytes freed backend_req 3817046 20.76 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_ban 1 . N total active bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 94759999 515.48 HCB Lookups without lock hcb_lock 3727914 20.28 HCB Lookups with lock hcb_insert 3727854 20.28 HCB Inserts esi_parse 0 0.00 Objects ESI parsed (unlock) esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 0 0.00 Accept failures client_drop_late 2649 0.01 Connection dropped late uptime 183829 1.00 Client uptime dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache vmods 0 . Loaded VMODs LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 0 0.00 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 1 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 566851 3.08 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 2 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 7597579 41.33 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 1 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 3997483 21.75 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 0 0.00 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 0 0.00 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 115440 0.63 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 21987 0.12 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 77627872 422.28 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 1339768 7.29 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 124570 0.68 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 8 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 205392462 1117.30 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 3736407 20.33 Created locks LCK.objhdr.destroy 276178 1.50 Destroyed locks LCK.objhdr.locks 379256304 2063.09 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 3982075 21.66 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 61272 0.33 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 3982428 21.66 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 0 0.00 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 1138562 6.19 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 1 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 9818919 53.41 Lock Operations LCK.backend.colls 0 0.00 Collisions SMF.s0.nreq 3629114 19.74 Allocator requests SMF.s0.nobj 3459482 . Outstanding allocations SMF.s0.nbytes 0 . Outstanding bytes SMF.s0.balloc 71045181440 . Bytes allocated SMF.s0.bfree 36329000960 . Bytes free SMF.s0.n_smf 3459526 . N struct smf SMF.s0.n_smf_frag 0 . N small free smf SMF.s0.n_smf_large 44 . N large free smf SMF.s1.nreq 3629041 19.74 Allocator requests SMF.s1.nobj 3459109 . Outstanding allocations SMF.s1.nbytes 0 . Outstanding bytes SMF.s1.balloc 71121489920 . Bytes allocated SMF.s1.bfree 36252692480 . Bytes free SMF.s1.n_smf 3459153 . N struct smf SMF.s1.n_smf_frag 0 . N small free smf SMF.s1.n_smf_large 44 . N large free smf SMA.Transient.nreq 566851 3.08 Allocator requests SMA.Transient.nobj 566851 . Outstanding allocations SMA.Transient.nbytes 707675125 . Outstanding bytes SMA.Transient.balloc 707675125 . Bytes allocated SMA.Transient.bfree 0 . Bytes free VBE.default(10.0.10.2,,8080).vcls 18446744073705461594 . VCL references VBE.default(10.0.10.2,,8080).happy 0 . Happy health probes }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 28 14:31:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Feb 2012 14:31:00 -0000 Subject: [Varnish] #1102: content delivered looks encrypted Message-ID: <045.99dc27835f0e5b7a71acb5d6209a1e56@varnish-cache.org> #1102: content delivered looks encrypted ---------------------------------+------------------------------------------ Reporter: gnollet | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: | ---------------------------------+------------------------------------------ Hi, We have a problem on delivery part of varnishd. Time to time, the browser receive page like gzip or encrypted format, then the result is that the page is not readable, only ascii code appears ont the browser window. The only way to fix the issue is to clear the cache, then we check every 10min our webpages and if we don't find specifi tag on the result, then we clear the URI on varnish. But this solution is not a fix because our customer could see this type of corrupted page between 2 checks. We search if this problem allready occurs but there is no message in this but that's not the case. We don't find anything on our logs also. Do you have any ideas about our problem ? Thanks a lot -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 29 09:46:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Feb 2012 09:46:52 -0000 Subject: [Varnish] #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) In-Reply-To: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> References: <046.a6566484918dbfcafe684a380482e519@varnish-cache.org> Message-ID: <055.5681298c8f07fb2846bab56280e9853d@varnish-cache.org> #1012: 503 error on 200 backend response: FetchError c straight read_error: -1 12 (Cannot allocate memory) -----------------------+---------------------------------------------------- Reporter: rzuidhof | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: major Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by octplane): Hi, We had the same issue and also moved the value to 1000 in hope this will fix the issue. I'd have hoped that varnish would try and nuke objects until it has enough storage. PS: we use a quite small cache size (20G) because we don't want to hit the disk and store small objects along with very larges ones, hence the problem... Cheers, Pierre. -- Ticket URL: Varnish The Varnish HTTP Accelerator