From varnish-bugs at projects.linpro.no Sat May 2 17:45:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 02 May 2009 17:45:04 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> References: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> Message-ID: <062.1921695e2cb4e68f83f452c9cfcdc096@projects.linpro.no> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------------------+-------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: busy threads monitoring | -------------------------------------+-------------------------------------- Comment (by stockrt): This new patch I uploaded seems to be very consistent. Could you take a look at it? Cheers, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 09:31:06 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 09:31:06 -0000 Subject: [Varnish] #502: purge() doesn't understand && in a string Message-ID: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no> #502: purge() doesn't understand && in a string ----------------------+----------------------------------------------------- Reporter: Sesse | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Hello, Trying to do the following in vcl_recv(): purge("req.http.host == some.vhost && req.url ~ bleh") does not work; purge.list does not get a new entry, and syslog says (when I do purge.list, it seems) May 1 16:15:56 pannekake varnishd[4077]: Child (4078) said expected conditional (~, !~, == or !=) got "req.url"CLI result = 106 Any purge specification string without && in it (ie., only one term) seems to work fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 09:34:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 09:34:15 -0000 Subject: [Varnish] #503: Assertion failure when trying to fetch a large object Message-ID: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> #503: Assertion failure when trying to fetch a large object -------------------+-------------------------------------------------------- Reporter: Sesse | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Whenever a client tries to fetch an object with a large Content-length (larger than my cache), the Varnish child dies with: May 1 01:09:16 pannekake varnishd[21621]: Child (30929) Panic message: Assert error in STV_alloc(), stevedore.c line 90: Condition((st) != NULL) not true. thread = (cache-worker)sp = 0x7fa0e1708008 { fd = 13, id = 13, xid = 1892791164, client = 91.124.53.2:4907, step = STP_FETCH, handling = pass, err_code = 206, err_reason = (null), ws = 0x7fa0e1708070 { id = "sess", {s,f,r,e} = {0x7fa0e1708800,,+267,(nil),+16384}, }, worker = 0x45535420 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7fa121cea000 { refcnt = 1, xid = 1892791164, ws = 0x7fa121cea030 { id = "obj", {s,f,r,e} = {0x7fa121cea340,,+334,(nil),+8192}, }, http = { ws = 0x7fa121cea030 { id = "obj", {s,f,r,e} = {0x7fa121cea340,,+334,(nil),+8192}, }, hd = { "Date: Thu, 30 Apr 2009 23:09:16 GMT", "Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0 m The only way around this I've found is to somehow find all large objects on all my vhosts, and write rules to use ?pipe? for those. At the very least, Varnish should log a reasonable error in this case instead of an assertion failure. Verified in 2.0.4 and in SVN trunk as of 2009-05-01. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 10:15:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 10:15:45 -0000 Subject: [Varnish] #502: purge() doesn't understand && in a string In-Reply-To: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no> References: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no> Message-ID: <060.ab3a060c72f4bdd5d31f974d0e14d1e3@projects.linpro.no> #502: purge() doesn't understand && in a string ----------------------+----------------------------------------------------- Reporter: Sesse | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by Sesse): Actually the documentation is pretty confusing here. http://varnish.projects.linpro.no/wiki/VCLSyntaxPurge says: In the second form, the $string argument is split into fields like a CLI command line after which it is processed like the first form. It seems this does _not_ mean that it takes in the same syntax as the CLI ?purge? command (as I expected) -- the code paths for the two are different, although they both seem to add up in BAN_AddTest. VRT_purge_string() and ccf_purge() are similar but not identical -- in particular, ccf_purge() actually checks for the && here and there, while VRT_purge_string() seems to just expect "a1 a2 a3 a1 a2 a3" etc. without any && in the middle. So, without knowing the code, it seems that either the code should be changed (possibly unified with ccf_purge()), or the && signs should be removed from the documentation. FWIW, it also seems that VCL_purge() has the same issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 15:48:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 15:48:16 -0000 Subject: [Varnish] #504: syslog example is broken Message-ID: <051.f944c3c5a2163e9eab62db20d14fd064@projects.linpro.no> #504: syslog example is broken -------------------+-------------------------------------------------------- Reporter: Sesse | Type: documentation Status: new | Priority: normal Milestone: | Component: documentation Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- (Please let me know if I could change this myself; I cannot find a way to edit the wiki even though I am logged in.) http://varnish.projects.linpro.no/wiki/VCLExampleSyslog mentions that you should be able to run C{ #include syslog(LOG_INFO, "Something happened at VCL line XX."); }C However, if I dump that into vcl_fetch(), I get Message from C-compiler: ./vcl.1P9zoqAU.c: In function ?VGC_function_vcl_fetch?: ./vcl.1P9zoqAU.c:705: error: incompatible implicit declaration of function ?syslog? /usr/include/sys/syslog.h:190: error: previous implicit declaration of ?syslog? was here Running C-compiler failed, exit 1 VCL compilation failed If I put the #include at the top of my VCL file, all is fine, though. The documentation also claims I'm supposed to get something from varnishd -C, but running that (as root) has exactly zero output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 17:29:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 17:29:13 -0000 Subject: [Varnish] #505: changeset 4046 Breaks AJAX posts. Message-ID: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no> #505: changeset 4046 Breaks AJAX posts. ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ Since updating varnish past 4046, our site stopped accepting ajax POST data. I see that the POST gets through to the back end but it never gets accepted. I am guessing it might be getting cut off. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 17:35:46 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 17:35:46 -0000 Subject: [Varnish] #505: changeset 4046 Breaks AJAX posts. In-Reply-To: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no> References: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no> Message-ID: <062.88af9d00c098c849c8f5d2f78ccc5cff@projects.linpro.no> #505: changeset 4046 Breaks AJAX posts. ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by victori): I forgot to mention I am using pipe for the POST. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun May 3 19:30:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 03 May 2009 19:30:24 -0000 Subject: [Varnish] #504: syslog example is broken In-Reply-To: <051.f944c3c5a2163e9eab62db20d14fd064@projects.linpro.no> References: <051.f944c3c5a2163e9eab62db20d14fd064@projects.linpro.no> Message-ID: <060.42b9623416719a0e41799caff88fc5f6@projects.linpro.no> #504: syslog example is broken ---------------------------+------------------------------------------------ Reporter: Sesse | Owner: perbu Type: documentation | Status: assigned Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by perbu): * owner: => perbu * status: new => assigned Comment: You've been added to the wiki group. You mind fixing it? :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 07:41:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 07:41:13 -0000 Subject: [Varnish] #504: syslog example is broken In-Reply-To: <051.f944c3c5a2163e9eab62db20d14fd064@projects.linpro.no> References: <051.f944c3c5a2163e9eab62db20d14fd064@projects.linpro.no> Message-ID: <060.3b9e62ea3734bfe6a83cf192def91c9a@projects.linpro.no> #504: syslog example is broken ---------------------------+------------------------------------------------ Reporter: Sesse | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: Fixed wiki page to mention that #include cannot be done inside VCL functions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 07:43:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 07:43:18 -0000 Subject: [Varnish] #505: changeset 4046 Breaks AJAX posts. In-Reply-To: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no> References: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no> Message-ID: <062.2787fc37bd0a9a6e4772abfb8688d517@projects.linpro.no> #505: changeset 4046 Breaks AJAX posts. ---------------------+------------------------------------------------------ Reporter: victori | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4047]) r4046 forgot to reset SO_LINGER for pipe handling which basically broke pipehandling. Fixes #505 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 07:44:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 07:44:39 -0000 Subject: [Varnish] #503: Assertion failure when trying to fetch a large object In-Reply-To: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> References: <051.365f2683f5c3171e1cc19a330c44dbab@projects.linpro.no> Message-ID: <060.0fcb8246ae8f1808d7a1c88e4dec1aa1@projects.linpro.no> #503: Assertion failure when trying to fetch a large object --------------------+------------------------------------------------------- Reporter: Sesse | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: You have run out of storage, plain and simple. Specify some more with -s, or handle really huge objects with pipe. We have plans to make pass able to pipe-line, but that is at least one major version away. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 08:05:30 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 08:05:30 -0000 Subject: [Varnish] #502: purge() doesn't understand && in a string In-Reply-To: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no> References: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no> Message-ID: <060.fb787509b2eb67e19f4941ba5c637b10@projects.linpro.no> #502: purge() doesn't understand && in a string ----------------------+----------------------------------------------------- Reporter: Sesse | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4048]) Fix a parse error in VCL:purge() string version. Fixes #502 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 13:29:32 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 13:29:32 -0000 Subject: [Varnish] #486: link failure with --as-needed In-Reply-To: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> References: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> Message-ID: <067.19ad85970d977f181afa11f71e1e75f0@projects.linpro.no> #486: link failure with --as-needed --------------------------+------------------------------------------------- Reporter: thilobangert | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: Keywords: | --------------------------+------------------------------------------------- Changes (by sky): * status: closed => reopened * resolution: fixed => Comment: This breaks gcc 4.01 on OSX which doesn't recognize -as-needed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 13:45:49 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 13:45:49 -0000 Subject: [Varnish] #486: link failure with --as-needed In-Reply-To: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> References: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> Message-ID: <067.633d47ec783494654279a18131515f36@projects.linpro.no> #486: link failure with --as-needed --------------------------+------------------------------------------------- Reporter: thilobangert | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: Keywords: | --------------------------+------------------------------------------------- Comment (by sky): also breaks {{{ Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable- languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable- shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include- dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable- checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:04:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:04:10 -0000 Subject: [Varnish] #486: link failure with --as-needed In-Reply-To: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> References: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> Message-ID: <067.742485f8e6fd6a5d40be24558c984ce1@projects.linpro.no> #486: link failure with --as-needed --------------------------+------------------------------------------------- Reporter: thilobangert | Owner: Type: enhancement | Status: closed Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: fixed in r4050 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:06:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:06:05 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.92419a823779911043c68afe1f9f9e43@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * priority: normal => low * component: build => varnishd Comment: Juding by the clients.txt tcpdump, your backend acts wrong by resetting the sessions without having previously closed it with FIN. That's not the same as Varnish cannot be more graceful about this, but it takes a low priority. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:10:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:10:10 -0000 Subject: [Varnish] #491: Crash in 2.0.4 In-Reply-To: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> References: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> Message-ID: <058.3359969be5ad3a3db4e75192431622c6@projects.linpro.no> #491: Crash in 2.0.4 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Old description: > {{{ > Panic message: Assert error in WS_Release(), cache_ws.c line 170: > Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker)sp = > 0x7f4ff0277008 { fd = 1043, id = 1043, xid = 1662105498, client = > 208.68.167.134:35521, step = STP_FETCH, handling = error, err_code > = 200, err_reason = (null), ws = 0x7f4ff0277078 { id = "sess", > {s,f,r,e} = {0x7f4ff0277808,,+3354,(nil),+32768}, }, worker = > 0x7f52e9083be0 { }, vcl = { srcname = { "input", > "Default", }, }, obj = 0x7f6d71a0b000 { refcnt = 1, xid = > 1662105498, ws = 0x7f6d71a0b028 { id = "obj", {s,f,r,e} > = {0x7f6d71a0b358,,+327,+3240,+3240}, }, http = { ws = > 0x7f6d71a0b028 { id = "obj", {s,f,r,e} = > {0x7f6d71a0b358,,+327,+3240,+3240}, }, hd = { "Date: > Tue, 21 Apr 2009 10:01:29 GMT", "Server: Apache", > "Content-language: en", "X-Served-By-Backend: > > }}} New description: {{{ Panic message: Assert error in WS_Release(), cache_ws.c line 170: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker)sp = 0x7f4ff0277008 { fd = 1043, id = 1043, xid = 1662105498, client = 208.68.167.134:35521, step = STP_FETCH, handling = error, err_code = 200, err_reason = (null), ws = 0x7f4ff0277078 { id = "sess", {s,f,r,e} = {0x7f4ff0277808,,+3354,(nil),+32768}, }, worker = 0x7f52e9083be0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f6d71a0b000 { refcnt = 1, xid = 1662105498, ws = 0x7f6d71a0b028 { id = "obj", {s,f,r,e} = {0x7f6d71a0b358,,+327,+3240,+3240}, }, http = { ws = 0x7f6d71a0b028 { id = "obj", {s,f,r,e} = {0x7f6d71a0b358,,+327,+3240,+3240}, }, hd = { "Date: Tue, 21 Apr 2009 10:01:29 GMT", "Server: Apache", "Content-language: en", "X-Served-By-Backend: }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:12:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:12:04 -0000 Subject: [Varnish] #488: child process restart with "Missing errorhandling code in sma_alloc()" error In-Reply-To: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> References: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> Message-ID: <063.16f90ff8073acc02a69bb0f16a0d15cb@projects.linpro.no> #488: child process restart with "Missing errorhandling code in sma_alloc()" error --------------------------------------+------------------------------------- Reporter: flyincat | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: worksforme Keywords: storage_malloc.c restart | --------------------------------------+------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: It looks like you are simply out of malloc(3)'able memory. Try using -sfile... instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:12:36 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:12:36 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.504fe3310bea3b7dc4bc7542c0a7a9f8@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:37:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:37:40 -0000 Subject: [Varnish] #381: Extra information useful in VCLExamplePurging In-Reply-To: <049.ffbf87943082984dd9bec3d1c2f76fca@projects.linpro.no> References: <049.ffbf87943082984dd9bec3d1c2f76fca@projects.linpro.no> Message-ID: <058.51d5e91f279b899b4717027844779e0f@projects.linpro.no> #381: Extra information useful in VCLExamplePurging ---------------------------+------------------------------------------------ Reporter: ldr | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Added some more info on purges now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:45:09 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:45:09 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.2f3c9a6ef164ffbbfad3d1ef4b5b6bf9@projects.linpro.no> #330: 2.0-beta1 dies with accept error ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I believe this is completely fixed now, I just seems to have forgotten to close the ticket. Please reopen if you can reproduce this with 2.0.4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 19:50:55 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 19:50:55 -0000 Subject: [Varnish] #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 Message-ID: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 ----------------------+----------------------------------------------------- Reporter: danger | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Keywords: ----------------------+----------------------------------------------------- I am getting the following crash on my production box when I enable one of my backends (just by defining it, not really using it): ---- {{{ May 4 21:36:08 gw kernel: pid 2100 (varnishd), uid 80: exited on signal 6 May 4 19:36:08 gw varnishd[1755]: Child (2100) Panic message: Assert error in http_StatusMessage(), cache_http.c line 111: Condition(status >= 100 && status <= 999) not true. errno = 22 (Invalid argument) thread = (cache-worker)sp = 0x806b3e008 { fd = 73, id = 73, xid = 1986051483, client = 78.99.126.13:2630, step = STP_FETCH, handling = fetch, ws = 0x806b3e078 { id = "sess", {s,f,r,e} = {0x806b3e808,,+1196,0x0,+16384}, }, worker = 0x7ffffcde7a70 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x806e39000 { refcnt = 1, xid = 1986051483, ws = 0x806e39028 { id = "obj", {s,f,r,e} = {0x806e39358,,0x806e39358,0x0,+7336}, }, http = { ws = 0x806e39028 { id = "obj", {s,f,r,e} = {0x806e39358,,0x806e39358,0x0,+7336}, }, }, len = 0, store = { }, }, }, }}} ---- System info: {{{ varnishd (varnish-2.0.4) FreeBSD 7.2-RELEASE #2: Mon May 4 19:01:03 CEST 2009 amd64 usable memory = 8582840320 (8185 MB) varnishd_storage="malloc,4G" varnishd_args="-p thread_pools=4 -p listen_depth=4096 -p lru_interval=3600 -h classic,377291 -p obj_workspace=4096 -p thread_pool_max=4000 -t 604800" }}} If you need any other information, just let me know, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 20:09:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 20:09:15 -0000 Subject: [Varnish] #348: Two extra parameters to control whether to include Via:varnish and X-Varnish header items In-Reply-To: <052.f74396f9c11e682f0fbf726a2036fe9e@projects.linpro.no> References: <052.f74396f9c11e682f0fbf726a2036fe9e@projects.linpro.no> Message-ID: <061.2d58c87bed5ab7c3b943e1336a7c8faa@projects.linpro.no> #348: Two extra parameters to control whether to include Via:varnish and X-Varnish header items -------------------------+-------------------------------------------------- Reporter: 191919 | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: Please just use VCL for this, the headers can be removed in vcl_deliver. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 20:17:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 20:17:19 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.874b0d4e8cb3c04ecf07de181e070885@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by cra3): The backend would send a FIN but before it can it gets more data from Varnish. Since sending the FIN can't be instant- I don't think there is anything the backend can do different to avoid the problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 20:22:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 20:22:42 -0000 Subject: [Varnish] #493: varnish-tools/regress broken In-Reply-To: <051.8b028e6dd7e5c51c90ba0cc07d3f50ad@projects.linpro.no> References: <051.8b028e6dd7e5c51c90ba0cc07d3f50ad@projects.linpro.no> Message-ID: <060.2a187bf07b4d4824c50c43232dfae21c@projects.linpro.no> #493: varnish-tools/regress broken ---------------------+------------------------------------------------------ Reporter: bolav | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: regress | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4051]) Get rid of old regress suite The old regress suite has been superseded by varnishtest, so nuke this. Fixes #493 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 4 20:26:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 04 May 2009 20:26:25 -0000 Subject: [Varnish] #473: Small errors in example code. In-Reply-To: <052.2444ffdd455338474faedf608accc486@projects.linpro.no> References: <052.2444ffdd455338474faedf608accc486@projects.linpro.no> Message-ID: <061.c31f93ce2628adf0eff0a64fb654d824@projects.linpro.no> #473: Small errors in example code. ---------------------------+------------------------------------------------ Reporter: rhalff | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks a lot, fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 5 09:50:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 05 May 2009 09:50:31 -0000 Subject: [Varnish] #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 In-Reply-To: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> References: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> Message-ID: <061.2764d649ed438961b75f4ec0758f6fc6@projects.linpro.no> #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 ----------------------+----------------------------------------------------- Reporter: danger | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by danger): As per Mithrandir at varnish irc channel, I have attached vcl config file. when I uncomment web1 backend, the boo begins. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 5 17:03:55 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 05 May 2009 17:03:55 -0000 Subject: [Varnish] #507: Segfaults with SVN 4051M Message-ID: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> #507: Segfaults with SVN 4051M ---------------------+------------------------------------------------------ Reporter: victori | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ The last stable build that was useable on Solaris was r4043. Whatever was modified past r4043 has been completely unstable on solaris. It stays up 30-45 minutes at a time before segfaulting. May 5 09:44:27 Executing start method ("newtask -p highfile /opt/extra/sbin/varnishd -f /opt/extra/etc/varnish/default.vcl -a 72.11.142.91:80 -p listen_depth=4096 -p thread_pool_max=4000 -p thread_pool_min=8 -s malloc,256m -p sess_timeout=10 -p max_restarts=12 -p connect_timeout=1s -p cli_timeout=10 -p client_http11=on -p obj_workspace=65536 -p sess_workspace=131072 -p thread_pools=4 -T 127.0.0.1:8086 -u webservd -F &"). ] storage_malloc: max size 256 MB. Using old SHMFILE child (18165) Started Child (18165) said Closed fds: 3 4 5 8 9 11 12 Child (18165) said Child starts Child (18165) said Ready [ May 5 09:44:27 Stopping because process dumped core. ] [ May 5 09:44:27 Executing stop method (:kill). ] Manager got SIGINT Stopping Child -- Ticket URL: Varnish The Varnish HTTP Accelerator From flyincat at gmail.com Wed May 6 05:40:59 2009 From: flyincat at gmail.com (Kevin Yu) Date: Wed, 6 May 2009 13:40:59 +0800 Subject: [Varnish] #488: child process restart with "Missing errorhandling code in sma_alloc()" error In-Reply-To: <063.16f90ff8073acc02a69bb0f16a0d15cb@projects.linpro.no> References: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> <063.16f90ff8073acc02a69bb0f16a0d15cb@projects.linpro.no> Message-ID: <37d9b06f0905052240p45b349f4p1b1ef05f92ba8b00@mail.gmail.com> Hi, Here's a new situation after I used -s file instead of malloc. Panic message: Missing errorhandling code in vca_acct(), cache_acceptor.c line 242: Condition((sp) != 0) not true. errno = 12 (Cannot allocate memory) thread = (cache-acceptor) and this happens more frequently than the situation I used malloc. Kevin Yu Mail: flyincat at gmail.com On Tue, May 5, 2009 at 3:12 AM, Varnish wrote: > #488: child process restart with "Missing errorhandling code in sma_alloc()" > error > --------------------------------------+------------------------------------- > ?Reporter: ?flyincat ? ? ? ? ? ? ? ? ?| ? ? ? ?Owner: ?phk > ? ? Type: ?defect ? ? ? ? ? ? ? ? ? ?| ? ? ? Status: ?closed > ?Priority: ?high ? ? ? ? ? ? ? ? ? ? ?| ? ?Milestone: > Component: ?varnishd ? ? ? ? ? ? ? ? ?| ? ? ?Version: ?2.0 > ?Severity: ?major ? ? ? ? ? ? ? ? ? ? | ? Resolution: ?worksforme > ?Keywords: ?storage_malloc.c restart ?| > --------------------------------------+------------------------------------- > Changes (by phk): > > ?* status: ?new => closed > ?* resolution: ?=> worksforme > > Comment: > > ?It looks like you are simply out of malloc(3)'able memory. ?Try using > ?-sfile... instead. > > -- > Ticket URL: > Varnish > The Varnish HTTP Accelerator > _______________________________________________ > varnish-bugs mailing list > varnish-bugs at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-bugs > From varnish-bugs at projects.linpro.no Fri May 8 09:49:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 May 2009 09:49:05 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). Message-ID: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Varnish 2.0.4 started crashing more often under load. Load is ~1k hits/s. Red Hat Enterprise Linux Server release 5 (Tikanga) # uname -s -r -m -p -i -o Linux 2.6.18-92.1.13.el5 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa | grep varnish varnish-libs-devel-2.0.4-1.el5 varnish-2.0.4-1.el5 varnish-debuginfo-2.0.4-1.el5 varnish-libs-2.0.4-1.el5 custom vcl, with heavy use of backends, health probes and directors. I can send vcl in private if necessary. /var/log/messages: May 8 06:45:35 rabbla varnishd[11699]: Child (24950) died signal=6 (core dumped) May 8 06:45:35 rabbla varnishd[11699]: Child (24950) Panic message: Assert error in VRT_r_req_backend_healthy(), cache_vrt.c line 663: Condition((sp->director) != NULL) not true. thread = (cache-worker)sp = 0x2aabeb9e0008 { fd = 49, id = 49, xid = 478829260, client = 87.238.55.90:57525, step = STP_DELIVER, handling = error, ws = 0x2aabeb9e0078 { id = "sess", {s,f,r,e} = {0x2aabeb9e0808,,+6011,(nil),+16384}, }, worker = 0x5d742bd0 { }, vcl = { srcname = { "input", "Default", "/etc/varnish/publications-begin.txt", "/etc/varnish/include- clusters. vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish /include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/ include-clusters.vcl", "/etc/varnish/publications-end.txt", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include- clusters.vcl", "/etc/varnish/include-clus (gdb) bt #0 0x0000003abde30155 in raise () from /lib64/libc.so.6 #1 0x0000003abde31bf0 in abort () from /lib64/libc.so.6 #2 0x000000000041af57 in pan_ic (func=, file=, line=, cond=, err=64, xxx=) at cache_panic.c:317 #3 0x00000000004200c5 in VRT_r_req_backend_healthy (sp=0x2aabebe4f008) at cache_vrt.c:663 #4 0x00002aabeb5071c8 in ?? () #5 0x000000005cc96bd0 in ?? () #6 0x00002aabebe4f008 in ?? () #7 0x00002aabebe4f008 in ?? () #8 0x000000000041f416 in VCL_deliver_method (sp=0x2aabebe4f008) at ../../include /vcl_returns.h:59 #9 0x000000000040f77a in cnt_deliver (sp=0x2aabebe4f008) at cache_center.c:166 #10 0x00000000004104ba in CNT_Session (sp=0x5cc94b20) at steps.h:42 #11 0x000000000041c4f2 in wrk_do_cnt_sess (w=0x5cc96bd0, priv=) at cache_pool.c:398 #12 0x000000000041bbbf in wrk_thread (priv=0x2ad8203331f0) at cache_pool.c:310 #13 0x0000003abe6062f7 in start_thread () from /lib64/libpthread.so.0 #14 0x0000003abded1b6d in clone () from /lib64/libc.so.6 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri May 8 13:04:52 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 08 May 2009 13:04:52 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> Message-ID: <063.228543344da580dd65a64dc0446c6f5f@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by nicholas): Correction, we downgraded to 2.0.3, and it has the same issues. So it seems we have an increase in health probes coinciding with the upgrade to 2.0.4. As a workaround we are throwing out most of the probes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 07:54:52 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 07:54:52 -0000 Subject: [Varnish] #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 In-Reply-To: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> References: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> Message-ID: <061.8a7d6d77fcb71765da5a246156dceca0@projects.linpro.no> #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 ----------------------+----------------------------------------------------- Reporter: danger | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > I am getting the following crash on my production box when I enable one > of my backends (just by defining it, not really using it): > > ---- > > {{{ > May 4 21:36:08 gw kernel: pid 2100 (varnishd), uid 80: exited on signal > 6 > May 4 19:36:08 gw varnishd[1755]: Child (2100) Panic message: Assert > error in http_StatusMessage(), cache_http.c line 111: Condition(status > >= 100 && status <= 999) not true. errno = 22 (Invalid argument) thread > = (cache-worker)sp = 0x806b3e008 { fd = 73, id = 73, xid = 1986051483, > client = 78.99.126.13:2630, step = STP_FETCH, handling = fetch, ws > = 0x806b3e078 { id = "sess", {s,f,r,e} = > {0x806b3e808,,+1196,0x0,+16384}, }, worker = 0x7ffffcde7a70 { > }, vcl = { srcname = { "input", "Default", > }, }, obj = 0x806e39000 { refcnt = 1, xid = 1986051483, ws > = 0x806e39028 { id = "obj", {s,f,r,e} = > {0x806e39358,,0x806e39358,0x0,+7336}, }, http = { ws = > 0x806e39028 { id = "obj", {s,f,r,e} = > {0x806e39358,,0x806e39358,0x0,+7336}, }, }, len = 0, > store = { }, }, }, > }}} > > ---- > > System info: > > {{{ > varnishd (varnish-2.0.4) > FreeBSD 7.2-RELEASE #2: Mon May 4 19:01:03 CEST 2009 amd64 > usable memory = 8582840320 (8185 MB) > varnishd_storage="malloc,4G" > varnishd_args="-p thread_pools=4 -p listen_depth=4096 -p > lru_interval=3600 -h classic,377291 -p obj_workspace=4096 -p > thread_pool_max=4000 -t 604800" > }}} > > If you need any other information, just let me know, thanks! New description: I am getting the following crash on my production box when I enable one of my backends (just by defining it, not really using it): ---- {{{ May 4 21:36:08 gw kernel: pid 2100 (varnishd), uid 80: exited on signal 6 May 4 19:36:08 gw varnishd[1755]: Child (2100) Panic message: Assert error in http_StatusMessage(), cache_http.c line 111: Condition(status >= 100 && status <= 999) not true. errno = 22 (Invalid argument) thread = (cache-worker)sp = 0x806b3e008 { fd = 73, id = 73, xid = 1986051483, client = 78.99.126.13:2630, step = STP_FETCH, handling = fetch, ws = 0x806b3e078 { id = "sess", {s,f,r,e} = {0x806b3e808,,+1196,0x0,+16384}, }, worker = 0x7ffffcde7a70 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x806e39000 { refcnt = 1, xid = 1986051483, ws = 0x806e39028 { id = "obj", {s,f,r,e} = {0x806e39358,,0x806e39358,0x0,+7336}, }, http = { ws = 0x806e39028 { id = "obj", {s,f,r,e} = {0x806e39358,,0x806e39358,0x0,+7336}, }, }, len = 0, store = { }, }, }, }}} ---- System info: {{{ varnishd (varnish-2.0.4) FreeBSD 7.2-RELEASE #2: Mon May 4 19:01:03 CEST 2009 amd64 usable memory = 8582840320 (8185 MB) varnishd_storage="malloc,4G" varnishd_args="-p thread_pools=4 -p listen_depth=4096 -p lru_interval=3600 -h classic,377291 -p obj_workspace=4096 -p thread_pool_max=4000 -t 604800" }}} If you need any other information, just let me know, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 08:14:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 08:14:56 -0000 Subject: [Varnish] #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 In-Reply-To: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> References: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no> Message-ID: <061.db4d8ea8a6b2d3760a2b678bf16769f8@projects.linpro.no> #506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6 ----------------------+----------------------------------------------------- Reporter: danger | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4052]) Be more paranoid about backend responses, a response of: HTTP/1.1 1000\n\r\n\r would panic us trying to find a suitable message for 1000. Now we 503 the response instead. Fixes #506 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 10:01:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 10:01:05 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> Message-ID: <063.6a988b448b71fd775be09e587ca4420c@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > Varnish 2.0.4 started crashing more often under load. Load is ~1k hits/s. > > Red Hat Enterprise Linux Server release 5 (Tikanga) > # uname -s -r -m -p -i -o > Linux 2.6.18-92.1.13.el5 x86_64 x86_64 x86_64 GNU/Linux > # rpm -qa | grep varnish > varnish-libs-devel-2.0.4-1.el5 > varnish-2.0.4-1.el5 > varnish-debuginfo-2.0.4-1.el5 > varnish-libs-2.0.4-1.el5 > > custom vcl, with heavy use of backends, health probes and directors. I > can send vcl in private if necessary. > > /var/log/messages: > May 8 06:45:35 rabbla varnishd[11699]: Child (24950) died signal=6 (core > dumped) > May 8 06:45:35 rabbla varnishd[11699]: Child (24950) Panic message: > Assert error in VRT_r_req_backend_healthy(), cache_vrt.c line 663: > Condition((sp->director) != NULL) not true. thread = (cache-worker)sp = > 0x2aabeb9e0008 { fd = 49, id = 49, xid = 478829260, client = > 87.238.55.90:57525, step = STP_DELIVER, handling = error, ws = > 0x2aabeb9e0078 { id = "sess", {s,f,r,e} = > {0x2aabeb9e0808,,+6011,(nil),+16384}, }, worker = 0x5d742bd0 { > }, vcl = { srcname = { "input", "Default", > "/etc/varnish/publications-begin.txt", "/etc/varnish/include- > clusters. > vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish > /include-clusters.vcl", "/etc/varnish/include-clusters.vcl", > "/etc/varnish/include-clusters.vcl", "/etc/varnish/ > include-clusters.vcl", "/etc/varnish/publications-end.txt", > "/etc/varnish/include-clusters.vcl", "/etc/varnish/include- > clusters.vcl", "/etc/varnish/include-clus > > (gdb) bt > #0 0x0000003abde30155 in raise () from /lib64/libc.so.6 > #1 0x0000003abde31bf0 in abort () from /lib64/libc.so.6 > #2 0x000000000041af57 in pan_ic (func=, file= optimized out>, line=, cond=, > err=64, xxx=) at cache_panic.c:317 > #3 0x00000000004200c5 in VRT_r_req_backend_healthy (sp=0x2aabebe4f008) > at cache_vrt.c:663 > #4 0x00002aabeb5071c8 in ?? () > #5 0x000000005cc96bd0 in ?? () > #6 0x00002aabebe4f008 in ?? () > #7 0x00002aabebe4f008 in ?? () > #8 0x000000000041f416 in VCL_deliver_method (sp=0x2aabebe4f008) at > ../../include /vcl_returns.h:59 > #9 0x000000000040f77a in cnt_deliver (sp=0x2aabebe4f008) at > cache_center.c:166 > #10 0x00000000004104ba in CNT_Session (sp=0x5cc94b20) at steps.h:42 > #11 0x000000000041c4f2 in wrk_do_cnt_sess (w=0x5cc96bd0, priv= optimized out>) at cache_pool.c:398 > #12 0x000000000041bbbf in wrk_thread (priv=0x2ad8203331f0) at > cache_pool.c:310 > #13 0x0000003abe6062f7 in start_thread () from /lib64/libpthread.so.0 > #14 0x0000003abded1b6d in clone () from /lib64/libc.so.6 New description: Varnish 2.0.4 started crashing more often under load. Load is ~1k hits/s. {{{ Red Hat Enterprise Linux Server release 5 (Tikanga) # uname -s -r -m -p -i -o Linux 2.6.18-92.1.13.el5 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa | grep varnish varnish-libs-devel-2.0.4-1.el5 varnish-2.0.4-1.el5 varnish-debuginfo-2.0.4-1.el5 varnish-libs-2.0.4-1.el5 custom vcl, with heavy use of backends, health probes and directors. I can send vcl in private if necessary. /var/log/messages: May 8 06:45:35 rabbla varnishd[11699]: Child (24950) died signal=6 (core dumped) May 8 06:45:35 rabbla varnishd[11699]: Child (24950) Panic message: Assert error in VRT_r_req_backend_healthy(), cache_vrt.c line 663: Condition((sp->director) != NULL) not true. thread = (cache-worker)sp = 0x2aabeb9e0008 { fd = 49, id = 49, xid = 478829260, client = 87.238.55.90:57525, step = STP_DELIVER, handling = error, ws = 0x2aabeb9e0078 { id = "sess", {s,f,r,e} = {0x2aabeb9e0808,,+6011,(nil),+16384}, }, worker = 0x5d742bd0 { }, vcl = { srcname = { "input", "Default", "/etc/varnish/publications-begin.txt", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/publications-end.txt", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clusters.vcl", "/etc/varnish/include-clus (gdb) bt #0 0x0000003abde30155 in raise () from /lib64/libc.so.6 #1 0x0000003abde31bf0 in abort () from /lib64/libc.so.6 #2 0x000000000041af57 in pan_ic (func=, file=, line=, cond=, err=64, xxx=) at cache_panic.c:317 #3 0x00000000004200c5 in VRT_r_req_backend_healthy (sp=0x2aabebe4f008) at cache_vrt.c:663 #4 0x00002aabeb5071c8 in ?? () #5 0x000000005cc96bd0 in ?? () #6 0x00002aabebe4f008 in ?? () #7 0x00002aabebe4f008 in ?? () #8 0x000000000041f416 in VCL_deliver_method (sp=0x2aabebe4f008) at ../../include /vcl_returns.h:59 #9 0x000000000040f77a in cnt_deliver (sp=0x2aabebe4f008) at cache_center.c:166 #10 0x00000000004104ba in CNT_Session (sp=0x5cc94b20) at steps.h:42 #11 0x000000000041c4f2 in wrk_do_cnt_sess (w=0x5cc96bd0, priv=) at cache_pool.c:398 #12 0x000000000041bbbf in wrk_thread (priv=0x2ad8203331f0) at cache_pool.c:310 #13 0x0000003abe6062f7 in start_thread () from /lib64/libpthread.so.0 #14 0x0000003abded1b6d in clone () from /lib64/libc.so.6 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 10:04:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 10:04:28 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.2f59bfff73a660b21fb1c7d6c563b357@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Is there any chance you can get a backtrace from a core dump ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 10:07:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 10:07:50 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.cc32ccaf9507e4de4e82f07304dc128e@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > The following problem has been observed in r3965, as well as r4033: > > Periodically, at irregular intervals, varnish on a production server will > issue the following error, and restart. As you know, this causes varnish > to lose the cache, and subsequently the website is not very usable for > several minutes afterwards. > > {{{ > Apr 15 22:41:49 varnishd[11662]: Child (11663) died > signal=6 > Apr 15 22:41:49 varnishd[11662]: Child (11663) Panic > message: Assert error in BAN_CheckObject(), cache_ban.c line 423: > Condition((o->ban) != NULL) not true. thread = (cache-worker)sp = > 0x2aaaf504b008 { fd = 9, id = 9, xid = 1986591368, client = > 127.0.0.1:44680, step = STP_LOOKUP, handling = hash, ws = > 0x2aaaf504b070 { id = "sess", {s,f,r,e} = > {0x2aaaf504b800,,+297,(nil),+16384}, }, worker = 0x4600a430 { > }, vcl = { srcname = { "input", "Default", > }, }, }, > Apr 15 22:41:49 varnishd[11662]: Child cleanup complete > Apr 15 22:41:49 varnishd[11662]: child (20389) Started > Apr 15 22:41:49 varnishd[11662]: Child (20389) said > Closed fds: 4 5 6 9 10 12 13 > Apr 15 22:41:49 varnishd[11662]: Child (20389) said > Child starts > Apr 15 22:41:49 varnishd[11662]: Child (20389) said > managed to mmap 1073741824 bytes of 1073741824 > Apr 15 22:41:49 varnishd[11662]: Child (20389) said > Ready > }}} > > This was previously also observed at the following times: > > {{{ > * r3965 > Mar 10 06:21:27 > Mar 18 10:37:45 > Mar 28 07:59:44 > Mar 28 11:52:40 > Mar 30 16:41:45 > Apr 1 11:41:25 > Apr 6 09:47:34 > Apr 6 15:29:26 > Apr 6 21:10:02 > Apr 7 10:50:43 > Apr 7 22:05:46 > Apr 9 06:56:42 > Apr 9 13:16:57 > Apr 9 19:53:26 > * update to r4033 > Apr 15 22:41:49 > }}} > > Varnish is serving a plone website using pound for loadbalancing. The > website serves up to 80,000 GET-requests per hour. > > Varnish is running on a dual-quad-core machine using Intel E5420 > processors @2.5 GHz with 16 GB RAM, where varnish has a 1 GB cache. > > If you need further specifics to debug the problem, I will gladly provide > them. New description: The following problem has been observed in r3965, as well as r4033: Periodically, at irregular intervals, varnish on a production server will issue the following error, and restart. As you know, this causes varnish to lose the cache, and subsequently the website is not very usable for several minutes afterwards. {{{ Apr 15 22:41:49 varnishd[11662]: Child (11663) died signal=6 Apr 15 22:41:49 varnishd[11662]: Child (11663) Panic message: Assert error in BAN_CheckObject(), cache_ban.c line 423: Condition((o->ban) != NULL) not true. thread = (cache-worker)sp = 0x2aaaf504b008 { fd = 9, id = 9, xid = 1986591368, client = 127.0.0.1:44680, step = STP_LOOKUP, handling = hash, ws = 0x2aaaf504b070 { id = "sess", {s,f,r,e} = {0x2aaaf504b800,,+297,(nil),+16384}, }, worker = 0x4600a430 { }, vcl = { srcname = { "input", "Default", }, }, }, Apr 15 22:41:49 varnishd[11662]: Child cleanup complete Apr 15 22:41:49 varnishd[11662]: child (20389) Started Apr 15 22:41:49 varnishd[11662]: Child (20389) said Closed fds: 4 5 6 9 10 12 13 Apr 15 22:41:49 varnishd[11662]: Child (20389) said Child starts Apr 15 22:41:49 varnishd[11662]: Child (20389) said managed to mmap 1073741824 bytes of 1073741824 Apr 15 22:41:49 varnishd[11662]: Child (20389) said Ready }}} This was previously also observed at the following times: {{{ * r3965 Mar 10 06:21:27 Mar 18 10:37:45 Mar 28 07:59:44 Mar 28 11:52:40 Mar 30 16:41:45 Apr 1 11:41:25 Apr 6 09:47:34 Apr 6 15:29:26 Apr 6 21:10:02 Apr 7 10:50:43 Apr 7 22:05:46 Apr 9 06:56:42 Apr 9 13:16:57 Apr 9 19:53:26 * update to r4033 Apr 15 22:41:49 }}} Varnish is serving a plone website using pound for loadbalancing. The website serves up to 80,000 GET-requests per hour. Varnish is running on a dual-quad-core machine using Intel E5420 processors @2.5 GHz with 16 GB RAM, where varnish has a 1 GB cache. If you need further specifics to debug the problem, I will gladly provide them. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 10:30:00 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 10:30:00 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.3fd93750935747125d466dcc3ab7cd96@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I have added a couple of asserts to try to catch this earlier, please try r4055 or later if possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 10:30:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 10:30:58 -0000 Subject: [Varnish] #491: Crash in 2.0.4 In-Reply-To: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> References: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> Message-ID: <058.799309cdfe6208937b40b6020dab87ed@projects.linpro.no> #491: Crash in 2.0.4 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): any stack trace on this one ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 14:50:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 14:50:38 -0000 Subject: [Varnish] #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 In-Reply-To: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> References: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> Message-ID: <061.adad88c13cad8a27c28e5afcffa46aa8@projects.linpro.no> #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Increasing sess_workspace from the default 16K to 32K og 64K seems to have no effect. Increasing obj_workspace from my current level of 2K to 4K does not help either. Lastly, I tried to start the latest trunk 4055 with 64K sess_workspace and 4K obj_workspace. It still crashes: {{{ Child (7082) died signal=6 (core dumped) Child (7082) Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159: Condition(ws->f + b2 <= ws->e) not true. thread = (cache-worker)sp = 0x81599b008 { fd = 2717, id = 2717, xid = 1654697922, client = 85.19.68.43:2099, step = STP_FETCH, handling = fetch, err_code = 200, err_reason = (null), ws = 0x81599b070 { id = "sess", {s,f,r,e} = {0x81599b800,+996,0x0,+65536}, }, worker = 0x7fffeef782c0 { }, vcl = { srcname = { "input", "Default", }, }, }, }}} How can we proceed with fixing this? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 9 18:39:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 09 May 2009 18:39:53 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.f14db1bb4c4e9050a0100e676063ee67@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition ----------------------+----------------------------------------------------- Reporter: cra | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by joel): was having the same problem (as much as 50% 503 errors on stress tests) but the above patches seem to have eliminated the problem (0% on same tests) thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 11 08:52:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 May 2009 08:52:27 -0000 Subject: [Varnish] #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). In-Reply-To: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> References: <054.609377173b75897a6f3bdc0d306a73a4@projects.linpro.no> Message-ID: <063.216f46b15670804b8081c86464effbfb@projects.linpro.no> #508: Varnish 2.0.4 started crashing more often under load. Assert error in VRT_r_req_backend_healthy(). ----------------------+----------------------------------------------------- Reporter: nicholas | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by jo): Commenting out two if-checks using "req.backend.healthy" (one in vcl_recv and one in vcl_deliver) removed the crashes. I've attached our current vcl (with the two checks commented out). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 11 10:59:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 11 May 2009 10:59:24 -0000 Subject: [Varnish] #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 In-Reply-To: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> References: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> Message-ID: <061.9dfae88a56bbd25b50bcf5d844026715@projects.linpro.no> #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4075]) We need to reset the worker threads workspace between requests if we short-cut through STP_AGAIN. Expected to fix #487 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 12 08:16:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 12 May 2009 08:16:38 -0000 Subject: [Varnish] #507: Segfaults with SVN 4051M In-Reply-To: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> References: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> Message-ID: <062.12ac796c09ba544756586dc22f3eec18@projects.linpro.no> #507: Segfaults with SVN 4051M ----------------------+----------------------------------------------------- Reporter: victori | 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: Any chance you get get us a backtrace from the core dump ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 12 08:29:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 12 May 2009 08:29:51 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.443d2bac30040acc584896a025024f35@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): Replying to [comment:3 phk]: Can you tell me how to go it? strace? However it works, it must be doable on a production server (performance penalties aren't a problem, but it will be restarted automatically within a minute if it crashes). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 13 14:44:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 May 2009 14:44:19 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.3d106187e9b41add7e16bca1e648521e@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): In response to phk's update in r4055, I installed the latest version in the environment causing the issues. I received the following output from start to next crash: {{{ start child (20479) Started 200 0 Child (20479) said Closed fds: 4 5 7 10 11 13 14 Child (20479) said Child starts Child (20479) said managed to mmap 1073741824 bytes of 1073741824 Child (20479) said Ready Child (20479) died signal=6 Child (20479) Panic message: Assert error in BAN_CheckObject(), cache_ban.c line 423: Condition((o->ban) != NULL) not true. thread = (cache-worker) Backtrace: 0x42641f: pan_ic+132 0x411675: BAN_CheckObject+127 0x41f46e: HSH_Lookup+65a 0x414874: cnt_lookup+17b 0x41609a: CNT_Session+4e2 0x4280e3: wrk_do_cnt_sess+12a 0x427979: wrk_thread_real+5cd 0x427d67: wrk_thread+a0 sp = 0x2aab2182a008 { fd = 30, id = 30, xid = 569023539, client = 127.0.0.1:56258, step = STP_LOOKUP, handling = hash, restarts = 0, esis = 0 ws = 0x2aab2182a078 { id = "sess", {s,f,r,e} = {0x2aab2182a808,+317,(nil),+16384}, }, http[req] = { ws = 0x2aab2182a078[sess] "GET", "/VirtualHostBase/http///VirtualHostRoot//", "HTTP/1.0", "X-Enable-SSI: True", "X-Hosting: ", "X-Real-IP: ", "X-Forwarded-For: ", "Host: ", "Connection: close", "Cache-Control: no-cache", "User-Agent: ApacheBench/2.0.40-dev", "Accept: */*", }, worker = 0x49811420 { ws = 0x49811910 { id = "wrk", {s,f,r,e} = {0x4980b3a0,0x4980b3a0,(nil),+16384}, }, }, vcl = { srcname = { "input", "Default", }, }, }, }}} Unfortunately, no core dump was created because I made a mistake with ulimit -c. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 13 14:45:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 13 May 2009 14:45:25 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.91412c5080400c3e3ae9ce4d9b1eb8db@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): Replying to [comment:6 waschtl]: I will run varnish again with the proper settings and supply a core dump later. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu May 14 08:12:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 May 2009 08:12:27 -0000 Subject: [Varnish] #509: configure: WARNING: sys/mount.h: present but cannot be compiled Message-ID: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> #509: configure: WARNING: sys/mount.h: present but cannot be compiled -----------------+---------------------------------------------------------- Reporter: aj | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | -----------------+---------------------------------------------------------- Got this error compiling Varnish 2.0.4 from FreeBSD ports. The ports tree was up to date. Full build log and mount.h attached, but this is the relevant bit: {{{ checking sys/mount.h usability... no checking sys/mount.h presence... yes configure: WARNING: sys/mount.h: present but cannot be compiled configure: WARNING: sys/mount.h: check for missing prerequisite headers? configure: WARNING: sys/mount.h: see the Autoconf documentation configure: WARNING: sys/mount.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mount.h: proceeding with the preprocessor's result configure: WARNING: sys/mount.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to varnish-dev at projects.linpro.no ## configure: WARNING: ## --------------------------------------------- ## }}} FreeBSD xxx 6.3-RELEASE-p7 FreeBSD 6.3-RELEASE-p7 #0: Sun Dec 21 03:58:13 UTC 2008 root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/SMP i386 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu May 14 08:47:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 May 2009 08:47:45 -0000 Subject: [Varnish] #509: configure: WARNING: sys/mount.h: present but cannot be compiled In-Reply-To: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> References: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> Message-ID: <057.60e83efaecc8c897fe571c6c1c6e19e8@projects.linpro.no> #509: configure: WARNING: sys/mount.h: present but cannot be compiled --------------------+------------------------------------------------------- Reporter: aj | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Old description: > Got this error compiling Varnish 2.0.4 from FreeBSD ports. The ports tree > was up to date. Full build log and mount.h attached, but this is the > relevant bit: > > {{{ > checking sys/mount.h usability... no > checking sys/mount.h presence... yes > configure: WARNING: sys/mount.h: present but cannot be compiled > configure: WARNING: sys/mount.h: check for missing prerequisite > headers? > configure: WARNING: sys/mount.h: see the Autoconf documentation > configure: WARNING: sys/mount.h: section "Present But Cannot Be > Compiled" > configure: WARNING: sys/mount.h: proceeding with the preprocessor's > result > configure: WARNING: sys/mount.h: in the future, the compiler will take > precedence > configure: WARNING: ## --------------------------------------------- > ## > configure: WARNING: ## Report this to varnish-dev at projects.linpro.no > ## > configure: WARNING: ## --------------------------------------------- > ## > }}} > > FreeBSD xxx 6.3-RELEASE-p7 FreeBSD > 6.3-RELEASE-p7 #0: Sun Dec 21 03:58:13 UTC 2008 > root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/SMP i386 New description: Got this error compiling Varnish 2.0.4 from FreeBSD ports. The ports tree was up to date. Full build log and mount.h attached, but this is the relevant bit: {{{ checking sys/mount.h usability... no checking sys/mount.h presence... yes configure: WARNING: sys/mount.h: present but cannot be compiled configure: WARNING: sys/mount.h: check for missing prerequisite headers? configure: WARNING: sys/mount.h: see the Autoconf documentation configure: WARNING: sys/mount.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mount.h: proceeding with the preprocessor's result configure: WARNING: sys/mount.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to varnish-dev at projects.linpro.no ## configure: WARNING: ## --------------------------------------------- ## }}} FreeBSD xxx 6.3-RELEASE-p7 FreeBSD 6.3-RELEASE-p7 #0: Sun Dec 21 03:58:13 UTC 2008 root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/SMP i386 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu May 14 09:29:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 May 2009 09:29:25 -0000 Subject: [Varnish] #509: configure: WARNING: sys/mount.h: present but cannot be compiled In-Reply-To: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> References: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> Message-ID: <057.d21dc156e88a337cf6befdc573ecf388@projects.linpro.no> #509: configure: WARNING: sys/mount.h: present but cannot be compiled --------------------+------------------------------------------------------- Reporter: aj | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by aj): Appears a fix has already made it in: http://projects.linpro.no/pipermail/varnish-dev/2009-April/001042.html I guess this will be in 2.0.5? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu May 14 22:32:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 14 May 2009 22:32:42 -0000 Subject: [Varnish] #449: Crash in cache_ws.c with Varnish 2.0.3 In-Reply-To: <052.22242a63723f99d4f3e13e394d7f20f2@projects.linpro.no> References: <052.22242a63723f99d4f3e13e394d7f20f2@projects.linpro.no> Message-ID: <061.859e4111bd70a1efca41b254f5f7d9f0@projects.linpro.no> #449: Crash in cache_ws.c with Varnish 2.0.3 ----------------------+----------------------------------------------------- Reporter: stonor | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by cloudep): I am also seeing crash every couple of days. CentOS 5 - 64bit May 14 13:36:17 varnish01 varnishd[10887]: Child (5958) died signal=6 May 14 13:36:17 varnish01 varnishd[10887]: Child (5958) Panic message: Assert error in WS_Reserve(), cache_ws.c line 156: Condition(ws->r == NULL) not true. thread = (cache-worker)sp = 0x2aacb27d0008 { fd = 90, id = 90, xid = 1343804065, client = 10.0.0.1:51302, step = STP_HIT, handling = error, ws = 0x2aacb27d0078 { id = "sess", {s,f,r,e} = {0x2aacb27d0808,,+380,(nil),+16384}, }, worker = 0x7c280be0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x2aaba1cfa000 { refcnt = 2, xid = 1333269650, ws = 0x2aaba1cfa028 { id = "obj", {s,f,r,e} = {0x2aaba1cfa358,,+3235,(nil),+3240}, }, http = { ws = 0x2aaba1cfa028 { id = "obj", {s,f,r,e} = {0x2aaba1cfa358,,+3235,(nil),+3240}, }, hd = { "Server: Resin/3.0.23", "Content-Type: text/plain; charset=UTF-8", "Date: Mon, 11 May 2009 13:42:25 GMT", "Content-Length: 6181", "X-Cache: HIT", "X- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 18 11:57:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 18 May 2009 11:57:19 -0000 Subject: [Varnish] #510: Age of objects with 2 varnishes in front of each other Message-ID: <054.3b06386eb2eccf58118d145bfed9f2e1@projects.linpro.no> #510: Age of objects with 2 varnishes in front of each other ----------------------+----------------------------------------------------- Reporter: nicholas | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- We have a setup with 2 varnishes in front of each other, "front" and "back". We want to cache an object for 180s and set: obj.ttl = 180s; set obj.http.cache-control = "s-maxage=180"; in the back varnish. The front varnish starts counting Age at 0 and keeps the object 180s. By comparing objectid's we see that we are getting front 180s + back (0 to 180s) cache times. In the source code of varnishd.c for 2.0.4 we see ... if (age > max_age) ttl = 0; else ttl = max_age - age; But we suspect that $age here is not valid, or ttl would have decreased accordingly. Bug? # varnishd -V varnishd (varnish-2.0.4) # rpm -qa | grep varnish varnish-libs-devel-2.0.4-1.el5 varnish-2.0.4-1.el5 varnish-debuginfo-2.0.4-1.el5 varnish-libs-2.0.4-1.el5 # cat /etc/issue Red Hat Enterprise Linux Server release 5.2 (Tikanga) x86_64 system. Poke me for more details, steps to reproduce or testing. :-) -nicholas -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 20 10:47:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 20 May 2009 10:47:14 -0000 Subject: [Varnish] #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance In-Reply-To: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> References: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> Message-ID: <062.555716326cec8665dc4870503d7cabc0@projects.linpro.no> #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance ---------------------------------------------------------------------------------+ Reporter: stockrt | Owner: phk Type: enhancement | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: cache_acceptor_epoll.c cache_waiter_epoll.c performance linux epoll | ---------------------------------------------------------------------------------+ Changes (by phk): * status: new => closed * resolution: => fixed Comment: I have cleaned up a couple of long lines and committed the patch. Sorry for taking so long, but I wanted to give some hi-perf sites a chance to test it out first. Thanks for the patch! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 20 19:20:47 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 20 May 2009 19:20:47 -0000 Subject: [Varnish] #507: Segfaults with SVN 4051M In-Reply-To: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> References: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> Message-ID: <062.c2468731c2bebce57b3df8ec617c3553@projects.linpro.no> #507: Segfaults with SVN 4051M ----------------------+----------------------------------------------------- Reporter: victori | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by victori): Seems the issue has gone away in r4085. If it persists to crash I will append a backtrace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri May 22 07:59:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 May 2009 07:59:57 -0000 Subject: [Varnish] #511: Repeating segfault Message-ID: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> #511: Repeating segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- After 30 days of runtime one varnish started restarting itself and getting cought in Panic message: Assert error in Lck__Lock(), cache_lck.c line 81: Condition(r == 0 || errno == EBUSY) not true. thread = (cache-worker)sp = 0x7f0275038008 { fd = 464, id = 464, xid = 1369256881, client = xx.xx.xx.xx:52301, step = STP_ERROR, handling = fetch, err_code = 503, err_reason = (null), ws = 0x7f0275038078 { id = "sess", {s,f,r,e} = {0x7f0275038808,,+653,(nil),+32768}, }, worker = 0x7f01c6ff7be0 { }, vcl = { srcname = { "input", "Default", }, }, }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri May 22 11:57:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 May 2009 11:57:44 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.10ab9157f62c26078b7ede679fb87b20@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): waschtl replying to [comment:7 waschtl]: So, now here is the panic message, the backtrace, and relevant information based on the document of Debugging Varnish. I am supplying a lot of information here. I hope all the necessary information is in there, and if it's too much information -- I apologize. Panic Message: {{{ child (18618) Started Child (18618) said Closed fds: 4 5 7 10 11 13 14 Child (18618) said Child starts Child (18618) said managed to mmap 1073741824 bytes of 1073741824 Child (18618) said Ready Child (18618) not responding to ping, killing it. Child (18618) not responding to ping, killing it. Child (18618) not responding to ping, killing it. Child (18618) not responding to ping, killing it. Child (18618) not responding to ping, killing it. Child (18618) not responding to ping, killing it. Child (18618) died signal=6 (core dumped) Child (18618) Panic message: Assert error in BAN_CheckObject(), cache_ban.c line 423: Condition((o->ban) != NULL) not true. thread = (cache-worker) Backtrace: 0x42641f: pan_ic+132 0x411675: BAN_CheckObject+127 0x41f46e: HSH_Lookup+65a 0x414874: cnt_lookup+17b 0x41609a: CNT_Session+4e2 0x4280e3: wrk_do_cnt_sess+12a 0x427979: wrk_thread_real+5cd 0x427d67: wrk_thread+a0 sp = 0x2aab13a25008 { fd = 34, id = 34, xid = 342003300, client = 127.0.0.1:35706, step = STP_LOOKUP, handling = hash, restarts = 1, esis = 0 ws = 0x2aab13a25078 { id = "sess", {s,f,r,e} = {0x2aab13a25808,+317,(nil),+16384}, }, http[req] = { ws = 0x2aab13a25078[sess] "GET", "/VirtualHostBase/http/www.xxxx.de/xxxx/VirtualHostRoot//", "HTTP/1.0", "X-Enable-SSI: True", "X-Hosting: www.xxxx.de", "X-Real-IP: x.x.x.x", "X-Forwarded-For: x.x.x.x", "Host: www.xxxx.de", "Connection: close", "Cache-Control: no-cache", "User-Agent: ApacheBench/2.0.40-dev", "Accept: */*", }, worker = 0x49010420 { ws = 0x49010910 { id = "wrk", {s,f,r,e} = {0x4900a3a0,0x4900a3a0,(nil),+16384}, }, }, vcl = { srcname = { "input", "Default", }, }, }, }}} GDB Output: {{{ (gdb) bt #0 0x00002b6ec9fad095 in raise () from /lib/libc.so.6 #1 0x00002b6ec9faeaf0 in abort () from /lib/libc.so.6 #2 0x00000000004264f8 in pan_ic (func=0x454200 "BAN_CheckObject", file=0x453eb9 "cache_ban.c", line=423, cond=0x4541b1 "(o->ban) != NULL", err=0, xxx=0) at cache_panic.c:356 #3 0x0000000000411675 in BAN_CheckObject (o=0x2aaaac3d9000, sp=0x2aab13a25008) at cache_ban.c:423 #4 0x000000000041f46e in HSH_Lookup (sp=0x2aab13a25008, poh=0x4900a2f0) at cache_hash.c:472 #5 0x0000000000414874 in cnt_lookup (sp=0x2aab13a25008) at cache_center.c:740 #6 0x000000000041609a in CNT_Session (sp=0x2aab13a25008) at steps.h:38 #7 0x00000000004280e3 in wrk_do_cnt_sess (w=0x49010420, priv=0x2aab13a25008) at cache_pool.c:456 #8 0x0000000000427979 in wrk_thread_real (qp=0x2b6ec8f0c150, shm_workspace=8192, sess_workspace=16384) at cache_pool.c:351 #9 0x0000000000427d67 in wrk_thread (priv=0x2b6ec8f0c150) at cache_pool.c:387 #10 0x00002b6ec98ca3f7 in start_thread () from /lib/libpthread.so.0 #11 0x00002b6eca052b3d in clone () from /lib/libc.so.6 #12 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x0000000000411675 in BAN_CheckObject (o=0x2aaaac3d9000, sp=0x2aab13a25008) at cache_ban.c:423 423 in cache_ban.c (gdb) print o $3 = (struct object *) 0x2aaaac3d9000 (gdb) print *o Cannot access memory at address 0x2aaaac3d9000 (gdb) print sp $4 = (const struct sess *) 0x2aab13a25008 (gdb) print *sp $5 = {magic = 741317722, fd = 34, id = 34, xid = 342003300, restarts = 1, esis = 0, disable_esi = 0, wrk = 0x49010420, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x2aab13a25708, mysockaddr = 0x2aab13a25788, mylsock = 0x2b6ec8f19ee0, addr = 0x2aab13a25808 "127.0.0.1", port = 0x2aab13a25812 "35706", doclose = 0x456e4d "Connection: close", http = 0x2aab13a25250, http0 = 0x2aab13a254a0, ws = {{magic = 905626964, id = 0x4583d3 "sess", s = 0x2aab13a25808 "127.0.0.1", f = 0x2aab13a25945 "", r = 0x0, e = 0x2aab13a29808 "", overflow = 0}}, ws_ses = 0x2aab13a25818 "GET", ws_req = 0x2aab13a25945 "", htc = {{magic = 1041886673, fd = 34, ws = 0x2aab13a25078, rxbuf = {b = 0x2aab13a25818 "GET", e = 0x2aab13a25945 ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1242418936.7020173, t_req = 1242418936.7020481, t_resp = nan(0x8000000000000), t_end = nan(0x8000000000000), connect_timeout = 0.40000000000000002, first_byte_timeout = 60, between_bytes_timeout = 60, grace = 30, step = STP_LOOKUP, cur_method = 0, handling = 2, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {vtqe_next = 0x2aab124f1008, vtqe_prev = 0x2aab7e1df850}, director = 0x2b6ec8f0c298, vbe = 0x0, obj = 0x0, objcore = 0x0, objhead = 0x0, vcl = 0x2b6ec8f02428, mem = 0x2aab13a25000, workreq = {list = {vtqe_next = 0x2aaaeb4e7198, vtqe_prev = 0x2b6ec8f0c1c0}, func = 0x427fb9 , priv = 0x2aab13a25008}, acct = { first = 1242418936.7020173, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, nhashptr = 0, ihashptr = 0, lhashptr = 0, hashptr = 0x0} }}} Further information consolidated (given here and there elsewhere): * Version: r4076[[BR]] * Architecture: x86_64 (amd64 on Intel)[[BR]] * Mode: 64-bit[[BR]] * RAM: 16 GB, varnish uses 1 GB[[BR]] * OS/Kernel: ubuntu 8.04 (hardy) / linux-2.6.22.10-vs2.2.0.4 (with linux- vserver-patch)[[BR]] * VCL: see below[[BR]] vcl.conf: {{{ acl purge { "localhost"; "127.0.0.1"; "x.x.x.x"/26; } backend default { /* backend = pound */ .host = "127.0.0.1"; .port = "8001"; } sub vcl_recv { if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "PURGE" && req.request != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ pipe; } if (req.request == "POST") { pipe; } # purge if someone hits shift-reload. This ONLY WORKS IF THE URL does not look like a regexp (i.e. with a "+" in it!) # for such urls see the workaround in vcl_hit. if (req.http.Cache-Control ~ "no-cache") { purge_url(req.url); } if (req.request != "GET" && req.request != "HEAD") { # PURGE request if zope asks nicely if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } lookup; } pass; } if (req.http.Expect) { pipe; } /* Don't use the cache for /community. */ if (req.url ~ "/communityfotos") { set req.grace = 30s; lookup; } /* Don't use the cache for /community. */ if (req.url ~ "/community/") { pass; } /* Always cache images, css and js */ if (req.url ~ "\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|css|js|vsd|doc|ppt|pps|xls|pdf|mp3|mp4|m4a|ogg|mov|avi|wmv|sxw|zip|gz|bz2|tgz|tar|rar|odc|odb|odf|odg|odi|odp|ods|odt|sxc|sxd|sxi|sxw|dmg|torrent|deb|msi|iso|rpm)$") { set req.grace = 30s; lookup; } # We only care about the "__ac.*" cookies, used for authentication and special persistent p_* cookies. if (req.http.Cookie && ( req.http.Cookie ~ "__ac|(_(name|password|persistent))=" || req.http.Cookie ~ "p_[^=]+=" || req.http.Cookie ~ "captchasessionid=" )) { pass; } # throw away cookies all other and lookup set req.grace = 30s; remove req.http.cookie; lookup; } sub vcl_pipe { pipe; } sub vcl_pass { pass; } sub vcl_hash { set req.hash += req.url; if (req.http.host) { set req.hash += req.http.host; } else { set req.hash += server.ip; } hash; } sub vcl_hit { # this should all work in vcl_recv, but it doesn't for urls with a "+" in it, i.e. # urls that look like regular expressions. So we workaround here. # THIS ONLY WORK IN VARNISH 2.0.3 OR GREATER (or trunk)!!! if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } if (req.http.Cache-Control ~ "no-cache") { set obj.ttl = 0s; restart; } if (!obj.cacheable) { pass; } deliver; } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } fetch; } sub vcl_fetch { set beresp.grace = 30s; if (beresp.ttl < 300s) { set beresp.ttl = 300s; } if (beresp.http.Set-Cookie) { pass; } if (req.url ~ "(/rss|search_rss)") { set beresp.ttl = 1800s; } /* Always cache images, css and js for at least 24 hours */ if (req.url ~ "\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|css|js|vsd|doc|ppt|pps|xls|pdf|mp3|mp4|m4a|ogg|mov|avi|wmv|sxw|zip|gz|bz2|tgz|tar|rar|odc|odb|odf|odg|odi|odp|ods|odt|sxc|sxd|sxi|sxw|dmg|torrent|deb|msi|iso|rpm)$") { set beresp.ttl = 86400s; } #set beresp.prefetch = -30s; deliver; } sub vcl_deliver { deliver; } sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" "} obj.status " " obj.response {"

