From varnish-bugs at projects.linpro.no Tue Nov 4 12:53:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 04 Nov 2008 12:53:58 -0000 Subject: [Varnish] #367: Varnish child dies Message-ID: <053.7ee57a35f379bae7ae859933f791ed02@projects.linpro.no> #367: Varnish child dies ----------------------+----------------------------------------------------- Reporter: j0nnybe | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: 2.0.1 ----------------------+----------------------------------------------------- From /var/log/syslog on our server: {{{ Nov 4 13:32:32 www6 varnishd[2648]: Child (5711) died signal=6 Nov 4 13:32:32 www6 varnishd[2648]: Child (5711) Panic message: Assert error in exp_timer(), cache_expire.c line 332: Condition(sp->handling == VCL_RET_DISCARD) not true. thread = (cache-timeout) Nov 4 13:32:32 www6 varnishd[2648]: Child cleanup complete Nov 4 13:32:32 www6 varnishd[2648]: child (5793) Started Nov 4 13:32:32 www6 varnishd[2648]: Child (5793) said Closed fds: 4 5 6 10 11 13 14 Nov 4 13:32:32 www6 varnishd[2648]: Child (5793) said Child starts Nov 4 13:32:32 www6 varnishd[2648]: Child (5793) said managed to mmap 1073741824 bytes of 1073741824 Nov 4 13:32:32 www6 varnishd[2648]: Child (5793) said Ready Nov 4 13:37:43 www6 varnishd[2648]: Child (5793) died signal=6 Nov 4 13:37:43 www6 varnishd[2648]: Child (5793) Panic message: Assert error in exp_timer(), cache_expire.c line 332: Condition(sp->handling == VCL_RET_DISCARD) not true. thread = (cache-timeout) Nov 4 13:37:43 www6 varnishd[2648]: Child cleanup complete Nov 4 13:37:43 www6 varnishd[2648]: child (5908) Started Nov 4 13:37:43 www6 varnishd[2648]: Child (5908) said Closed fds: 4 5 6 10 11 13 14 Nov 4 13:37:43 www6 varnishd[2648]: Child (5908) said Child starts Nov 4 13:37:43 www6 varnishd[2648]: Child (5908) said managed to mmap 1073741824 bytes of 1073741824 Nov 4 13:37:43 www6 varnishd[2648]: Child (5908) said Ready Nov 4 13:42:54 www6 varnishd[2648]: Child (5908) died signal=6 Nov 4 13:42:54 www6 varnishd[2648]: Child (5908) Panic message: Assert error in exp_timer(), cache_expire.c line 332: Condition(sp->handling == VCL_RET_DISCARD) not true. thread = (cache-timeout) Nov 4 13:42:54 www6 varnishd[2648]: Child cleanup complete Nov 4 13:42:54 www6 varnishd[2648]: child (6007) Started Nov 4 13:42:54 www6 varnishd[2648]: Child (6007) said Closed fds: 4 5 6 10 11 13 14 Nov 4 13:42:54 www6 varnishd[2648]: Child (6007) said Child starts Nov 4 13:42:54 www6 varnishd[2648]: Child (6007) said managed to mmap 1073741824 bytes of 1073741824 Nov 4 13:42:54 www6 varnishd[2648]: Child (6007) said Ready }}} We use this vcl-config: {{{ backend b1 { .host = "127.0.0.1"; .port = "6081"; } acl purge { "localhost"; } ## Called when a client request is received # #pipe = just a pipe through varnish. No checks whatsoever #pass = Go through all checks -> everything, just dont lookup in the cache sub vcl_recv { # Add a unique header containing the client address unset req.http.X-Forwarded-For; set req.http.X-Forwarded-For = client.ip; ##### always cache these items: ## images if (req.request == "GET" && req.url ~ "\.(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") { set req.backend = b1; lookup; } ## various other content pages if (req.request == "GET" && req.url ~ "\.(css|js)$") { set req.backend = b1; lookup; } ## multimedia if (req.request == "GET" && req.url ~ "\.(svg|swf|mov|avi|wmv)$") { set req.backend = b1; lookup; } #### do not cache these files # if (req.request == "GET" && req.url ~ "\.(cfm)$") { # pass; # } #### do not cache these rules: # pass mode can't handle POST (yet) if (req.request == "POST") { pipe; } if (req.request != "GET" && req.request != "HEAD") { pipe; } if (req.http.Expect) { pipe; } if (req.http.Authenticate || req.http.Authorization) { pass; } #### if there is a purge make sure its coming from $localhost if (req.request == "PURGE") { if(!client.ip ~ purge) { error 405 "Not Allowed"; } purge_url(req.http.X-Purge-Url); error 200 "Purged"; } #### #### unknown function to "normalize the Accept-Encoding headers" if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm unset req.http.Accept-Encoding; } } #### don't cache authenticated sessions if (req.http.Cookie && req.http.Cookie ~ "is_logged_in=") { pipe; } // Varnish doesn't do INM requests so pass it through if no If- Modified-Since was sent if (req.http.If-None-Match && !req.http.If-Modified-Since) { pass; } #### if it passes all these tests, do a lookup anyway; lookup; } # ## Called when entering pipe mode # sub vcl_pipe { pipe; } # ## Called when entering pass mode # sub vcl_pass { pass; } # ## Called when entering an object into the cache # sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; hash; } # ## Called when the requested object was found in the cache # sub vcl_hit { # if (obj.http.X-Cache == "MISS") { # set obj.http.X-Cache = "HIT"; # } if (!obj.cacheable) { pass; } deliver; } # ## Called when the requested object was not found in the cache # sub vcl_miss { fetch; } # ## Called when the requested object has been retrieved from the ## backend, or the request to the backend has failed # sub vcl_fetch { # default time to live for cache objects set obj.ttl = 300s; if (!obj.cacheable) { pass; } if (obj.http.Set-Cookie ~ "is_logged_in=deleted(.*)") { deliver; } if (obj.http.Set-Cookie) { pass; } if (req.request == "GET" && req.url ~ "\.(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") { set obj.ttl = 600s; deliver; } ## various other content pages if (req.request == "GET" && req.url ~ "\.(css|js|html)$") { set obj.ttl = 600s; deliver; } ## multimedia if (req.request == "GET" && req.url ~ "\.(svg|swf|ico|mp3|mp4|m4a|ogg|mov|avi|wmv)$") { set obj.ttl = 600s; deliver; } # for varnish 2.0: # set obj.prefetch = -30s; deliver; } # # ## Called before a cached object is delivered to the client # sub vcl_deliver { deliver; } # ## Called when an object nears its expiry time # sub vcl_timeout { fetch; } # ## Called when an object is about to be discarded # sub vcl_discard { discard; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 5 12:51:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 05 Nov 2008 12:51:53 -0000 Subject: [Varnish] #361: [PATCH] random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.b20f6e01638e7972f58aa6d5f5b67645@projects.linpro.no> #361: [PATCH] random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: fixed Keywords: director | -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3359]) Fix the broken logic in the random directors picking routine. Drop the consistency check for health-changes, at the cost of a slight bias[1] for hosts before, or after, then one that changed health, according to how its health changed. Count all failures to pick against the retry count. Fixes #361 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 6 10:47:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 06 Nov 2008 10:47:33 -0000 Subject: [Varnish] #368: getting errors while loading vcl causes instant death Message-ID: <051.817a8f1a81f6e0fcba8155610af6c117@projects.linpro.no> #368: getting errors while loading vcl causes instant death ----------------------+----------------------------------------------------- Reporter: pj0tr | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- passing a directory to vcl.load makes varnish die without giving any error message. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 6 11:46:32 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 06 Nov 2008 11:46:32 -0000 Subject: [Varnish] #359: regsub documented as using $1, $2 etc, but actually uses \1, \2 for replacement strings In-Reply-To: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> References: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> Message-ID: <061.eab677cb08d6a8a2e994ad752ea36e8e@projects.linpro.no> #359: regsub documented as using $1,$2 etc, but actually uses \1, \2 for replacement strings ---------------------------+------------------------------------------------ Reporter: eugaia | Owner: Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: regsub | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [3361]) Fix up $N vs \N in man page The VCL man page documented the capturing parentheses as using $N rather than \N which is actually used. Fixes #359 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 6 11:57:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 06 Nov 2008 11:57:06 -0000 Subject: [Varnish] #362: Add malloc size option to varnishd.1 manual page In-Reply-To: <048.6d6293d69bbb64b321d0094c7f25f6f5@projects.linpro.no> References: <048.6d6293d69bbb64b321d0094c7f25f6f5@projects.linpro.no> Message-ID: <057.15965c77a1058f2c50f25923e082b5b9@projects.linpro.no> #362: Add malloc size option to varnishd.1 manual page ---------------------------+------------------------------------------------ Reporter: mm | Owner: phk Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [3362]) Document the size parameter to -s malloc Fixes #362 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 6 19:57:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 06 Nov 2008 19:57:33 -0000 Subject: [Varnish] #365: Calling "restart" from "vcl_hit" serves an empty request. In-Reply-To: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> References: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> Message-ID: <062.7e32734a98b8484ba30feccd0fd523d9@projects.linpro.no> #365: Calling "restart" from "vcl_hit" serves an empty request. ----------------------+----------------------------------------------------- Reporter: nkallen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by nkallen): Here is a failing test: test "Test restarts in vcl_hit" server s { rxreq expect req.url == "/foo" txresp -status 200 } -start varnish v -vcl+backend { sub vcl_hit { set obj.ttl = 0s; restart; } } -start client c1 { txreq -url "/foo" rxresp expect resp.status == 200 txreq -url "/foo" rxresp expect resp.status == 200 } -run -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 11:15:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 11:15:01 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down Message-ID: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- We would like to be able to serve graced objects if the backend health polling says the backend is down. Its not clear to me whether this should happen automatically or if it should be done explicitly in vcl ( if !req.backend.healthy { lookup;} ). It seems to be a minor job enabling this (from my limited understanding of the code) but it would be a huge enhancement for varnish. Per. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 11:54:45 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 11:54:45 -0000 Subject: [Varnish] #355: grace not documented In-Reply-To: <050.8925fc4ff5931834e2a641a3ee266395@projects.linpro.no> References: <050.8925fc4ff5931834e2a641a3ee266395@projects.linpro.no> Message-ID: <059.019714887ef578184d9d4851f71fbc58@projects.linpro.no> #355: grace not documented ---------------------------+------------------------------------------------ Reporter: eric | Owner: tfheen Type: documentation | Status: new Priority: low | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: Keywords: vcl grace | ---------------------------+------------------------------------------------ Changes (by perbu): * owner: => tfheen Comment: {{{ .Ss Grace If the backend takes a long time do generate an object there is a risk of a thread pile up. In order to mitigate this you can enable "grace". Grace allows varnish to serve an expired version of the object while a fresh object is being generated by the backend. The following vcl code will enable varnish to served expired object. All object will be kept up to two minutes past their expiration time unless a fresh object is generated. .Bd -literal -offset 4n sub vcl_recv { set req.grace = 2m; } sub vcl_fetch { set obj.grace = 2m; } .Ed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 12:04:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 12:04:50 -0000 Subject: [Varnish] #291: Default.vcl In-Reply-To: <054.6d1fc28d069a1c4393afd6c5bed06e2b@projects.linpro.no> References: <054.6d1fc28d069a1c4393afd6c5bed06e2b@projects.linpro.no> Message-ID: <063.88908bbcde538b1bc8f28fd22413f0cf@projects.linpro.no> #291: Default.vcl ---------------------------+------------------------------------------------ Reporter: The_ZoRo | Owner: des Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ---------------------------+------------------------------------------------ Changes (by perbu): * status: new => closed * resolution: => wontfix Comment: The RPM package I have installed consists of two default.vcl files. One in /etc/varnish and one in /usr/share/doc/varnish-2.0.1/examples/default.vcl This is not confusing, in my opinion. These two files will of course be four if you check out the source as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 12:29:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 12:29:42 -0000 Subject: [Varnish] #100: Setting the TTL does not adjust Expires: header In-Reply-To: <049.f779265ea82196cf4acaa40d47ee6ca5@projects.linpro.no> References: <049.f779265ea82196cf4acaa40d47ee6ca5@projects.linpro.no> Message-ID: <058.5a8f466fe5923bf27ab59daac45a747c@projects.linpro.no> #100: Setting the TTL does not adjust Expires: header ----------------------+----------------------------------------------------- Reporter: des | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by perbu): I can't see why varnish should bother with the Expires: header. Can't you just add the header with VCL as you manipulate the object's TTL? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 17:54:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 17:54:50 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.56c4faa5b8a7c52897a1e33dac1e3ee0@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by anders): I also want to be able to serve graced objects, and to control it from VCL. Please give us force_grace! Excerpt from IRC conversation: {{{ phk: is it hard to lift the limitation on the grace that the object +has to be busy in order for the graced object to be served? I understand that normally the limitation should be in place - but +when the backend is down it would be really useful. i've tried forcing a lookup in vcl - but it doesn't seem to respect +that. perbu, yes, we should grace when the polling marks the backend down as +well. perbu, open a ticket so we remember phk: ack. > This is very interesting for me too. > It would be nice to control this grace in VCL as well, not just because of +polling. For example if replies from the backend have the wrong http code, +grace would be preferred.. > In such situations, it would preferable to deliver the graced object, and +even extend the grave time.. :) anordby, in that case, you need to do a restart to take another attempt anordby, we are simply too far down the road at that time to make a +determination or said another way: we would have to do exactly the same work as you +end up doing with restart > phk: If all backends fail at around the same time, restart does not help. anordby, the trick is to make the restart do grace before trying to +contact the backend. > Yes. But something needs to be done for that to happen, I suppose ? I guess you're right, we need to say "don't even try, just grace" > I just recently started to play with Varnish' load balancing ability. > One thing I found out quickly, default interval is 0? Meaning it'll poll as +often as possible, if interval is not defined? This lead to huge amounts of +traffic and CPU usage way beyond expected. :-) > Maybe there should be a default .interval of one or two seconds? anordby, ticket > Ok, I will. There could also be some issues related to loading VCL runtime, +I'll check that too. > It would be nice to also say "try restart 2 times, then grace" in VCL. well, you can, it would be something like "sub vcl_recv { if (req. +restart == 3) { force_grace; }} s/restart/&s/, though > Amen > (Let it happen) :) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 19:19:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 19:19:23 -0000 Subject: [Varnish] #370: varnishadm set up Message-ID: <051.ce3d60c95fc0f66fd5737c9771e77a0c@projects.linpro.no> #370: varnishadm set up -------------------------+-------------------------------------------------- Reporter: perbu | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: packaging | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- Hi. On my home installation of varnish I have aliased va to "varnishadm -T localhost:6082". You could consider letting a wrapper source the configuration (in /etc/sysconfig or /etc/default) in order to pass this option to varnishadm. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 22:11:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 22:11:33 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.468c911457ddccabe83ea508224b468b@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by anders): * cc: anders at fupp.net (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 8 22:12:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 08 Nov 2008 22:12:13 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.cb0f6a9267181f26220ae1416b7dc44d@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by anders): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Nov 9 15:25:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 09 Nov 2008 15:25:38 -0000 Subject: [Varnish] #371: Typo in .spec file Message-ID: <051.f4d5751303b2a81d04c2250b571b099a@projects.linpro.no> #371: Typo in .spec file -------------------+-------------------------------------------------------- Reporter: zenon | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: minor Keywords: | -------------------+-------------------------------------------------------- The .spec file distributed with 2.0.1 defines 2.0 as the version. This causes rpm to search for the source tarball varnish-2.0.tar.gz and breaks building. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Nov 9 17:21:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 09 Nov 2008 17:21:13 -0000 Subject: [Varnish] #371: Typo in .spec file In-Reply-To: <051.f4d5751303b2a81d04c2250b571b099a@projects.linpro.no> References: <051.f4d5751303b2a81d04c2250b571b099a@projects.linpro.no> Message-ID: <060.2fe586b6cbf2f1548d8e07ece473aa69@projects.linpro.no> #371: Typo in .spec file -----------------------+---------------------------------------------------- Reporter: zenon | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: trunk Severity: minor | Resolution: Keywords: | -----------------------+---------------------------------------------------- Changes (by perbu): * owner: => ingvar * component: build => packaging -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 05:45:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 05:45:05 -0000 Subject: [Varnish] #372: varnish dies Message-ID: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------------+----------------------------------------------- Below errors from /var/log/messeges/ Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) died signal=6 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) Panic message: Assert error in STV_alloc(), stevedore.c line 71: Condition((st) != NULL) not true. thread = (cache-worker)sp = 0x5ec4c004 { fd = 190, id = 190, xid = 2128188541, client = 117.98.38.99:1529, step = STP_FETCH, handling = DISCARD, ws = 0x5ec4c04c { id = "sess", {s,f,r,e} = {0x5ec4c4dc,,+600,(nil),+8192}, }, worker = 0x4cbe3170 { }, vcl = { srcname = { "/etc/varnish/rediff.vcl", "Default", }, }, obj = 0x757f1000 { refcnt = 1, xid = 2128188541, ws = 0x757f1018 { id = "obj", {s,f,r,e} = {0x757f11ec,,+186,(nil),+7700}, }, http = { ws = 0x757f1018 { id = "obj", {s,f,r,e} = {0x757f11ec,,+186,(nil),+7700}, }, hd = { "Date: Sun, 09 Nov 2008 05:06:46 GMT", "Server: Apache", "X-Powered- By: PHP/5.1.4", "Expires: Mon, 09 Nov 2009 05:06:46 GMT", "Cache-Control: max-age=31536000", Nov 9 05:06:54 monitoring-bt varnishd[10256]: child (29841) Started Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Closed fds: 4 5 6 10 11 13 14 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Child starts Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said managed to mmap 1073741824 bytes of 1073741824 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Ready -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 10:07:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 10:07:30 -0000 Subject: [Varnish] #361: [PATCH] random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.a7f78c039dcb182c2fb801a8e1f76e1d@projects.linpro.no> #361: [PATCH] random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: fixed Keywords: director | -----------------------+---------------------------------------------------- Comment (by tfheen): (In [3369]) Merge r3359: Fix the broken logic in the random directors picking routine. Drop the consistency check for health-changes, at the cost of a slight bias[1] for hosts before, or after, then one that changed health, according to how its health changed. Count all failures to pick against the retry count. Fixes #361 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 11:55:18 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 11:55:18 -0000 Subject: [Varnish] #368: getting errors while loading vcl causes instant death In-Reply-To: <051.817a8f1a81f6e0fcba8155610af6c117@projects.linpro.no> References: <051.817a8f1a81f6e0fcba8155610af6c117@projects.linpro.no> Message-ID: <060.e5b58d55583fa7deff8f3ec756be5c89@projects.linpro.no> #368: getting errors while loading vcl causes instant death ----------------------+----------------------------------------------------- Reporter: pj0tr | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [3378]) Make sure the VCL we try to load is a regular file Fixes #368 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:11:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:11:17 -0000 Subject: [Varnish] #372: varnish dies In-Reply-To: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> References: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> Message-ID: <069.e50637eeafc6d9b55e2b204c9bebb249@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Old description: > Below errors from /var/log/messeges/ > > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) died > signal=6 > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) Panic > message: Assert error in STV_alloc(), stevedore.c line 71: > Condition((st) != NULL) not true. thread = (cache-worker)sp = 0x5ec4c004 > { fd = 190, id = 190, xid = 2128188541, client = 117.98.38.99:1529, > step = STP_FETCH, handling = DISCARD, ws = 0x5ec4c04c { id = > "sess", {s,f,r,e} = {0x5ec4c4dc,,+600,(nil),+8192}, }, worker = > 0x4cbe3170 { }, vcl = { srcname = { > "/etc/varnish/rediff.vcl", "Default", }, }, obj = > 0x757f1000 { refcnt = 1, xid = 2128188541, ws = 0x757f1018 { > id = "obj", {s,f,r,e} = {0x757f11ec,,+186,(nil),+7700}, }, > http = { ws = 0x757f1018 { id = "obj", {s,f,r,e} = > {0x757f11ec,,+186,(nil),+7700}, }, hd = { "Date: Sun, > 09 Nov 2008 05:06:46 GMT", "Server: Apache", "X-Powered- > By: PHP/5.1.4", "Expires: Mon, 09 Nov 2009 05:06:46 GMT", > "Cache-Control: max-age=31536000", > Nov 9 05:06:54 monitoring-bt varnishd[10256]: child (29841) Started > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Closed > fds: 4 5 6 10 11 13 14 > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Child > starts > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said managed > to mmap 1073741824 bytes of 1073741824 > Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Ready New description: Below errors from /var/log/messeges/ {{{ Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) died signal=6 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29309) Panic message: Assert error in STV_alloc(), stevedore.c line 71: Condition((st) != NULL) not true. thread = (cache-worker)sp = 0x5ec4c004 { fd = 190, id = 190, xid = 2128188541, client = 117.98.38.99:1529, step = STP_FETCH, handling = DISCARD, ws = 0x5ec4c04c { id = "sess", {s,f,r,e} = {0x5ec4c4dc,,+600,(nil),+8192}, }, worker = 0x4cbe3170 { }, vcl = { srcname = { "/etc/varnish/rediff.vcl", "Default", }, }, obj = 0x757f1000 { refcnt = 1, xid = 2128188541, ws = 0x757f1018 { id = "obj", {s,f,r,e} = {0x757f11ec,,+186,(nil),+7700}, }, http = { ws = 0x757f1018 { id = "obj", {s,f,r,e} = {0x757f11ec,,+186,(nil),+7700}, }, hd = { "Date: Sun, 09 Nov 2008 05:06:46 GMT", "Server: Apache", "X-Powered- By: PHP/5.1.4", "Expires: Mon, 09 Nov 2009 05:06:46 GMT", "Cache-Control: max-age=31536000", Nov 9 05:06:54 monitoring-bt varnishd[10256]: child (29841) Started Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Closed fds: 4 5 6 10 11 13 14 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Child starts Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said managed to mmap 1073741824 bytes of 1073741824 Nov 9 05:06:54 monitoring-bt varnishd[10256]: Child (29841) said Ready }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:14:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:14:23 -0000 Subject: [Varnish] #372: varnish dies In-Reply-To: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> References: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> Message-ID: <069.99b5693c49af224a58fcd4961ebbe2e5@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: It looks like you have simply run out of storage. Try to give more space to the -s argument or make sure the LRU mechanism gets to clean up. If this does not solve your problem, please report full details: arguments, VCL (if any) and varnishstat output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:29:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:29:37 -0000 Subject: [Varnish] #370: varnishadm set up In-Reply-To: <051.ce3d60c95fc0f66fd5737c9771e77a0c@projects.linpro.no> References: <051.ce3d60c95fc0f66fd5737c9771e77a0c@projects.linpro.no> Message-ID: <060.76f035c4a4818ff1a130f8a1d65bd2bc@projects.linpro.no> #370: varnishadm set up -------------------------+-------------------------------------------------- Reporter: perbu | Owner: Type: enhancement | Status: closed Priority: low | Milestone: Component: packaging | Version: trunk Severity: minor | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: In general we don't want to have global configuration files like that for Varnish, because it makes running multiple instances more cumbersome. I also find that adding a config file to capture one argument which can trivially be put in a shellscript or shell alias to be overkill. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:43:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:43:55 -0000 Subject: [Varnish] #367: Varnish child dies In-Reply-To: <053.7ee57a35f379bae7ae859933f791ed02@projects.linpro.no> References: <053.7ee57a35f379bae7ae859933f791ed02@projects.linpro.no> Message-ID: <062.b4972bff8c1bce600200cf229cee3885@projects.linpro.no> #367: Varnish child dies ----------------------+----------------------------------------------------- Reporter: j0nnybe | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: 2.0.1 | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Remove your vcl_timeout function, that is not supported yet. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:44:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:44:46 -0000 Subject: [Varnish] #366: CLI Communication Error when calling vcl.discard in management interface In-Reply-To: <052.1727b4b0db11f5c555d134fb64c4b0fd@projects.linpro.no> References: <052.1727b4b0db11f5c555d134fb64c4b0fd@projects.linpro.no> Message-ID: <061.2da2792d9bf0676e303e64e9eba01c42@projects.linpro.no> #366: CLI Communication Error when calling vcl.discard in management interface -------------------------------------------------------------+-------------- Reporter: foxdie | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: cli, communication, error, vcl.discard, discard | -------------------------------------------------------------+-------------- Comment (by phk): Could you please check that there is not a core dump happening behind the scenes ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:46:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:46:30 -0000 Subject: [Varnish] #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: In-Reply-To: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> References: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> Message-ID: <058.fd4d13a7d6c75a9a47f6d42d8e36ea57@projects.linpro.no> #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): This looks like you are running out of workspace for the hash-string construction. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:47:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:47:37 -0000 Subject: [Varnish] #371: Typo in .spec file In-Reply-To: <051.f4d5751303b2a81d04c2250b571b099a@projects.linpro.no> References: <051.f4d5751303b2a81d04c2250b571b099a@projects.linpro.no> Message-ID: <060.805796269d55aca97fa93b624486b413@projects.linpro.no> #371: Typo in .spec file -----------------------+---------------------------------------------------- Reporter: zenon | Owner: ingvar Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: trunk Severity: minor | Resolution: fixed Keywords: | -----------------------+---------------------------------------------------- Changes (by ingvar): * status: new => closed * resolution: => fixed Comment: Fixed in trunk (2.0.2). Will also be in 2.0.2 when released, I hope. Note that you may also get precompiled packages (with issues like this already found and fixed) from EPEL, see for example http://download.fedora.redhat.com/pub/epel/testing/5/x86_64/ varnish will be merged into EPEL's "stable" release in november or december. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 10 12:47:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 10 Nov 2008 12:47:57 -0000 Subject: [Varnish] #363: The first POST request is replaced by GET In-Reply-To: <053.a1f0b750ba0de527247294d34b1f6df0@projects.linpro.no> References: <053.a1f0b750ba0de527247294d34b1f6df0@projects.linpro.no> Message-ID: <062.a5a02d12c922bf05d6cb34237e274940@projects.linpro.no> #363: The first POST request is replaced by GET ----------------------+----------------------------------------------------- Reporter: tcouery | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: 2.0 Severity: normal | Resolution: wontfix Keywords: POST | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: Yes, you asked for that, implicitly, in vcl_recv{} when you did not do a "pass" on the POST request. This is expected behaviour under such circumstances. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 11 09:00:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Nov 2008 09:00:20 -0000 Subject: [Varnish] #373: Varnish fails to reload backend/directory Message-ID: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> #373: Varnish fails to reload backend/directory ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When reloading VCL by using vcl.load and vcl.use, Varnish fails to update which hosts to probe. Given this VCL: {{{ backend kart3d1 { .host = "192.168.41.134"; .port = "80"; .probe = { .request = "GET /varnish-lb-check.html HTTP/1.1" "Host: foo.bars.no" "Connection: close"; .timeout = 5s; .window = 8; .threshold = 3; .interval = 2s; } } backend kart3d2 { .host = "192.168.41.135"; .port = "80"; .probe = { .request = "GET /varnish-lb-check.html HTTP/1.1" "Host: foo.bars.no" "Connection: close"; .timeout = 5s; .window = 8; .threshold = 3; .interval = 2s; } } director kart3dlb random { { .backend = kart3d1; .weight = 100; } { .backend = kart3d2; .weight = 100; } } }}} If one backend is commented out (as backend, and in the directory), and VCL is reloaded, Varnish still polls it. If the host header is updated, a full restart of Vartnish is also necessary. Conclusion: it seems Varnish is unable to update backend/director runtime, without a restart. It would be nice to have this fixed, so that cache servers with a large dataset do not lose their data because of load balancing changes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 11 15:59:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Nov 2008 15:59:07 -0000 Subject: [Varnish] #373: Varnish fails to reload backend/directory In-Reply-To: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> References: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> Message-ID: <061.3cfb53a47f659456a88edcad8316d4e1@projects.linpro.no> #373: Varnish fails to reload backend/directory ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Folowing up on questions from Tollef: {{{ * anordby is having problems getting Varnish to update backend/director +runtime. New ticket, 373. anordby: even if you vcl.discard the old config? * anordby thought vcl.use would do. I can check if discard makes any +difference. we continue checking all defined backends, since you might +reasonably want to switch to them and having them all be down then would be +bad. > Well. If I have two, and I remove one from the config and reload? Then I +expect Varnish to stop probing the one removed. reload as in, vcl.load foo /etc/varnish/foo.vcl ; vcl.use foo ; +vcl.discard boot? or reload as in vcl.load foo /etc/varnish/foo.vcl ; vcl.use foo? }}} Answer: yes, I reloaded config, and discarded the old one. Varnish keeps checking the backend that has been commented out. An example of how I reloaded: {{{ # telnet localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. vcl.list 200 69 available 0 boot discarded 6 run2 active 15 run3 vcl.load run4 /usr/local/etc/varnish.vcl 200 13 VCL compiled. vcl.use run4 200 0 vcl.discard run3 200 0 vcl.list 200 92 available 0 boot discarded 6 run2 discarded 3 run3 active 12 run4 quit 500 22 Closing CLI connection Connection closed by foreign host. }}} What I said about the host header being updated in the probe definition seems wrong however, you can disregard that. By the way: it would be nice to be able to check the status of Varnish' load balancing: which host is in/out, etc. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 11 16:04:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Nov 2008 16:04:57 -0000 Subject: [Varnish] #373: Varnish fails to reload backend/directory In-Reply-To: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> References: <052.97a4618163e5031ea84f8aa8a5cdbbf4@projects.linpro.no> Message-ID: <061.9eabe5dbf3a055e4127c64593f050abf@projects.linpro.no> #373: Varnish fails to reload backend/directory ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Uhm. Sorry. But, for some reason, while changing the probe definition, some requests are updated according to the VCL, but some are not. Checking with ngrep, I see that every second probe against the same server uses a probe is no longer in the loaded VCL: {{{ T 192.168.41.132:61629 -> 192.168.41.137:80 [AP] GET /varnish-lb-check.html HTTP/1.1. Host: foo.bars.no. Connection: close. . ### T 192.168.41.137:80 -> 192.168.41.132:61629 [AP] HTTP/1.1 200 OK. Connection: close. Content-Type: text/html. ETag: "6940323574995064302". Accept-Ranges: bytes. Last-Modified: Tue, 04 Nov 2008 19:58:26 GMT. Content-Length: 47. Date: Tue, 11 Nov 2008 15:59:34 GMT. Server: lighttpd/1.4.13. .

Works fine.

###### T 192.168.41.132:57516 -> 192.168.41.137:80 [AP] GET /xvarnish-lb-check.html HTTP/1.1. Host: baz.bars.no. Connection: close. . ### T 192.168.41.137:80 -> 192.168.41.132:57516 [AP] HTTP/1.1 404 Not Found. Connection: close. Content-Type: text/html. Content-Length: 345. Date: Tue, 11 Nov 2008 15:59:36 GMT. Server: lighttpd/1.4.13. . 404 - Not Found

404 - Not Found

###### T 192.168.41.132:63120 -> 192.168.41.137:80 [AP] GET /varnish-lb-check.html HTTP/1.1. Host: foo.bars.no. Connection: close. . ### T 192.168.41.137:80 -> 192.168.41.132:63120 [AP] HTTP/1.1 200 OK. Connection: close. Content-Type: text/html. ETag: "6940323574995064302". Accept-Ranges: bytes. Last-Modified: Tue, 04 Nov 2008 19:58:26 GMT. Content-Length: 47. Date: Tue, 11 Nov 2008 15:59:37 GMT. Server: lighttpd/1.4.13. .

Works fine.

##^Cexit }}} So we have a problem with updating the probes also, not only commenting in/out a backend. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 11 19:06:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Nov 2008 19:06:56 -0000 Subject: [Varnish] #365: Calling "restart" from "vcl_hit" serves an empty request. In-Reply-To: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> References: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> Message-ID: <062.a855890e2929fe380cf6ead7c2ef0ec1@projects.linpro.no> #365: Calling "restart" from "vcl_hit" serves an empty request. ----------------------+----------------------------------------------------- Reporter: nkallen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3386]) Implement restart in vcl_hit. Fixes #365 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 11 21:57:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 11 Nov 2008 21:57:50 -0000 Subject: [Varnish] #374: Implement restart in vcl_error Message-ID: <053.fd2fc11de17ab07a4a0b42ad6d8273db@projects.linpro.no> #374: Implement restart in vcl_error ----------------------+----------------------------------------------------- Reporter: tcouery | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Keywords: restart vcl_error ----------------------+----------------------------------------------------- It would be very interesting to use restart in vcl_error to switch to a new backend when a server is down. We can't use restart in vcl_fetch when the server is down because vcl_fetch is never called. sub vcl_error { if (obj.status = 503) { restart; } } -- Ticket URL: Varnish The Varnish HTTP Accelerator From jxh_ty at 163.com Sat Nov 1 07:46:39 2008 From: jxh_ty at 163.com (=?gbk?B?va/Qwruq?=) Date: Sat, 1 Nov 2008 15:46:39 +0800 (CST) Subject: many connecting,the varnish doesn't work more... Message-ID: <17669224.207871225525599009.JavaMail.coremail@bj163app34.163.com> Dear: I use "Microsoft Web Application Stress Tool" to test the varnish 2.0.1.When I set the stress level(threads)=800,the varnish doesn't work more.Even I stop the test,it will not work too,until I restart the varnish.Why varnish doesn't work in a mult-threads EVN? While I use Nginx as the proxy ,I set the stress level(threads)=3000or more?It works very well. Please tell me what to do. /usr/local/sbin/varnishd -a 0.0.0.0:80 -s malloc,3.5G -f /root/default2.vcl -p thread_pool_max=10000 -p thread_pools=16 -h classic,10000 -p client_http11=on -p auto_restart=on -p backend_http11=on -w 16,10000,60 -p default_ttl=360 -p ping_interval=3 -p listen_depth=10000 -p obj_workspace=10960 -p user=varnish -p group=varnish -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Thu Nov 13 12:36:45 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 13 Nov 2008 12:36:45 -0000 Subject: [Varnish] #375: Secure communication between Client Browser and Varnish. Message-ID: <053.a0a53655033e615613b4b7acc1ae8533@projects.linpro.no> #375: Secure communication between Client Browser and Varnish. ---------------------+------------------------------------------------------ Reporter: tuhintt | Type: enhancement Status: new | Priority: normal Milestone: Later | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ We know Browser client like ie, firefox or any other browser client and proxy server communication is plain text format or there is no encryption between them. Between client browser and proxy server (reverse or caching or web proxy) communication can be sniff by anyone and get the data passing between them. like Squid proxy. Is there any feature in Varnish to communicate with browser client in a secure way. Say, when a browser client first time communicate with Varnish, they will create a random key to to encrypt the data communication and secure the data between them. there may not necessary to have server/client certificate. we know lots of people like me looking for a secure proxy server solution like me. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 14 00:19:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 14 Nov 2008 00:19:34 -0000 Subject: [Varnish] #210: The binary heap implementation does not scale In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> Message-ID: <058.79708e91d22c0c6a74326880799b0da6@projects.linpro.no> #210: The binary heap implementation does not scale -------------------------+-------------------------------------------------- Reporter: phk | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3390]) Rework the binary heap, we use for expiry processing, to deal more gracefully with large number of objects. Previously we kept all objects in a single array which resultined in increasingly infrequent but increasingly demanding calls to calloc(3) with the consequent massive memory copies. We also did not release memory again if unused. Now we stripe the array into rows of 64k objects each. This number is a compromise between space wastage, max 1MB on a 64bit machine, and the desire to not add and delete rows all the time. With 64k objects in a row, even on a very busy server would only add a new row every 5...10 seconds during ramp up. Delete unused rows, but keep a hysteresis of an entire empty row to avoid silly add-delete-add-delete-add-delete behaviour at row boundaries. Streamline some of the functions a bit. Fixes #210 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 14 13:32:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 14 Nov 2008 13:32:01 -0000 Subject: [Varnish] #376: Varnish core-dumps on ctrl-c Message-ID: <052.e6b196f75eb9cb191e0cd030b908f316@projects.linpro.no> #376: Varnish core-dumps on ctrl-c ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Running Varnish trunk 3390, it core-dumps if I press control+c: {{{ Missing errorhandling code in mgt_vcc_del(), mgt_vcc.c line 314: Condition((unlink(vp->fname)) == 0) not true. errno = 2 (No such file or directory) }}} Backtrace: {{{ (gdb) bt #0 0x0000000800da4dec in kill () from /lib/libc.so.7 #1 0x0000000800da3c5b in abort () from /lib/libc.so.7 #2 0x000000080067342c in lbv_assert_default ( func=0xf07d
, file=0x6
, line=0, cond=0x800da4e0c "r\001?H\213\r\n\230\022", err=2, xxx=-8472) at assert.c:61 #3 0x000000000042aee8 in mgt_vcc_del (vp=0x800f200e0) at mgt_vcc.c:314 #4 0x000000000042c00b in mgt_vcc_atexit () at mgt_vcc.c:459 #5 0x0000000800d86824 in __cxa_finalize () from /lib/libc.so.7 #6 0x0000000800d38b17 in exit () from /lib/libc.so.7 #7 0x0000000000426c85 in mgt_sigint (e=Variable "e" is not available. ) at mgt_child.c:492 #8 0x00000008006760fb in vev_sched_signal (evb=0x800f16100) at vev.c:437 #9 0x00000008006766c8 in vev_schedule (evb=0x800f16100) at vev.c:365 #10 0x0000000000427941 in mgt_run (dflag=2, T_arg=Variable "T_arg" is not available. ) at mgt_child.c:560 #11 0x0000000000431dfa in main (argc=41, argv=0x7fffffffe580) at varnishd.c:632 }}} This is in FreeBSD/amd64 7.0-RELEASE. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 15 04:06:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 15 Nov 2008 04:06:44 -0000 Subject: [Varnish] #377: Varnish sending empty http packets to the backend Message-ID: <053.525a6b24070245046748eee1a31218fa@projects.linpro.no> #377: Varnish sending empty http packets to the backend ---------------------+------------------------------------------------------ Reporter: ibrezac | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Varnish Version: 2.0.2[[BR]] OS: Solaris 10 x86-64 (amd64) U4[[BR]] Compiler: Sun Studio 12 (varnish does not compile with gcc 3.4.3)[[BR]] Behavior is the same using 32 or 64-bit builds[[BR]] [[BR]] Using a very simple vcl: {{{ backend default { .host = "10.16.3.132"; .port = "80"; } }}} {{{ varnishd -F -f /var/tmp/default.vcl storage_file: filename: ./varnish.4QaOMW (unlinked) size 202849 MB. Using old SHMFILE child (24891) Started Child (24891) said Closed fds: 3 5 9 10 12 13 Child (24891) said Child starts Child (24891) said managed to mmap 212703117312 bytes of 212703117312 Child (24891) said Ready }}} The backend server (apache) is not getting requests from varnish. I inspected traffic on the wire and varnish is sending empty HTTP packets. {{{ 0.97 SessionOpen 127.0.0.1 61524 :80 0.97 ReqStart 127.0.0.1 61524 728026802 0.97 RxRequest GET 0.97 RxURL / 0.97 RxProtocol HTTP/1.0 0.97 RxHeader User-Agent: Wget/1.10.2 0.97 RxHeader Accept: */* 0.97 RxHeader Host: www.ypass.net 0.97 RxHeader Connection: Keep-Alive 0.97 VCL_call recv 0.97 VCL_return lookup 0.97 VCL_call hash 0.97 VCL_return hash 0.97 VCL_call miss 0.97 VCL_return fetch 0.97 VCL_call error 0.97 Length 452 0.97 VCL_call deliver 0.97 TxProtocol HTTP/1.1 0.97 TxStatus 503 0.97 TxResponse Service Unavailable 0.97 TxHeader Server: Varnish }}} I'd be happy to provide more information. Thanks,[[BR]] -Igor -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 17 08:06:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 17 Nov 2008 08:06:03 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.0e4f2077e1d34310f9546afb8b390aac@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): what's meaning about 'pfault' state ? In the 'pfault' state, varnishd freeze {{{ [xiaoyong at HP08020020 ~]$ top last pid: 88414; load averages: 0.04, 0.01, 0.00 up 3+22:38:54 15:43:18 116 processes: 1 running, 113 sleeping, 2 waiting CPU states: 0.0% user, 0.0% nice, 1.8% system, 0.0% interrupt, 98.2% idle Mem: 3042M Active, 393M Inact, 467M Wired, 11M Cache, 214M Buf, 3880K Free Swap: 8192M Total, 771M Used, 7421M Free, 9% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 64105 root 81 76 0 122G 3418M pfault 1 458:20 0.00% varnishd 522 root 1 44 0 4684K 0K WAIT 0 0:31 0.00% 692 root 1 8 0 6212K 440K wait 0 0:15 0.00% sh 691 root 4 -8 0 29136K 1748K piperd 0 0:05 0.00% cfexecd 629 root 1 44 0 10576K 672K select 0 0:04 0.00% sendmail 781 root 1 8 0 5736K 284K nanslp 1 0:02 0.00% cron 64104 root 1 44 0 92456K 0K WAIT 2 0:01 0.00% ...... [xiaoyong at HP08020020 ~]$ varnishstat 3+03:40:07 HP08020020 Hitrate ratio: 10 62 62 Hitrate avg: 0.9531 0.9225 0.9225 89060003 0.00 326.94 Client connections accepted 166199493 0.00 610.11 Client requests received 163787382 0.00 601.26 Cache hits 19639 0.00 0.07 Cache hits for pass 2372107 0.00 8.71 Cache misses 2391813 0.00 8.78 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 0 0.00 0.00 Backend connections failures 2356930 0.00 8.65 Backend connections reuses 2382545 0.00 8.75 Backend connections recycles 0 0.00 0.00 Backend connections unused 8052 . . N struct srcaddr 18446744073709551221 . . N active struct srcaddr 10262 . . N struct sess_mem 4490 . . N struct sess 2028461 . . N struct object 2029034 . . N struct objecthead 4040453 . . N struct smf 2 . . N small free smf 21 . . N large free smf 18 . . N struct vbe_conn 681 . . N struct bereq 78 . . N worker threads 10155 0.00 0.04 N worker threads created 0 0.00 0.00 N worker threads not created 358964 0.00 1.32 N worker threads limited 0 0.00 0.00 N queued work requests 1952453 0.00 7.17 N overflowed work requests 17350716 0.00 63.69 N dropped work requests 2 . . N backends 330156 . . N expired objects 0 . . N LRU nuked objects 0 . . N LRU saved objects 4363790 . . N LRU moved objects 0 . . N objects on deathrow 0 0.00 0.00 HTTP header overflows }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 17 09:31:11 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 17 Nov 2008 09:31:11 -0000 Subject: [Varnish] #378: unresonable varnish free smf number Message-ID: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> #378: unresonable varnish free smf number ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: blocker | Keywords: ----------------------+----------------------------------------------------- varnish stopped responding and a wget "localhost" timeouts and no reply received. I noticed a value of the stats probe is strange: 18446744073709551573 N small free smf Is it reasonable? # telnet localhost 6000 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. stats 200 2733 2633573 Client connections accepted 2633564 Client requests received 872254 Cache hits 57 Cache hits for pass 1460964 Cache misses 1712598 Backend connections success 0 Backend connections not attempted 0 Backend connections too many 80 Backend connections failures 2 Backend connections reuses 11310 Backend connections recycles 0 Backend connections unused 3 N struct srcaddr 3 N active struct srcaddr 131052 N struct sess_mem 48034 N struct sess 262 N struct object 264 N struct objecthead 61 N struct smf 18446744073709551573 N small free smf 1 N large free smf 1 N struct vbe_conn 74 N struct bereq 40 N worker threads 382 N worker threads created 0 N worker threads not created 316 N worker threads limited 0 N queued work requests 5757 N overflowed work requests 0 N dropped work requests 5 N backends 1460570 N expired objects 0 N LRU nuked objects 0 N LRU saved objects 0 N LRU moved objects 0 N objects on deathrow 0 HTTP header overflows 0 Objects sent with sendfile 2327561 Objects sent with write 0 Objects overflowing workspace 2633572 Total Sessions 2633564 Total Requests 251433 Total pipe 389 Total pass 1460960 Total fetch 882556140 Total header bytes 20790925758 Total body bytes 2585539 Session Closed 0 Session Pipeline 0 Session Read Ahead 0 Session Linger 0 Session herd 179969709 SHM records 16041689 SHM writes 216649 SHM flushes due to overflow 2490 SHM MTX contention 68 SHM cycles through buffer 2913748 allocator requests 9 outstanding allocations 1261568 bytes allocated 214747471872 bytes free 0 SMA allocator requests 0 SMA outstanding allocations 0 SMA outstanding bytes 0 SMA bytes allocated 0 SMA bytes free 884 SMS allocator requests 0 SMS outstanding allocations 0 SMS outstanding bytes 343064 SMS bytes allocated 343064 SMS bytes freed 1461182 Backend requests made 1 N vcl total 1 N vcl available 0 N vcl discarded 1 N total active purges 1 N new purges added 0 N old purges deleted 0 N objects tested 0 N regexps tested against -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 17 10:31:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 17 Nov 2008 10:31:53 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.faa2ba1a3b867b467ac56b8ede4b58f2@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by 191919): 18446744073709551221 . . N active struct srcaddr I also occasionally saw this number when varnishd stopped responding. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 17 16:59:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 17 Nov 2008 16:59:38 -0000 Subject: [Varnish] #379: The varnish have no response most of the time , is it the bug? Message-ID: <051.87655e50bc8fca878e4c18f54c9f6ca6@projects.linpro.no> #379: The varnish have no response most of the time ,is it the bug? -------------------+-------------------------------------------------------- Reporter: Ajian | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Now I am using the varnish 2.0.2 ,but I found a question that is not be resolved . I don't know it is my fault or the varnish's bug. OS: CentOS 5.2 64X MEM:16G varnish : 2.0.2 Description: I have two domains ,They are the WWW and the BBS . The WWW domain have the index.html ,another have not . Open the WWW , is very fast . Open the BBS ,always the varnish have no response ,if add the index.php after the BBS domain ,the web display at once.Additional,I have test the web of the BBS ,not use the varnish ,the web running is well . Problem: 1?I don't why the no response appears always. 2?How to debug the varnish and check the error log of the varnish ,not the access log. The fellowing is the configuration and the varnishstat {{{ backend www { .host = "50.28.29.20"; .port = "80"; } backend bbs { .host = "50.28.29.21"; .port = "80"; } acl purge { "localhost"; "127.0.0.1"; "10.10.10.0"/24; "50.28.29.0"/26; } sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } elseif(req.url ~ "\.(php|cgi)($|\?)") { pass; } else { lookup; } } if(req.http.host ~"^(bbs).mobile.com.cn") { set req.backend = bbs; } elseif(req.http.host ~"^(www.|img.|www2.|ad.|soft.)?mobile.com.cn") { set req.backend = www; }else{ error 200 "Domain is not exist"; } if (req.request != "GET" && req.request != "HEAD") { pipe; } elseif (req.url ~ "\.(php|cgi)($|\?)") { pass; } elseif (req.http.Authenticate || req.http.Authorization) { pass; } lookup; } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } if (!obj.cacheable) { pass; } if (obj.http.Vary) { unset obj.http.Vary; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } } sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; #set req.hash += req.http.cookie; hash; } sub vcl_fetch { if (!obj.cacheable) { pass; } if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no- cache" || obj.http.Cache-Control ~ "private") { pass; } if (!obj.http.ETag && !obj.http.Last-Modified) { pass; } if (obj.http.Set-Cookie) { pass; } set obj.ttl = 28800s; } }}} The varnishstat {{{ Hitrate ratio: 10 28 28 Hitrate avg: 0.8181 0.8142 0.8142 1969722 46.00 39.47 Client connections accepted 4866403 64.00 97.52 Client requests received 3542647 53.00 70.99 Cache hits 90073 1.00 1.80 Cache hits for pass 714443 5.00 14.32 Cache misses 1300258 10.00 26.06 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 3888 0.00 0.08 Backend connections failures 387852 3.00 7.77 Backend connections reuses 443628 8.00 8.89 Backend connections recycles 0 0.00 0.00 Backend connections unused 7075 . . N struct srcaddr 6100 . . N active struct srcaddr 19735 . . N struct sess_mem 19718 . . N struct sess 291944 . . N struct object 285351 . . N struct objecthead 618316 . . N struct smf 39508 . . N small free smf 4718 . . N large free smf 89 . . N struct vbe_conn 322 . . N struct bereq 121 . . N worker threads 2556 0.00 0.05 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 18334 0.00 0.37 N overflowed work requests 0 0.00 0.00 N dropped work requests 9 . . N backends }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 18 08:20:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Nov 2008 08:20:01 -0000 Subject: [Varnish] #380: sudden Increase in load on server running varnish Message-ID: <052.4576bcc56d854b21e1d9fc4dbbbdc48b@projects.linpro.no> #380: sudden Increase in load on server running varnish ----------------------+----------------------------------------------------- Reporter: plfgoa | Owner: phk Type: task | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Hi, I have been trying my hand at varnish , which although most of the times tends to run without much of an issue, after running it for about 6-7 hours there seems to be sudden increase in load on the server with CPU usage going upto 100% and the number of worker threads increasing to about 500 . Is this an issue associated with cleanup when the cache becomes full in varnish ? The cache size used was 8GB(RAM disk) . Are there any parameters which could be applied to handle this kind of sudden surge in load on the server ? Any help in this regards will be appreciated and thanks in advance. Server Config: Intel Xeon Quad core , OS: SUSE LINUX 10.1 (X86-64) with 20GB RAM Varnish version used is 2.0.2 Thank you. -Paras -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 18 20:27:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Nov 2008 20:27:55 -0000 Subject: [Varnish] #381: Extra information useful in VCLExamplePurging Message-ID: <049.ffbf87943082984dd9bec3d1c2f76fca@projects.linpro.no> #381: Extra information useful in VCLExamplePurging -----------------+---------------------------------------------------------- Reporter: ldr | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | -----------------+---------------------------------------------------------- VCLExamplePurging should mention that if vcl_hash is customised, it is possible that PURGE requests will not 'hit' as the hash generated for the purging server process may not match that generated by a browser. To handle this you can purge unconditionally in vvcl_recv: {{{ sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } purge_url(req.url); error 200 "Purged"; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 18 20:54:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 18 Nov 2008 20:54:50 -0000 Subject: [Varnish] #355: grace not documented In-Reply-To: <050.8925fc4ff5931834e2a641a3ee266395@projects.linpro.no> References: <050.8925fc4ff5931834e2a641a3ee266395@projects.linpro.no> Message-ID: <059.976416400f9b5d5a68e8fca238511aae@projects.linpro.no> #355: grace not documented ---------------------------+------------------------------------------------ Reporter: eric | Owner: tfheen Type: documentation | Status: closed Priority: low | Milestone: Component: documentation | Version: 2.0 Severity: normal | Resolution: fixed Keywords: vcl grace | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r3402. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 19 08:55:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 19 Nov 2008 08:55:38 -0000 Subject: [Varnish] #382: varnishncsa is leaking Message-ID: <056.b1479d969d8ea2c19febb9535df4b4e3@projects.linpro.no> #382: varnishncsa is leaking ---------------------------------+------------------------------------------ Reporter: chrisrixon | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: varnishncsa Version: 2.0 | Severity: major Keywords: leak | ---------------------------------+------------------------------------------ Looks to us like varnishncsa is leaking we do this: {{{ varnishncsa -D -w v.txt }}} then every minute: {{{ mv v.txt v2.txt /usr/bin/killall -HUP varnishncsa }}} I thinks its about 500M a week (Varnish 2.01) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 19 09:58:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 19 Nov 2008 09:58:35 -0000 Subject: [Varnish] #377: Varnish sending empty http packets to the backend In-Reply-To: <053.525a6b24070245046748eee1a31218fa@projects.linpro.no> References: <053.525a6b24070245046748eee1a31218fa@projects.linpro.no> Message-ID: <062.fe9657ead5cc5dd9fb83fb42e9346873@projects.linpro.no> #377: Varnish sending empty http packets to the backend ---------------------+------------------------------------------------------ Reporter: ibrezac | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => invalid Comment: Hi Igor, Solaris support is very experimental at this point, and I don't have any solaris machines myself to test on. I suggest you send an email to Theo Schlossnagle who submitted the Solaris patches to us. Poul-Henning PS: I'm going to close this ticket as "invalid", that's not a reflection on the issue, but I don't have an option that says "can't fix". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 19 12:03:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 19 Nov 2008 12:03:48 -0000 Subject: [Varnish] #383: Unexplained vcl behaivior maybe header related to header modify Message-ID: <056.d969776f70d684566868c4d4abb7abaf@projects.linpro.no> #383: Unexplained vcl behaivior maybe header related to header modify ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.0 Severity: normal | Keywords: vcl header ------------------------+--------------------------------------------------- If we uncomment the block of code below we get many more backend hits. It seems to be related to the gzip header modification because if thats commented out it works. Possibly related to #292 ? Its puzzling us as the offending code looks like it should be a NOP ... {{{ sub vcl_recv { set req.grace = 2m; # coment this block to fix it if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|gz|tgz|mp3|zip|swf)") { # No point in compressing these remove req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } if (req.request != "GET" && req.request != "HEAD") { pipe; } if (req.http.Expect) { pipe; } if (req.http.Authenticate) { pass; } if (req.http.Cache-Control ~ "no-cache") { pass; } # uncomment this to break it # if (req.request != "GET" && # req.request != "HEAD" && # req.request != "PUT" && # req.request != "POST" && # req.request != "TRACE" && # req.request != "OPTIONS" && # req.request != "DELETE") { # /* Non-RFC2616 or CONNECT which is weird. */ # pipe; # } lookup; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 20 14:32:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 20 Nov 2008 14:32:23 -0000 Subject: [Varnish] #384: RPM .spec is missing gcc dependency Message-ID: <051.73361bd7c4175565a4bb27c53641b091@projects.linpro.no> #384: RPM .spec is missing gcc dependency -------------------+-------------------------------------------------------- Reporter: janne | Type: enhancement Status: new | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: trivial Keywords: | -------------------+-------------------------------------------------------- varnish.spec is missing the requirement of gcc, so rpm's built with it can be installed without gcc but the installation does not work. "Requires: gcc" should do the trick. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 20 19:07:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 20 Nov 2008 19:07:51 -0000 Subject: [Varnish] #384: RPM .spec is missing gcc dependency In-Reply-To: <051.73361bd7c4175565a4bb27c53641b091@projects.linpro.no> References: <051.73361bd7c4175565a4bb27c53641b091@projects.linpro.no> Message-ID: <060.6a9b9d25b1cb92f760a4dc3275fd9beb@projects.linpro.no> #384: RPM .spec is missing gcc dependency -------------------------+-------------------------------------------------- Reporter: janne | Owner: ingvar Type: enhancement | Status: new Priority: normal | Milestone: Component: packaging | Version: trunk Severity: trivial | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by perbu): * owner: => ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 22 07:51:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 22 Nov 2008 07:51:43 -0000 Subject: [Varnish] #385: Pluggable cache engines Message-ID: <052.70e37345207180ee7dfaef63a1966bff@projects.linpro.no> #385: Pluggable cache engines -------------------------+-------------------------------------------------- Reporter: eugaia | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: -------------------------+-------------------------------------------------- Has anyone thought about the idea of pluggable cache engines, in the same way that MySQL (5.1+) has pluggable storage engines? The idea I have is for you to be able to choose a caching engine as part of the settings in VCL, so that you could use the current method (i.e. virtual memory file, hashing, buckets etc), or another method. One other possible type of engine I've thought of (and will be implementing using the C{ }C inclusion method in VCL - a fantastically good idea btw) is to use a MySQL storage plugin which opens up a high- speed socket to a cache file table. The code that I'll include in the VCL would then access that socket to retrieve / write cache data. There might be particular advantages of this method of storing cache data, e.g. persistence, ability to access the cache files via a database, scalability, clustering etc. Other caching engines/protocols could be developed, perhaps based on specific needs, and an 'ideal' solution might involve more than one caching engine. By opening up the caching engine, and by having a setting like: engine cache1 { .type = MyCache; .socket = "/tmp/mycache.sock"; } set req.engine = cache1; it would facilitate such a feature and would (I believe) be a valuable addition to the architecture of Varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 24 10:58:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 24 Nov 2008 10:58:36 -0000 Subject: [Varnish] #386: Varnish sometimes fails to insert ESI snippet Message-ID: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> #386: Varnish sometimes fails to insert ESI snippet -------------------+-------------------------------------------------------- Reporter: peter | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- We are using the ESI support from Varnish 2.0.2 to insert 2 ESI snippets in a certain page. 98% of the time this works perfectly, but sometimes instead of the snippet nothing is inserted. However there is no log of any error whatsoever. The snippets and the main page are all plain HTML files served by an Apache server. At the time of failure there are no other requests of other users on the webserver. A page that at a given time fails can succeed at another time. Sometimes a user will see failure after failure while another user can't reproduce other times the same user can't reproduce at all. We did some logging using Varnishlog of one the failed request. From the logs we can see that Varnish does detect the ESI includes, does the requests and even parses the results to checked for nested ESI includes. However the resulting page doesn't contain the includes, so it doesn't seem a problem of retrieving the snippet. Also when after a failure we try to retrieve the snippet directly we see that it has an age which goes back to the time we requested the snippet as part of the main page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 24 12:34:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 24 Nov 2008 12:34:44 -0000 Subject: [Varnish] #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used In-Reply-To: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> References: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> Message-ID: <070.abc862e4dcbe42439bc53b6ab60476c0@projects.linpro.no> #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used -----------------------------+---------------------------------------------- Reporter: anders at fupp.net | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | -----------------------------+---------------------------------------------- Changes (by anders): * version: 1.0 => 2.0 Comment: The problem still exists in Varnish 2.0.2: {{{ (gdb) bt #0 0x0000000800dabe7c in kill () from /lib/libc.so.7 #1 0x0000000800daaceb in abort () from /lib/libc.so.7 #2 0x000000080067a4fc in lbv_assert_default ( func=0xaddf
, file=0x6
, line=0, cond=0x800dabe9c "r\001?H\213\rZ\230\022", err=43, xxx=-7112) at assert.c:61 #3 0x000000000042cd52 in mgt_cli_telnet (dflag=Variable "dflag" is not available. ) at mgt_cli.c:478 #4 0x000000000042c227 in mgt_run (dflag=0, T_arg=0x7fffffffedc2 "localhost:8080") at mgt_child.c:518 #5 0x000000000043716a in main (argc=Variable "argc" is not available. ) at varnishd.c:630 }}} If I remove the IPv6 address for localhost in hosts, this crash does not happen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 07:19:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 07:19:47 -0000 Subject: [Varnish] #372: varnish dies In-Reply-To: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> References: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> Message-ID: <069.f16c5e2349402f1be34c3db4238b262e@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Comment (by maheshollalwar): Varnish doesn't start when I add more space. Nov 25 11:57:56 varnish-ril1 varnishd: NB: Storage size limited to 2GB on 32 bit architecture, Nov 25 11:57:56 varnish-ril1 varnishd: NB: otherwise we could run out of address space. Nov 25 11:57:56 varnish-ril1 varnishd: storage_file: filename: /var/lib/varnish/storage1.bin size 2047 MB. Nov 25 11:57:56 varnish-ril1 varnishd: storage_file: filename: /var/lib/varnish/storage2.bin size 2047 MB. Nov 25 11:57:56 varnish-ril1 varnishd: NB: Storage size limited to 2GB on 32 bit architecture, Nov 25 11:57:56 varnish-ril1 varnishd: NB: otherwise we could run out of address space. Nov 25 11:58:08 varnish-ril1 varnishd: Using old SHMFILE Nov 25 06:28:08 varnish-ril1 varnishd[28051]: child (28052) Started Nov 25 11:58:08 varnish-ril1 varnish: varnishd startup succeeded Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Pushing vcls failed: CLI communication error Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Child (28052) said Closed fds: 5 6 7 11 12 14 15 Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Child (28052) said Child starts Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Child (28052) said managed to mmap 2147479552 bytes of 2147479552 Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Child (28052) said managed to mmap 951578624 bytes of 2147479552 Nov 25 06:28:08 varnish-ril1 varnishd[28051]: Child (28052) said Ready Below is my configuration :- DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -u varnish -g varnish \ -s file,/var/lib/varnish/storage.bin,2G \ -s file,/var/lib/varnish/storage.bin,2G" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 07:21:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 07:21:04 -0000 Subject: [Varnish] #372: varnish dies In-Reply-To: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> References: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> Message-ID: <069.7b4d1773cc5a1938cc4457a1fff1b32d@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Comment (by maheshollalwar): 0+00:13:36 varnish-ril1.rediff.com Hitrate ratio: 2 2 2 Hitrate avg: 0.7965 0.7965 0.7965 3590 4.99 4.40 Client connections accepted 11298 4.99 13.85 Client requests received 8861 3.99 10.86 Cache hits 123 0.00 0.15 Cache hits for pass 2312 1.00 2.83 Cache misses 2435 1.00 2.98 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 0 0.00 0.00 Backend connections failures 2158 1.00 2.64 Backend connections reuses 2234 1.00 2.74 Backend connections recycles 0 0.00 0.00 Backend connections unused 343 . . N struct srcaddr 38 . . N active struct srcaddr 95 . . N struct sess_mem 52 . . N struct sess 2299 . . N struct object 2300 . . N struct objecthead 4541 . . N struct smf 0 . . N small free smf 2 . . N large free smf 4 . . N struct vbe_conn 25 . . N struct bereq 60 . . N worker threads 69 0.00 0.08 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 293 0.00 0.36 N overflowed work requests 0 0.00 0.00 N dropped work requests 2 . . N backends 63 . . N expired objects 0 . . N LRU nuked objects 0 . . N LRU saved objects 6797 . . N LRU moved objects 0 . . N objects on deathrow 0 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 07:27:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 07:27:58 -0000 Subject: [Varnish] #372: varnish dies In-Reply-To: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> References: <060.36d4062402051dfe8d5ae15410c8a404@projects.linpro.no> Message-ID: <069.66cf7895d2b7b8a7b1532b3fa47ccf13@projects.linpro.no> #372: varnish dies ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------------+----------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: On a 32bit system you can not get more than about 2GB of storage to work, switch to a 64bit OS. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 08:35:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 08:35:56 -0000 Subject: [Varnish] #386: Varnish sometimes fails to insert ESI snippet In-Reply-To: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> References: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> Message-ID: <060.91fb72990a9320fbdbabf27eeb2e8949@projects.linpro.no> #386: Varnish sometimes fails to insert ESI snippet --------------------+------------------------------------------------------- Reporter: peter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): This bug happens when an If-Modified-Since is sent and the parent document is delivered, but the included document does not satisfy the IMS condition. That is why you do not see it with curl but only with reload in a browser. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 08:37:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 08:37:35 -0000 Subject: [Varnish] #386: Varnish sometimes fails to insert ESI snippet In-Reply-To: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> References: <051.124d2a70058f09aefc562a116f2a23b5@projects.linpro.no> Message-ID: <060.dce7491a04e096a4db2ea7e0803b4527@projects.linpro.no> #386: Varnish sometimes fails to insert ESI snippet --------------------+------------------------------------------------------- Reporter: peter | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [3433]) When we receive an If-Modified-Since on an ESI object, do not process the conditional for the child object and pretend to send a 304 reply for them, if we have decided to deliver the main object. Fixes #386 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 25 12:46:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 25 Nov 2008 12:46:14 -0000 Subject: [Varnish] #387: Varnish crashes on Missing errorhandling code in fetch_chunked Message-ID: <052.22bfa1b1cfef87b231048e0ed3d9726b@projects.linpro.no> #387: Varnish crashes on Missing errorhandling code in fetch_chunked ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- While running Varnish trunk/2980 (from july 21st), I got a crash like this: {{{ Oct 14 21:13:52 cache12 varnishd[15319]: Child (15331) Panic message: Missing errorhandling code in fetch_chunked(), cache_fetch.c line 113: Condition(be > bp) not true. errno = 22 (Invalid argument) thread = (cache-worker)sp = 0x80bd5e008 { fd = 64, id = 64, xid = 1644558162, client = 195.159.226.113:9553, step = STP_FETCH, handling = FETCH, ws = 0x80bd5e078 { id = "sess", {s,f,r,e} = {0x80bd5e7a0,,+853,0x0,+8192}, }, worker = 0x7fffd48a5ac0 { }, vcl = { srcname = { "/usr/local/etc/varnish.vcl", "Default", }, }, obj = 0x13fd348000 { refcnt = 1, xid = 1644558162, ws = 0x13fd348028 { id = "obj", {s,f,r,e} = {0x13fd348350,,+338,0x0,+3248}, }, http = { ws = 0x13fd348028 { id = "obj", {s,f,r,e} = {0x13fd348350,,+338,0x0,+3248}, }, hd = { "Set-Cookie: finn_ld=aeb69f3baeb69f33baeebab8; path=/", "Date: Tue, 14 Oct 2008 21:13:28 GMT", "Server: Apache/2.2.3 (Debian }}} It looks like this portion of cache_fetch.c has not been changed since then, and that this could still be a problem. Unfortunately I don't have the core-dump anymore. Let me know if any more info is needed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 09:52:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 09:52:38 -0000 Subject: [Varnish] #388: make gives errors when xsltproc is not installed Message-ID: <054.ee8df78fba05cd4856a6b9bb05182d1c@projects.linpro.no> #388: make gives errors when xsltproc is not installed ----------------------+----------------------------------------------------- Reporter: mtempels | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- when compiling varnish when "xsltproc" is not installed the make process outputs some errors and does not update documentation.. xinclude -o changes-2.0.1.html changes-2.0.1.xml /bin/bash: xinclude: command not found -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 09:54:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 09:54:49 -0000 Subject: [Varnish] #389: no error when libncurses is not installed Message-ID: <054.5b74b900095af22d52a4ea64cf432825@projects.linpro.no> #389: no error when libncurses is not installed ----------------------+----------------------------------------------------- Reporter: mtempels | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- It would be nice in imho that varnish should warn you during ./configure if libncursrs is not installed that varnish tools will not be built :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 10:04:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 10:04:14 -0000 Subject: [Varnish] #389: no error when libncurses is not installed In-Reply-To: <054.5b74b900095af22d52a4ea64cf432825@projects.linpro.no> References: <054.5b74b900095af22d52a4ea64cf432825@projects.linpro.no> Message-ID: <063.be04fc46a7c9ef9863175f7a04a3eea7@projects.linpro.no> #389: no error when libncurses is not installed -------------------------+-------------------------------------------------- Reporter: mtempels | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by mtempels): this is fixed already :) Cheers! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 10:05:18 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 10:05:18 -0000 Subject: [Varnish] #389: no error when libncurses is not installed In-Reply-To: <054.5b74b900095af22d52a4ea64cf432825@projects.linpro.no> References: <054.5b74b900095af22d52a4ea64cf432825@projects.linpro.no> Message-ID: <063.fbb2e069490c169941c28a57e766309d@projects.linpro.no> #389: no error when libncurses is not installed -------------------------+-------------------------------------------------- Reporter: mtempels | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: from configure.ac: if test "$have_curses" = no; then AC_MSG_WARN([curses not found; some tools will not be built]) fi so this is already there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 11:06:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 11:06:36 -0000 Subject: [Varnish] #390: varnish #3444 core dumps.. Message-ID: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> #390: varnish #3444 core dumps.. ----------------------+----------------------------------------------------- Reporter: mtempels | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- child dies.. various log entries: Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) not responding to ping, killing it. Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) died signal=6 (core dumped) Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) Panic message: Assert error in WRW_Reserve(), cache_pool.c line 114: Condition((w->wfd) == 0) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker)sp = 0x7f2f8e449008 { fd = 137, id = 137, xid = 369732011, client = 213.221.42.174:2504, step = STP_DELIVER, handling = DELIVER, ws = 0x7f2f8e449078 { id = "sess", {s,f,r,e} = {0x7f2f8e4497c8,,+1223,(nil),+8192}, }, worker = 0x4eccbbc0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f2f7b248000 { refcnt = 1, xid = 369732011, ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, http = { ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, hd = { "Date: Wed, 26 Nov 2008 10:38:39 GMT", "Server: Varnish", "Retry- After: 0", "Content-Type: text/html; cha Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child cleanup complete Nov 26 11:38:40 vkmag-cache varnishd[21915]: child (26105) Started Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Closed fds: 3 4 5 8 9 11 12 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Child starts Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Ready Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.151 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said ", 0.5, 1) Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.152 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times root at vkmag-cache:~/varnish/svn# svn info Path: . URL: http://varnish.projects.linpro.no/svn Repository Root: http://varnish.projects.linpro.no/svn Repository UUID: d4fa192b-c00b-0410-8231-f00ffab90ce4 Revision: 3444 Node Kind: directory Schedule: normal Last Changed Author: phk Last Changed Rev: 3444 Last Changed Date: 2008-11-25 17:04:47 +0100 (Tue, 25 Nov 2008) 21915 ? Ss 0:00 /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a 0.0.0.0:80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,10 -p auto_restart on -s malloc,6G (gdb) bt #0 0x00007f2f971a2095 in raise () from /lib/libc.so.6 #1 0x00007f2f971a3af0 in abort () from /lib/libc.so.6 #2 0x000000000041f6a6 in pan_ic (func=0x44c480 "WRW_Reserve", file=0x44c498 "cache_pool.c", line=114, cond=0x44c4be "(w->wfd) == 0", err=11, xxx=0) at cache_panic.c:325 #3 0x000000000041fd99 in WRW_Reserve (w=0x4eccbbc0, fd=0x7f2f8e44900c) at cache_pool.c:114 #4 0x0000000000422184 in RES_WriteObj (sp=0x7f2f8e449008) at cache_response.c:140 #5 0x000000000041040f in cnt_deliver (sp=0x7f2f8e449008) at cache_center.c:178 #6 0x00000000004130a9 in CNT_Session (sp=0x7f2f8e449008) at steps.h:42 #7 0x0000000000420eda in wrk_do_cnt_sess (w=0x4eccbbc0, priv=0x7f2f8e449008) at cache_pool.c:396 #8 0x00000000004209af in wrk_thread (priv=0x7f2f96e0a100) at cache_pool.c:310 #9 0x00007f2f979723f7 in start_thread () from /lib/libpthread.so.0 #10 0x00007f2f97247b3d in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 11:07:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 11:07:57 -0000 Subject: [Varnish] #390: varnish #3444 core dumps.. In-Reply-To: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> References: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> Message-ID: <063.fbc8bd50f196ca70e50030b5b2dda4a0@projects.linpro.no> #390: varnish #3444 core dumps.. ----------------------+----------------------------------------------------- Reporter: mtempels | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by mtempels): this is more readable i guess {{{ Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) not responding to ping, killing it. Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) died signal=6 (core dumped) Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) Panic message: Assert error in WRW_Reserve(), cache_pool.c line 114: Condition((w->wfd) == 0) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker)sp = 0x7f2f8e449008 { fd = 137, id = 137, xid = 369732011, client = 213.221.42.174:2504, step = STP_DELIVER, handling = DELIVER, ws = 0x7f2f8e449078 { id = "sess", {s,f,r,e} = {0x7f2f8e4497c8,,+1223,(nil),+8192}, }, worker = 0x4eccbbc0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f2f7b248000 { refcnt = 1, xid = 369732011, ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, http = { ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, hd = { "Date: Wed, 26 Nov 2008 10:38:39 GMT", "Server: Varnish", "Retry- After: 0", "Content-Type: text/html; cha Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child cleanup complete Nov 26 11:38:40 vkmag-cache varnishd[21915]: child (26105) Started Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Closed fds: 3 4 5 8 9 11 12 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Child starts Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Ready Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.151 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said ", 0.5, 1) Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.152 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times root at vkmag-cache:~/varnish/svn# svn info Path: . URL: http://varnish.projects.linpro.no/svn Repository Root: http://varnish.projects.linpro.no/svn Repository UUID: d4fa192b-c00b-0410-8231-f00ffab90ce4 Revision: 3444 Node Kind: directory Schedule: normal Last Changed Author: phk Last Changed Rev: 3444 Last Changed Date: 2008-11-25 17:04:47 +0100 (Tue, 25 Nov 2008) 21915 ? Ss 0:00 /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a 0.0.0.0:80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,10 -p auto_restart on -s malloc,6G (gdb) bt #0 0x00007f2f971a2095 in raise () from /lib/libc.so.6 #1 0x00007f2f971a3af0 in abort () from /lib/libc.so.6 #2 0x000000000041f6a6 in pan_ic (func=0x44c480 "WRW_Reserve", file=0x44c498 "cache_pool.c", line=114, cond=0x44c4be "(w->wfd) == 0", err=11, xxx=0) at cache_panic.c:325 #3 0x000000000041fd99 in WRW_Reserve (w=0x4eccbbc0, fd=0x7f2f8e44900c) at cache_pool.c:114 #4 0x0000000000422184 in RES_WriteObj (sp=0x7f2f8e449008) at cache_response.c:140 #5 0x000000000041040f in cnt_deliver (sp=0x7f2f8e449008) at cache_center.c:178 #6 0x00000000004130a9 in CNT_Session (sp=0x7f2f8e449008) at steps.h:42 #7 0x0000000000420eda in wrk_do_cnt_sess (w=0x4eccbbc0, priv=0x7f2f8e449008) at cache_pool.c:396 #8 0x00000000004209af in wrk_thread (priv=0x7f2f96e0a100) at cache_pool.c:310 #9 0x00007f2f979723f7 in start_thread () from /lib/libpthread.so.0 #10 0x00007f2f97247b3d in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 11:28:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 11:28:07 -0000 Subject: [Varnish] #390: varnish #3444 core dumps.. In-Reply-To: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> References: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> Message-ID: <063.7d34fa31835ca55948b0046c7bff1b19@projects.linpro.no> #390: varnish #3444 core dumps.. ----------------------+----------------------------------------------------- Reporter: mtempels | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > child dies.. > > various log entries: > > Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) not responding > to ping, killing it. > Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) died signal=6 > (core dumped) > Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) Panic message: > Assert error in WRW_Reserve(), cache_pool.c line 114: > Condition((w->wfd) == 0) not true. errno = 11 (Resource temporarily > unavailable) thread = (cache-worker)sp = 0x7f2f8e449008 { fd = 137, id > = 137, xid = 369732011, client = 213.221.42.174:2504, step = > STP_DELIVER, handling = DELIVER, ws = 0x7f2f8e449078 { id = > "sess", {s,f,r,e} = {0x7f2f8e4497c8,,+1223,(nil),+8192}, }, > worker = 0x4eccbbc0 { }, vcl = { srcname = { > "input", "Default", }, }, obj = 0x7f2f7b248000 { > refcnt = 1, xid = 369732011, ws = 0x7f2f7b248028 { id = "obj", > {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, http = { > ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = > {0x7f2f7b248358,,+161,(nil),+7336}, }, hd = { "Date: > Wed, 26 Nov 2008 10:38:39 GMT", "Server: Varnish", > "Retry-After: 0", "Content-Type: text/html; cha > Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child cleanup complete > Nov 26 11:38:40 vkmag-cache varnishd[21915]: child (26105) Started > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Closed > fds: 3 4 5 8 9 11 12 > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Child > starts > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Ready > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Probe("GET /check.php HTTP/1.1 > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: > 81.23.234.151 > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Connection: close > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache last message repeated 2 times > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said ", 0.5, > 1) > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Probe("GET /check.php HTTP/1.1 > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: > 81.23.234.152 > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Connection: close > Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said > Nov 26 11:38:40 vkmag-cache last message repeated 2 times > > root at vkmag-cache:~/varnish/svn# svn info > Path: . > URL: http://varnish.projects.linpro.no/svn > Repository Root: http://varnish.projects.linpro.no/svn > Repository UUID: d4fa192b-c00b-0410-8231-f00ffab90ce4 > Revision: 3444 > Node Kind: directory > Schedule: normal > Last Changed Author: phk > Last Changed Rev: 3444 > Last Changed Date: 2008-11-25 17:04:47 +0100 (Tue, 25 Nov 2008) > > 21915 ? Ss 0:00 /usr/local/sbin/varnishd -P > /var/run/varnishd.pid -a 0.0.0.0:80 -f /etc/varnish/default.vcl -T > 127.0.0.1:6082 -t 120 -w 1,1000,10 -p auto_restart on -s malloc,6G > > (gdb) bt > #0 0x00007f2f971a2095 in raise () from /lib/libc.so.6 > #1 0x00007f2f971a3af0 in abort () from /lib/libc.so.6 > #2 0x000000000041f6a6 in pan_ic (func=0x44c480 "WRW_Reserve", > file=0x44c498 "cache_pool.c", line=114, > cond=0x44c4be "(w->wfd) == 0", err=11, xxx=0) at cache_panic.c:325 > #3 0x000000000041fd99 in WRW_Reserve (w=0x4eccbbc0, fd=0x7f2f8e44900c) > at cache_pool.c:114 > #4 0x0000000000422184 in RES_WriteObj (sp=0x7f2f8e449008) at > cache_response.c:140 > #5 0x000000000041040f in cnt_deliver (sp=0x7f2f8e449008) at > cache_center.c:178 > #6 0x00000000004130a9 in CNT_Session (sp=0x7f2f8e449008) at steps.h:42 > #7 0x0000000000420eda in wrk_do_cnt_sess (w=0x4eccbbc0, > priv=0x7f2f8e449008) at cache_pool.c:396 > #8 0x00000000004209af in wrk_thread (priv=0x7f2f96e0a100) at > cache_pool.c:310 > #9 0x00007f2f979723f7 in start_thread () from /lib/libpthread.so.0 > #10 0x00007f2f97247b3d in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () New description: child dies.. various log entries: {{{ Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) not responding to ping, killing it. Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) died signal=6 (core dumped) Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child (21916) Panic message: Assert error in WRW_Reserve(), cache_pool.c line 114: Condition((w->wfd) == 0) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker)sp = 0x7f2f8e449008 { fd = 137, id = 137, xid = 369732011, client = 213.221.42.174:2504, step = STP_DELIVER, handling = DELIVER, ws = 0x7f2f8e449078 { id = "sess", {s,f,r,e} = {0x7f2f8e4497c8,,+1223,(nil),+8192}, }, worker = 0x4eccbbc0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f2f7b248000 { refcnt = 1, xid = 369732011, ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, http = { ws = 0x7f2f7b248028 { id = "obj", {s,f,r,e} = {0x7f2f7b248358,,+161,(nil),+7336}, }, hd = { "Date: Wed, 26 Nov 2008 10:38:39 GMT", "Server: Varnish", "Retry- After: 0", "Content-Type: text/html; cha Nov 26 11:38:39 vkmag-cache varnishd[21915]: Child cleanup complete Nov 26 11:38:40 vkmag-cache varnishd[21915]: child (26105) Started Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Closed fds: 3 4 5 8 9 11 12 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Child starts Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Ready Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.151 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said ", 0.5, 1) Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Probe("GET /check.php HTTP/1.1 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Host: 81.23.234.152 Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Connection: close Nov 26 11:38:40 vkmag-cache varnishd[21915]: Child (26105) said Nov 26 11:38:40 vkmag-cache last message repeated 2 times root at vkmag-cache:~/varnish/svn# svn info Path: . URL: http://varnish.projects.linpro.no/svn Repository Root: http://varnish.projects.linpro.no/svn Repository UUID: d4fa192b-c00b-0410-8231-f00ffab90ce4 Revision: 3444 Node Kind: directory Schedule: normal Last Changed Author: phk Last Changed Rev: 3444 Last Changed Date: 2008-11-25 17:04:47 +0100 (Tue, 25 Nov 2008) 21915 ? Ss 0:00 /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a 0.0.0.0:80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,10 -p auto_restart on -s malloc,6G (gdb) bt #0 0x00007f2f971a2095 in raise () from /lib/libc.so.6 #1 0x00007f2f971a3af0 in abort () from /lib/libc.so.6 #2 0x000000000041f6a6 in pan_ic (func=0x44c480 "WRW_Reserve", file=0x44c498 "cache_pool.c", line=114, cond=0x44c4be "(w->wfd) == 0", err=11, xxx=0) at cache_panic.c:325 #3 0x000000000041fd99 in WRW_Reserve (w=0x4eccbbc0, fd=0x7f2f8e44900c) at cache_pool.c:114 #4 0x0000000000422184 in RES_WriteObj (sp=0x7f2f8e449008) at cache_response.c:140 #5 0x000000000041040f in cnt_deliver (sp=0x7f2f8e449008) at cache_center.c:178 #6 0x00000000004130a9 in CNT_Session (sp=0x7f2f8e449008) at steps.h:42 #7 0x0000000000420eda in wrk_do_cnt_sess (w=0x4eccbbc0, priv=0x7f2f8e449008) at cache_pool.c:396 #8 0x00000000004209af in wrk_thread (priv=0x7f2f96e0a100) at cache_pool.c:310 #9 0x00007f2f979723f7 in start_thread () from /lib/libpthread.so.0 #10 0x00007f2f97247b3d in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 26 15:39:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 26 Nov 2008 15:39:38 -0000 Subject: [Varnish] #391: Panic message: Assert error in cnt_lookup(), cache_center.c Message-ID: <053.29acd601888f493fb4fef82533c92d10@projects.linpro.no> #391: Panic message: Assert error in cnt_lookup(), cache_center.c ----------------------+----------------------------------------------------- Reporter: vrobert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: ----------------------+----------------------------------------------------- Hello, we are a french company, we have 4 varnish server v2.0.2. Each server have about 500 req/s. Sometime a server hang with this message: {{{ Nov 26 15:13:41 tatooine varnishd[25912]: Child (25913) died signal=6 Nov 26 15:13:41 tatooine varnishd[25912]: Child (25913) Panic message: Assert error in cnt_lookup(), cache_center.c line 625: Condition(sp->objhead != NULL) not true. thread = (cache-worker)sp = 0x2ab5ecd73008 { fd = 5, id = 5, xid = 948877249, client = 192.168.7.86:44306, step = STP_FETCH, handling = FETCH, ws = 0x2ab5ecd73078 { id = "sess", {s,f,r,e} = {0x2ab5ecd737b0,,+564,(nil),+8192}, }, worker = 0x58d3dc10 { }, vcl = { srcname = { "/etc/varnish/production.vcl", "Default", }, }, obj = 0x2aab77d40000 { refcnt = 1, xid = 948877249, ws = 0x2aab77d40028 { id = "obj", {s,f,r,e} = {0x2aab77d40358,,0x2aab77d40358,(nil),+7336}, }, http = { ws = 0x2aab77d40028 { id = "obj", {s,f,r,e} = {0x2aab77d40358,,0x2aab77d40358,(nil),+7336}, }, }, len = 0, store = { }, }, }, Nov 26 15:13:41 tatooine varnishd[25912]: child (7207) Started Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Closed fds: 4 5 6 10 11 13 14 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Child starts Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said managed to mmap 48318382080 bytes of 48318382080 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Ready Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.83 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.84 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.88 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.87 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.90 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.91 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.219 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Probe("GET /index.html HTTP/1.1 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Host: 192.168.7.224 Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Connection: close Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said Nov 26 15:13:41 tatooine varnishd[25912]: Child (7207) said ", 0.1, 1) }}} Our configuration: {{{ DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/production.vcl \ -u varnish -g varnish \ -s file,/cache/varnish_storage.bin,45G \ -p lru_interval=60 \ -p thread_pool_max=2000 \ -p listen_depth=2048 \ -t 0 \ -h classic,500009" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 27 06:05:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 27 Nov 2008 06:05:00 -0000 Subject: [Varnish] #392: Varnish installs but doesn't start on suse 10.3 (X86-64) Message-ID: <052.3c6bf685f7cf98159b81e6983206c77b@projects.linpro.no> #392: Varnish installs but doesn't start on suse 10.3 (X86-64) ----------------------+----------------------------------------------------- Reporter: plfgoa | Owner: phk Type: task | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: ----------------------+----------------------------------------------------- Hi, When I try to start varnish 2.0.2 in debug mode , ./varnishd -d -a :9999 -f /home/accel/varnish/etc/varnish.vcl -s file,/home/accel/varnish/var/cache,1G I get the following message storage_file: filename: /home/accel/varnish/var/cache size 1024 MB. Using old SHMFILE Debugging mode, enter "start" to start child start child (28673) Started Pushing vcls failed: Internal error: No VCL_conf symbol Child (28673) said Closed fds: 4 9 10 12 13 Child (28673) said Child starts Child (28673) said managed to mmap 1073741824 bytes of 1073741824 Child (28673) said Ready unlink ./vcl.1P9zoqAU.so OS: openSUSE 10.3 (X86-64) Varnish : 2.0.2 (built from source) gcc version 4.2.1 (SUSE Linux) What could be the issue here ? Thank you. -Paras -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 27 14:18:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 27 Nov 2008 14:18:54 -0000 Subject: [Varnish] #393: cache error ! Message-ID: <054.384ae02be9df15ea850c651e7372cce8@projects.linpro.no> #393: cache error ! ---------------------------------+------------------------------------------ Reporter: shawnlau | Type: defect Status: new | Priority: highest Milestone: Varnish 2.1 release | Component: build Version: 2.0 | Severity: critical Keywords: | ---------------------------------+------------------------------------------ The varnishd-2.0.2.tar.gz was downloaded by me the day before yesterday. I compiled and installed it in my vm Centos 5.1 system. Create the vcl.conf file by myself , and use below command boot it: /usr/local/varnish/sbin/varnishd -n /var/vcache -f /usr/local/varnish/etc/vcl.conf -a 0.0.0.0:80 -p thread_pool_max=51200 -p thread_pool_min=30000 -p thread_pools=5 -s \file,/var/vcache/varnish_cache.data,1G -w 30000,51200,10 -T 127.0.0.1:3500 -p client_http11=on It's running ok . On the client, when I input the url address and press enter, the web page could not display and also no error, if I click the goto button on the right side of the IE broswer, cache will hit the target ,then the page will display . I don't know why? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 27 19:35:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 27 Nov 2008 19:35:54 -0000 Subject: [Varnish] #394: How to configure persistant session Message-ID: <053.d4088e782febb8cbe880a1bae628b8b5@projects.linpro.no> #394: How to configure persistant session ---------------------------------+------------------------------------------ Reporter: telnetk | Type: defect Status: new | Priority: high Milestone: Varnish 2.1 release | Component: documentation Version: trunk | Severity: critical Keywords: | ---------------------------------+------------------------------------------ please need help- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 27 19:45:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 27 Nov 2008 19:45:42 -0000 Subject: [Varnish] #394: How to configure persistant session In-Reply-To: <053.d4088e782febb8cbe880a1bae628b8b5@projects.linpro.no> References: <053.d4088e782febb8cbe880a1bae628b8b5@projects.linpro.no> Message-ID: <062.c0269873b12ca0d81af78f81f2f6b441@projects.linpro.no> #394: How to configure persistant session ---------------------------+------------------------------------------------ Reporter: telnetk | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: documentation | Version: trunk Severity: critical | Resolution: invalid Keywords: | ---------------------------+------------------------------------------------ Changes (by perbu): * status: new => closed * resolution: => invalid Comment: This is not a support forum. Please send mail to the mailing list. You probably need to specify better what a persistant session is. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 27 19:48:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 27 Nov 2008 19:48:17 -0000 Subject: [Varnish] #393: cache error ! In-Reply-To: <054.384ae02be9df15ea850c651e7372cce8@projects.linpro.no> References: <054.384ae02be9df15ea850c651e7372cce8@projects.linpro.no> Message-ID: <063.809a8f132445605dcf9dc86d0652e9aa@projects.linpro.no> #393: cache error ! ----------------------+----------------------------------------------------- Reporter: shawnlau | Owner: Type: defect | Status: closed Priority: highest | Milestone: Varnish 2.1 release Component: build | Version: 2.0 Severity: critical | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => invalid Comment: Please send mail to the mailing list. The ticking system is for confirmed bugs. You probably need to document the error a bit better. Please see the documentation on the Wiki for instructions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 12:06:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 12:06:46 -0000 Subject: [Varnish] #395: question, varnish supports persistent sessions? Message-ID: <053.ea693832dc48a73d5d0598ad941b5ba6@projects.linpro.no> #395: question, varnish supports persistent sessions? -------------------------------+-------------------------------------------- Reporter: telnetk | Type: defect Status: new | Priority: normal Milestone: After Varnish 2.1 | Component: documentation Version: trunk | Severity: normal Keywords: | -------------------------------+-------------------------------------------- question, varnish supports persistent sessions? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 12:44:11 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 12:44:11 -0000 Subject: [Varnish] #390: varnish #3444 core dumps.. In-Reply-To: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> References: <054.0dbd81a32c10b855dd882b170d5f4863@projects.linpro.no> Message-ID: <063.0623d9836989980917d35d43b0584933@projects.linpro.no> #390: varnish #3444 core dumps.. ----------------------+----------------------------------------------------- Reporter: mtempels | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3445 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 12:44:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 12:44:31 -0000 Subject: [Varnish] #395: question, varnish supports persistent sessions? In-Reply-To: <053.ea693832dc48a73d5d0598ad941b5ba6@projects.linpro.no> References: <053.ea693832dc48a73d5d0598ad941b5ba6@projects.linpro.no> Message-ID: <062.259aca6e8f323d1b8550e74a16137d57@projects.linpro.no> #395: question, varnish supports persistent sessions? ---------------------------+------------------------------------------------ Reporter: telnetk | Owner: Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: documentation | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => invalid Comment: not at this time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 12:49:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 12:49:39 -0000 Subject: [Varnish] #385: Pluggable cache engines In-Reply-To: <052.70e37345207180ee7dfaef63a1966bff@projects.linpro.no> References: <052.70e37345207180ee7dfaef63a1966bff@projects.linpro.no> Message-ID: <061.619d3939db2cbfa173ce7a317a76f4f3@projects.linpro.no> #385: Pluggable cache engines -------------------------+-------------------------------------------------- Reporter: eugaia | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: The principle has been pondered, but the advantage seems speculative. The overhead of socket communications to another thread is very high, compared to direct VM access. But selection of the storage backends from VCL might happen as part of persistent storage. This does not really belong in a ticket, stuff like this should go in the post-2.0 wiki page, so I'm closing this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 13:06:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 13:06:21 -0000 Subject: [Varnish] #395: question, varnish supports persistent sessions? In-Reply-To: <053.ea693832dc48a73d5d0598ad941b5ba6@projects.linpro.no> References: <053.ea693832dc48a73d5d0598ad941b5ba6@projects.linpro.no> Message-ID: <062.31d9a1764e597222c1ce5222bca1837a@projects.linpro.no> #395: question, varnish supports persistent sessions? ---------------------------+------------------------------------------------ Reporter: telnetk | Owner: Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: documentation | Version: trunk Severity: normal | Resolution: invalid Keywords: | ---------------------------+------------------------------------------------ Comment (by telnetk): thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 28 18:21:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 28 Nov 2008 18:21:07 -0000 Subject: [Varnish] #396: IPv6 problem with management interface on localhost on Linux Message-ID: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> #396: IPv6 problem with management interface on localhost on Linux -------------------+-------------------------------------------------------- Reporter: olau | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I'm not super familiar with the socket API, so I don't know whether you can fix it, but I just upgraded a Debian testing box to Varnish 2.0.2 from 1.1.2 and had Varnish crash on me with the following error when run with "varnishd -d -d -a :80 -T localhost:6082 -f /etc/varnish/iola.vcl -s file,/var/lib/varnish/iola.dk/varnish_storage.bin,1G" {{{ socket(): Address family not supported by protocol Assert error in mgt_cli_telnet(), mgt_cli.c line 478: Condition(sock >= 0) not true. errno = 97 (Address family not supported by protocol) Aborted }}} If I replaced "-T localhost:6082" with "-T 127.0.0.1:6082" then it worked. Maybe it needs a check and fallback on IPv4? My /etc/hosts file contains an entry for localhost for both IPv4 and IPv6 (which might be a bug in Debian given that the kernel refuses the socket): {{{ 127.0.0.1 iola.dk localhost localhost.localdomain ::1 localhost ip6-localhost ip6-loopback }}} I don't think Varnish 1.1.2 had this problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 29 12:36:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 29 Nov 2008 12:36:24 -0000 Subject: [Varnish] #396: IPv6 problem with management interface on localhost on Linux In-Reply-To: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> References: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> Message-ID: <059.e9ffe1539d16af9f96eeb401c5017578@projects.linpro.no> #396: IPv6 problem with management interface on localhost on Linux --------------------+------------------------------------------------------- Reporter: olau | Owner: bahner Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by bahner): * owner: => bahner -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 29 12:38:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 29 Nov 2008 12:38:35 -0000 Subject: [Varnish] #396: IPv6 problem with management interface on localhost on Linux In-Reply-To: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> References: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> Message-ID: <059.2a04f15bc6c280846c3f87a9f5fca386@projects.linpro.no> #396: IPv6 problem with management interface on localhost on Linux --------------------+------------------------------------------------------- Reporter: olau | Owner: bahner Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by bahner): You should not have duplicate entries for localhost in /etc/hosts. Try getent hosts localhost and you will see that only the last entry is used. Remove localhost host from ::1. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 29 12:39:02 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 29 Nov 2008 12:39:02 -0000 Subject: [Varnish] #396: IPv6 problem with management interface on localhost on Linux In-Reply-To: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> References: <050.2f281a2f6c46f06db5db53761ef3b160@projects.linpro.no> Message-ID: <059.8cbc557d5ef8c7ec6f647db088b67df8@projects.linpro.no> #396: IPv6 problem with management interface on localhost on Linux --------------------+------------------------------------------------------- Reporter: olau | Owner: bahner Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by bahner): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Nov 29 13:41:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 29 Nov 2008 13:41:13 -0000 Subject: [Varnish] #397: varnish panic and restarts every 3-5 minutes Message-ID: <060.27b3b11a1b62f3ca458585ac81a37f8c@projects.linpro.no> #397: varnish panic and restarts every 3-5 minutes ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.0 Severity: major | Keywords: ----------------------------+----------------------------------------------- Hi, Varnish is restarting in every 3-5 minutes with a panic message. Nov 29 13:28:05 varnish-vsnl1 varnishd[19560]: Child (19640) Panic message: Assert error in WS_Release(), cache_ws.c line 170: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker)sp = 0x1f594004 { fd = 61, id = 61, xid = 596033830, client = 117.193.199.92:1242, step = STP_HIT, handling = 0x0, ws = 0x1f59404c { id = "sess", {s,f,r,e} = {0x1f5944dc,,+795,(nil),+8192}, }, worker = 0x214ff170 { }, vcl = { srcname = { "/etc/varnish/rediff.vcl", "Default", }, }, obj = 0x8e9d4000 { refcnt = 2, xid = 596017492, ws = 0x8e9d4018 { id = "obj", {s,f,r,e} = {0x8e9d41ec,,+3586,+3604,+3604}, }, http = { ws = 0x8e9d4018 { id = "obj", {s,f,r,e} = {0x8e9d41ec,,+3586,+3604,+3604}, }, hd = { "Date: Sat, 29 Nov 2008 13:20:06 GMT", "Last-Modified: Fri, 28 Nov 2008 10:35:22 GMT", "ETag: "6bc68-5fea-492fc96a"", "Content- Type: image/jpeg", "Content-Length Below is my configuration. backend datastore { .host = "ds.rediff.com"; .port = "80"; } backend adsstore { .host = "ads.rediff.com"; .port = "80"; } backend imads { .host = "ads.rediff.com"; .port = "80"; } acl purge { "localhost"; "202.137.232.0"/21; "203.197.35.0"/25; "202.54.124.128"/25; "203.199.83.0"/24; "59.160.240.0"/24; "220.226.195.0"/24; } sub vcl_recv { if (req.http.host ~ "^datastore.rediff.com") { set req.backend = datastore; }elseif ( req.http.host ~ "^adsstore.rediff.com") { set req.backend = adsstore; }elseif ( req.http.host ~ "^imads.rediff.com") { set req.backend = imads; }else{ error 401 "Bad Domain"; } if (req.request == "PURGE") { if(!client.ip ~ purge) { error 405 "Not Allowed"; } lookup; } if (req.request != "GET" && req.request != "HEAD") { pipe; } if (req.http.Expect) { pipe; } # normalize the Accept-Encoding header if (req.http.Accept-Encoding) { if (req.url ~ "\.(JPG|PNG|GIF|Jpg|Png|Gif|jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|flv|mp4|m4v)$") { # No point in compressing these remove req.http.Accept-Encoding; } elseif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elseif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } lookup; } sub vcl_pipe { pipe; } # ## Called when entering pass mode # sub vcl_pass { pass; } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } if (!obj.cacheable) { pass; } if (req.url ~ "\.(aif|aiff|au|avi|bin|bmp|cab|carb|cct|cdf|class|dcr|doc|dtd|exe|gcf|gff|grv|hdml|hqx|ico|ini|mov|mp3|nc|pct|pdf|ppc|pws|swa|swf|txt|vbs|w32|wav|wbmp|wml|wmlc|wmls|wmlsc|xml|xsd|xsl|zip)$") { if (req.http.host ~ "^imads.rediff.com") { set obj.ttl = 604800s; }else{ set obj.ttl = 2592000s; } } if (req.url ~ "\.(css|js|htm|html)$") { remove obj.http.Via; remove obj.http.Age; remove obj.http.X-Varnish; # remove obj.http.Vary; if (req.http.host ~ "^imads.rediff.com") { set obj.http.Cache-Control = "max-age=604800"; set obj.ttl = 604800s; }else{ set obj.http.Cache-Control = "max-age=2592000"; set obj.ttl = 2592000s; } } if (req.url ~ "\.(JPG|PNG|GIF|Jpg|Png|Gif|flv|gif|jpeg|jpg|png|mp4|m4v)$") { remove obj.http.Via; remove obj.http.Age; remove obj.http.X-Varnish; remove obj.http.Vary; if (req.http.host ~ "^imads.rediff.com") { set obj.http.Cache-Control = "max-age=604800"; set obj.ttl = 604800s; }else{ set obj.http.Cache-Control = "max-age=2592000"; set obj.ttl = 2592000s; } } set obj.http.Server = "Rediff CDN"; deliver; } # #sub vcl_hash { # set req.hash += req.url; # hash; #} ## Called when the requested object was not found in the cache # sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } fetch; } sub vcl_fetch { if (!obj.cacheable) { pass; } if (obj.http.Set-Cookie) { pass; } if (obj.status == 500 || obj.status == 501 || obj.status == 502 || obj.status == 503 || obj.status == 504){ set obj.ttl = 0s ; } if (req.url ~ "\.(css|js|html|htm)$") { if (req.http.host ~ "^imads.rediff.com") { set obj.ttl = 604800s ; set obj.http.cache-control = "max-age=604800"; }else{ set obj.ttl = 2592000s ; set obj.http.cache-control = "max-age=2592000"; } } if (req.url ~ "\.(JPG|PNG|GIF|Jpg|Png|Gif|flv|gif|jpeg|jpg|png|mp4|m4v|swf)$") { if (req.http.host ~ "^imads.rediff.com") { set obj.ttl = 604800s ; set obj.http.cache-control = "max-age=604800"; }else{ set obj.ttl = 2592000s ; set obj.http.cache-control = "max-age=2592000"; } } deliver; } sub vcl_deliver { remove resp.http.Via; remove resp.http.Age; remove resp.http.X-Varnish; # remove resp.http.Vary; deliver; } # ## Called when an object nears its expiry time # sub vcl_timeout { discard; } # ## Called when an object is about to be discarded # sub vcl_discard { discard; } DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/rediff.vcl \ -u varnish -g varnish \ -p thread_pool_max=4000 \ -p thread_pools=4 \ -p listen_depth=4096 \ -p lru_interval=3600 \ -h classic,500009 \ -p obj_workspace=4096 \ -s file,/var/lib/varnish/storage.bin,1G \ -s file,/var/lib/varnish/storage1.bin,1G" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Nov 30 06:20:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 30 Nov 2008 06:20:24 -0000 Subject: [Varnish] #398: logging off phpbb always causes "Error 503 Service Unavailable" Message-ID: <053.fcc528fb5f49a4e239de8466a1c0a6d5@projects.linpro.no> #398: logging off phpbb always causes "Error 503 Service Unavailable" ----------------------+----------------------------------------------------- Reporter: mmpower | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: Error 503 Service Unavailable ----------------------+----------------------------------------------------- I have the backend running phpbb (www.phpbb.com) forum software. everytime user logs out from phpbb the browser shows this kind of error message: "Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 1569421074 Varnish" there is no problem logging in to phpbb. no problme to login/off to other web apps on the same host via varnishd... Varnish version is 2.02. OS: linux (Fedora 6), 32 bit amount of ram : 6GB varnishlog trace info for the failing request: 14 SessionOpen c 72.83.129.191 54449 *:80 14 ReqStart c 72.83.129.191 54449 1569432969 14 RxRequest c GET 14 RxURL c /forum/login.php?logout=true&sid=cab5706b5795a7586969328f9df81f8c 14 RxProtocol c HTTP/1.1 14 RxHeader c Host: www.haiguinet.com 14 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 14 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 14 RxHeader c Accept-Language: en-us,en;q=0.5 14 RxHeader c Accept-Encoding: gzip,deflate 14 RxHeader c Accept-Charset: UTF-8,* 14 RxHeader c Keep-Alive: 300 14 RxHeader c Connection: keep-alive 14 RxHeader c Referer: http://www.haiguinet.com/forum/index.php?sid=cab5706b5795a7586969328f9df81f8c 14 RxHeader c Cookie: setframeview=0; userstatusserver=http%3A//211.100.30.224%3A8080/flashIM/wdkstatus; flashservers=rtmp%3A//211.100.30.224%3A80/flashIM%2Crtmp%3A//wdkchat1.vicp.net%3A80/freechat%2Chttp%3A//211.100.30.224%3A8080/flashgo%2Chttp%3A//wdkchat1.vicp.net%3 14 VCL_call c recv pass 14 VCL_call c pass pass 14 Backend c 10 default default 14 VCL_call c error deliver 14 Length c 453 14 VCL_call c deliver deliver 14 TxProtocol c HTTP/1.1 14 TxStatus c 503 14 TxResponse c Service Unavailable 14 TxHeader c Server: Varnish 14 TxHeader c Retry-After: 0 14 TxHeader c Content-Type: text/html; charset=utf-8 14 TxHeader c Content-Length: 453 14 TxHeader c Date: Sun, 30 Nov 2008 06:16:44 GMT 14 TxHeader c X-Varnish: 1569432969 14 TxHeader c Age: 0 14 TxHeader c Via: 1.1 varnish 14 TxHeader c Connection: close 14 ReqEnd c 1569432969 1228025804.806035519 1228025804.817787170 0.329633474 0.011698008 0.000053644 my VCL file: backend default { .host = "127.0.0.1"; .port = "81"; } sub vcl_recv { remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = client.ip; if (req.request == "GET" && req.url ~ "\.(jpg|jpeg|gif|ico|html|htm|css|js|pdf|xls|vsd|doc|ppt|iso)$") { lookup; } if (req.request == "GET" && (req.url ~ "www.haiguinet.com/$" || req.url ~ "www.haiguinet.com$" || req.url ~ "get_data.php\?")) { lookup; } if (req.http.Expect) { pipe; } if (req.http.Cache-Control ~ "no-cache") { pass; } } sub vcl_fetch { if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-cache" || obj.http.Cache-Control ~ "private") { pass; } if (req.url ~ "\.(png|gif|jpg|swf|css)$") { unset obj.http.set-cookie; } } -- Ticket URL: Varnish The Varnish HTTP Accelerator