Fehler

Beim Zugriff auf http://www.freitag.de ist es aufgrund von Wartungsarbeiten zu einer Zeit?berschreitung gekommen.
Bitte rufen Sie die Seite erneut auf oder probieren es in ein paar Minuten wieder.

"}; deliver; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri May 22 20:29:45 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 22 May 2009 20:29:45 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.e7f53a986fedd75fa83bf823d2acc555@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I have a hard time figuring out how this happens. I have spotted one way one could conceiveably get into that situation, but I have not been able to see how your VCL would be able to get you there. r4087 closes that possibility, and even though I do not expect it to make a difference, I would appreciate if you could give that a whirl. The other question I have relates to the later of your two dumps above: The dump shows "restarts = 1", indicating that the "no-cache" check in vcl_hit was encountered. Can you confirm, that the URL string does not contain any characters which would confuse the purge_url() attempt in vcl_recv{} ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 25 08:08:37 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 May 2009 08:08:37 -0000 Subject: [Varnish] #511: Repeating segfault In-Reply-To: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> References: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> Message-ID: <058.36a0c70c44d3ca6d9dfd49673c47d93c@projects.linpro.no> #511: Repeating segfault --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Old description: > After 30 days of runtime one varnish started restarting itself and > getting cought in > > Panic message: Assert error in Lck__Lock(), cache_lck.c line 81: > Condition(r == 0 || errno == EBUSY) not true. thread = (cache-worker)sp > = 0x7f0275038008 { fd = 464, id = 464, xid = 1369256881, client = > xx.xx.xx.xx:52301, step = STP_ERROR, handling = fetch, err_code = > 503, err_reason = (null), ws = 0x7f0275038078 { id = "sess", > {s,f,r,e} = {0x7f0275038808,,+653,(nil),+32768}, }, worker = > 0x7f01c6ff7be0 { }, vcl = { srcname = { "input", > "Default", }, }, }, New description: After 30 days of runtime one varnish started restarting itself and getting cought in {{{ Panic message: Assert error in Lck__Lock(), cache_lck.c line 81: Condition(r == 0 || errno == EBUSY) not true. thread = (cache-worker)sp = 0x7f0275038008 { fd = 464, id = 464, xid = 1369256881, client = xx.xx.xx.xx:52301, step = STP_ERROR, handling = fetch, err_code = 503, err_reason = (null), ws = 0x7f0275038078 { id = "sess", {s,f,r,e} = {0x7f0275038808,,+653,(nil),+32768}, }, worker = 0x7f01c6ff7be0 { }, vcl = { srcname = { "input", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 25 08:09:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 May 2009 08:09:42 -0000 Subject: [Varnish] #511: Repeating segfault In-Reply-To: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> References: <049.27f2235b5b0f4e5a0c8bec8d6ea0e9e6@projects.linpro.no> Message-ID: <058.c787c43d94046889ff3ee4820352a73a@projects.linpro.no> #511: Repeating segfault ----------------------+----------------------------------------------------- Reporter: sky | 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: This one is pretty impossible to do anything about without a backtrace... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 25 08:10:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 May 2009 08:10:50 -0000 Subject: [Varnish] #507: Segfaults with SVN 4051M In-Reply-To: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> References: <053.f212d951a84b8e3cbdffbaa6fc770341@projects.linpro.no> Message-ID: <062.08e845f54ffcb5ec21555c39023c1055@projects.linpro.no> #507: Segfaults with SVN 4051M ----------------------+----------------------------------------------------- Reporter: victori | 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 Old description: > The last stable build that was useable on Solaris was r4043. Whatever was > modified past r4043 has been completely unstable on solaris. It stays up > 30-45 minutes at a time before segfaulting. > > May 5 09:44:27 Executing start method ("newtask -p highfile > /opt/extra/sbin/varnishd -f /opt/extra/etc/varnish/default.vcl -a > 72.11.142.91:80 -p listen_depth=4096 -p thread_pool_max=4000 -p > thread_pool_min=8 -s malloc,256m -p sess_timeout=10 -p max_restarts=12 -p > connect_timeout=1s -p cli_timeout=10 -p client_http11=on -p > obj_workspace=65536 -p sess_workspace=131072 -p thread_pools=4 -T > 127.0.0.1:8086 -u webservd -F &"). ] > storage_malloc: max size 256 MB. > Using old SHMFILE > child (18165) Started > Child (18165) said Closed fds: 3 4 5 8 9 11 12 > Child (18165) said Child starts > Child (18165) said Ready > [ May 5 09:44:27 Stopping because process dumped core. ] > [ May 5 09:44:27 Executing stop method (:kill). ] > Manager got SIGINT > Stopping Child New description: The last stable build that was useable on Solaris was r4043. Whatever was modified past r4043 has been completely unstable on solaris. It stays up 30-45 minutes at a time before segfaulting. {{{ May 5 09:44:27 Executing start method ("newtask -p highfile /opt/extra/sbin/varnishd -f /opt/extra/etc/varnish/default.vcl -a 72.11.142.91:80 -p listen_depth=4096 -p thread_pool_max=4000 -p thread_pool_min=8 -s malloc,256m -p sess_timeout=10 -p max_restarts=12 -p connect_timeout=1s -p cli_timeout=10 -p client_http11=on -p obj_workspace=65536 -p sess_workspace=131072 -p thread_pools=4 -T 127.0.0.1:8086 -u webservd -F &"). ] storage_malloc: max size 256 MB. Using old SHMFILE child (18165) Started Child (18165) said Closed fds: 3 4 5 8 9 11 12 Child (18165) said Child starts Child (18165) said Ready [ May 5 09:44:27 Stopping because process dumped core. ] [ May 5 09:44:27 Executing stop method (:kill). ] Manager got SIGINT Stopping Child }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon May 25 08:12:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 25 May 2009 08:12:56 -0000 Subject: [Varnish] #509: configure: WARNING: sys/mount.h: present but cannot be compiled In-Reply-To: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> References: <048.50cb089f75bdc09c14b11d89f30e1301@projects.linpro.no> Message-ID: <057.f0ae10791ced449889cca002c7cbb1d4@projects.linpro.no> #509: configure: WARNING: sys/mount.h: present but cannot be compiled --------------------+------------------------------------------------------- Reporter: aj | 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: Already fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 26 07:57:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 26 May 2009 07:57:54 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() In-Reply-To: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> References: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> Message-ID: <062.321ccb84b84a66e313c4fb73c79133d0@projects.linpro.no> #489: Assert error in BAN_CheckObject() ----------------------+----------------------------------------------------- Reporter: waschtl | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by waschtl): OK. I'm giving r4087 a whirl - I installed it yesterday. As to your question: The URL-string that was called when the crash occurred (/VirtualHostBase/http/www.xxxx.de/xxxx/VirtualHostRoot//) contains only lower-case letters [a-z]. But, other URL-strings contain plusses and percent-signs. The following for example (bogus hides alphabetic characters of the same case): {{{ GET /bogus_kss/Bogus%20Theme/++resource++bogus.cms.kss }}} This is the reason vcl_hit exists in addition to vcl_recv. Does this answer your question, or did I miss something? Now, it just remains to wait for another crash. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue May 26 16:28:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 26 May 2009 16:28:58 -0000 Subject: [Varnish] #512: 503 error with load-balancer setup Message-ID: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> #512: 503 error with load-balancer setup ----------------------+----------------------------------------------------- Reporter: ajung | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: Loadbalancer ----------------------+----------------------------------------------------- Running Varnish 2.0.4 on latest Debian. I tried setting up Varnish as a load-balancer with the following configuration. Load-balancing works with both .probe options disabled. It also work with one .probe option enabled. Varnish fails (replies with a 503 error) as soon as both backend are configured for probing. In fact the probing is working (I can see the requests on the backends (returning with status 200). So what's the heck here? backend labor1 { .host = "diaweb07"; .port = "11001"; # .probe = { # .url = "/"; # .interval = 5s; # .timeout = 1 s; # .window = 5; # .threshold = 3; # } } backend labor2 { .host = "diaweb07"; .port = "11002"; # .probe = { # .url = "/"; # .interval = 5s; # .timeout = 1 s; # .window = 5; # .threshold = 3; # } } director laborbalancer round-robin { { .backend = labor1; } { .backend = labor2; } } acl purge { "172.25.4.232"; } sub vcl_recv { set req.backend = laborbalancer; -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 27 07:39:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 27 May 2009 07:39:31 -0000 Subject: [Varnish] #512: 503 error with load-balancer setup In-Reply-To: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> References: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> Message-ID: <060.050f4cae960e5265965cc56f6e6c89da@projects.linpro.no> #512: 503 error with load-balancer setup --------------------------+------------------------------------------------- Reporter: ajung | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: Loadbalancer | --------------------------+------------------------------------------------- Comment (by whocares): The problem could be that you simply didn't wait long enough. In your configuration, Varnish would at least need 15 seconds (3 good replies with a wait time of 5 seconds between each try) before actually processing client requests. In the meantime it will reply with 503 "Service Unavailable" because that's exactly what Varnish thinks is the case. As soon as you disable one of the .probe configs, Varnish will see the node with the probes disabled as immediately available and start serving requests from there until the second backend is successfully checked and also used in the loadbalancing setup. That's why it works for you when just checking one backend system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 27 07:46:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 27 May 2009 07:46:08 -0000 Subject: [Varnish] #512: 503 error with load-balancer setup In-Reply-To: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> References: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> Message-ID: <060.6376c1ad7800ff3f7eadbe201882428f@projects.linpro.no> #512: 503 error with load-balancer setup --------------------------+------------------------------------------------- Reporter: ajung | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: Loadbalancer | --------------------------+------------------------------------------------- Comment (by whocares): As an afterthought, I'd say that it's not exactly wise to have Varnish start up with all backend systems marked as "sick". Imho, it would be better to initially start out with a status of "healthy" unless proven otherwise by the probe requests. This would eliminate the somewhat lengthy delay until Varnish starts serving requests after being (re-)started in a loadbalancing setup. Or, well, make it a startup option and let the admin decide ;) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed May 27 23:55:33 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 27 May 2009 23:55:33 -0000 Subject: [Varnish] #512: 503 error with load-balancer setup In-Reply-To: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> References: <051.93b0fdd93e18ab1938af816defd3ca3b@projects.linpro.no> Message-ID: <060.8a373cec6b66ab031ff90d9a67ece3c4@projects.linpro.no> #512: 503 error with load-balancer setup --------------------------+------------------------------------------------- Reporter: ajung | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: Loadbalancer | --------------------------+------------------------------------------------- Comment (by kb): I agree, defaulting to healthy might cause some false-positives, but it seems by far the more common case for an accelerator to start (or especially in the crash/restart case) with healthy back-ends. Perhaps varnish shouldn't listen() until immediate initial probes are sent out and evaluated. The only side-effect would be a ~100ms one-time startup delay that's transparent to users. A load balancer's own health- checking would not pass the 503s back to users, but for those without LBs, direct to varnish would be a bad experience, IMHO. I'd be willing to code it if I could get some pointers in the right direction. Ken. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu May 28 00:45:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 28 May 2009 00:45:10 -0000 Subject: [Varnish] #513: Implement a VCL "constructor" Message-ID: <048.0ca14503bff93f739ffb0346b288b20f@projects.linpro.no> #513: Implement a VCL "constructor" -------------------------+-------------------------------------------------- Reporter: kb | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -------------------------+-------------------------------------------------- I'm building up Varnish to replace a Squid install, and I'm doing something along these lines inside vcl_recv(): {{{ C{ #include "regex.h" // (at top level, not here) regex_t *preg ; preg = calloc(N); regcomp( preg, "pattern", flags ); if ( regexec( preg, ... ) ) // do stuff regfree(preg); }C }}} However, this should perform much better: {{{ C{ #include "regex.h" regex_t *preg ; }C sub vcl_init { C{ preg = calloc(N); regcomp( preg, "pattern", flags ); }C } sub vcl_recv { C{ if ( regexec( preg, ... ) ) // do stuff }C } }}} This assumes that vcl_init() is an initializer that only runs once after the config is loaded, before threads are created. I implemented a "callonce" command that uses the POSIX pthread_once business: {{{ sub vcl_recv { callonce vcl_init ; C{ ... }C } }}} But properly tracking arbitrary once-called functions would be ugly. As is most of POSIX. This is why I thought a constructor or initializer that skips the complication of locks and pthread_once would be a nice addition for more efficient C integration. If there were a preferred way of implementing this, I'd love the feedback and pointers to do it in my off-time. Thx,[[br]] -- [[br]] Ken. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat May 30 01:07:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 30 May 2009 01:07:50 -0000 Subject: [Varnish] #514: varnishtop not printing values in once mode Message-ID: <051.8d7aaa65ab9b51b57f19db6c93f05345@projects.linpro.no> #514: varnishtop not printing values in once mode ------------------------+--------------------------------------------------- Reporter: ericp | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- When called with -1, varnishtop doesn't print the actual values from the log. For example: {{{ > varnishtop -i RxRequest -1 30.00 20.00 }}} It looks like a few magic constants were used in the dump() function and never replaced with proper constants. The attached patch fixes this, and will give the correct output: {{{ > varnishtop -i RxRequest -1 30.00 HEAD 20.00 GET }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator