From varnish-bugs at projects.linpro.no Fri Jan 5 01:19:51 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Jan 2007 01:19:51 -0000 Subject: [Varnish] #67: All varnish-child-processes dies In-Reply-To: <077.067db0f778d30e7d6a816827c924caee@projects.linpro.no> References: <077.067db0f778d30e7d6a816827c924caee@projects.linpro.no> Message-ID: <086.ea2180a88133c9ef055ff2476d97f3f2@projects.linpro.no> #67: All varnish-child-processes dies ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by sebastien.estienne at gmail.com): I can reproduce this behaviour by restarting the backend server while varnish is running: All the childs immediately die -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 15 11:02:00 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Jan 2007 11:02:00 -0000 Subject: [Varnish] #79: force nocache of objects Message-ID: <077.521b0effdab17234c6a562780350761e@projects.linpro.no> #79: force nocache of objects ----------------------+----------------------------------------------------- Reporter: hmn | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- What are the correct cache headers to set if I need to tell varnish not to cache a file. Right now I use : Pragma: no-cache Cache-Control: s-maxage=0, max-age=0, must-revalidate, no-cache But sometimes I get some other users cached file, and it seems to be when I try to get a file in the exact same moment as som eother user. In vcl i have the following code to allow caching af some of the files even though a user is logged in. # force lookup even when cookies are present if (req.request == "GET" && req.http.cookie) { lookup; } And when i request the file I get the following in varnishlog 15 VCL_call c recv 15 VCL_return c lookup 15 VCL_call c miss 15 VCL_return c fetch 16 RxHeader b Pragma: no-cache 16 RxHeader b Cache-Control: s-maxage=0, max-age=0, must- revalidate, no-cache 16 RxHeader b Expires: Fri, 05 Jan 2007 08:57:03 GMT 16 RxHeader b Content-Length: 1555 16 RxHeader b Connection: close 16 RxHeader b Content-Type: text/javascript 15 TTL c 277100755 RFC 0 1168592154 1168592223 1167987423 0 0 15 VCL_call c fetch 15 VCL_return c insert Could it be the insert that is made by varnish that is the problem ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Jan 19 15:29:54 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Jan 2007 15:29:54 -0000 Subject: [Varnish] #80: Missing errorhandler causes crash Message-ID: <077.e97396144de555b7e05f93bb17097cd6@projects.linpro.no> #80: Missing errorhandler causes crash --------------------+------------------------------------------------------- Reporter: xingli | Owner: des Type: defect | Status: new Priority: high | Milestone: Varnish 1.1 Component: build | Version: 1.0 Severity: major | Keywords: --------------------+------------------------------------------------------- Below is the varnish management log. There is 1 assert and at the end 1 missing error handler. Varnish was not able to recover from the error at the end. Platform: Centos 4.4 x64 version. Latest stable varnish. {{{ Child said (2, 3520): <> Child said (2, 3520): <> etChild said (2, 3520): <pipe)) == 0) not true. errno = 24 (Too many open files) >> Child not responding to ping Cache child died pid=3520 status=0x6 Clean child Child cleaned start child pid 18923 Pushing vcls failed: dlopen(/tmp/vcl.XXh9z1Wp): /tmp/vcl.XXh9z1Wp: cannot open shared object file: No such file or directory Child said (1, 18923): <> unlink /tmp/vcl.XXh9z1Wp Missing errorhandling code in mgt_vcc_del(), mgt_vcc.c line 129: Condition((unlink(vp->fname)) == 0) not true. errno = 2 (No such file or directory) k 1 rev 16 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 23 09:05:03 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Jan 2007 09:05:03 -0000 Subject: [Varnish] #80: Missing errorhandler causes crash In-Reply-To: <077.e97396144de555b7e05f93bb17097cd6@projects.linpro.no> References: <077.e97396144de555b7e05f93bb17097cd6@projects.linpro.no> Message-ID: <086.87465ab4dd099202fc3aeb4aba7c5dd0@projects.linpro.no> #80: Missing errorhandler causes crash --------------------+------------------------------------------------------- Reporter: xingli | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Varnish 1.1 Component: build | Version: 1.0 Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by des): * status: new => assigned Comment: I'm not sure a failure to unlink the VCL object should be considered an error at all. Try the attached patch as a workaround (apply with {{{patch -l}}}): {{{ === bin/varnishd/mgt_vcc.c ================================================================== --- bin/varnishd/mgt_vcc.c (revision 34134) +++ bin/varnishd/mgt_vcc.c (local) @@ -126,7 +126,7 @@ { TAILQ_REMOVE(&vclhead, vp, list); printf("unlink %s\n", vp->fname); - XXXAZ(unlink(vp->fname)); + unlink(vp->fname); free(vp->fname); free(vp->name); free(vp); }}} The interesting question, of course, is why the file is missing, and why you didn't get an error message when it failed to be created. We should also consider whether the initial error (Too many open files) can be handled more gracefully. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 23 09:06:11 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Jan 2007 09:06:11 -0000 Subject: [Varnish] #79: force nocache of objects In-Reply-To: <077.521b0effdab17234c6a562780350761e@projects.linpro.no> References: <077.521b0effdab17234c6a562780350761e@projects.linpro.no> Message-ID: <086.0cdac4dd926991c3eca616361d4e569a@projects.linpro.no> #79: force nocache of objects ----------------------+----------------------------------------------------- Reporter: hmn | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des Old description: > What are the correct cache headers to set if I need to tell varnish not > to cache a file. > > Right now I use : > > Pragma: no-cache > Cache-Control: s-maxage=0, max-age=0, must-revalidate, no-cache > > But sometimes I get some other users cached file, and it seems to be when > I try to get a file in the exact same moment as som eother user. > > In vcl i have the following code to allow caching af some of the files > even though a user is logged in. > > # force lookup even when cookies are present > if (req.request == "GET" && req.http.cookie) { > lookup; > } > > And when i request the file I get the following in varnishlog > > 15 VCL_call c recv > 15 VCL_return c lookup > 15 VCL_call c miss > 15 VCL_return c fetch > > 16 RxHeader b Pragma: no-cache > 16 RxHeader b Cache-Control: s-maxage=0, max-age=0, must- > revalidate, no-cache > 16 RxHeader b Expires: Fri, 05 Jan 2007 08:57:03 GMT > 16 RxHeader b Content-Length: 1555 > 16 RxHeader b Connection: close > 16 RxHeader b Content-Type: text/javascript > 15 TTL c 277100755 RFC 0 1168592154 1168592223 1167987423 0 0 > 15 VCL_call c fetch > 15 VCL_return c insert > > Could it be the insert that is made by varnish that is the problem ? New description: What are the correct cache headers to set if I need to tell varnish not to cache a file. Right now I use : {{{ Pragma: no-cache Cache-Control: s-maxage=0, max-age=0, must-revalidate, no-cache }}} But sometimes I get some other users cached file, and it seems to be when I try to get a file in the exact same moment as som eother user. In vcl i have the following code to allow caching af some of the files even though a user is logged in. {{{ # force lookup even when cookies are present if (req.request == "GET" && req.http.cookie) { lookup; } }}} And when i request the file I get the following in varnishlog {{{ 15 VCL_call c recv 15 VCL_return c lookup 15 VCL_call c miss 15 VCL_return c fetch 16 RxHeader b Pragma: no-cache 16 RxHeader b Cache-Control: s-maxage=0, max-age=0, must- revalidate, no-cache 16 RxHeader b Expires: Fri, 05 Jan 2007 08:57:03 GMT 16 RxHeader b Content-Length: 1555 16 RxHeader b Connection: close 16 RxHeader b Content-Type: text/javascript 15 TTL c 277100755 RFC 0 1168592154 1168592223 1167987423 0 0 15 VCL_call c fetch 15 VCL_return c insert }}} Could it be the insert that is made by varnish that is the problem ? Comment: Reformatted the original message. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 23 09:06:34 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Jan 2007 09:06:34 -0000 Subject: [Varnish] #78: URLS without trailing / direct to backend . In-Reply-To: <077.5efa7663912c67ccf38afa67fa7389d5@projects.linpro.no> References: <077.5efa7663912c67ccf38afa67fa7389d5@projects.linpro.no> Message-ID: <086.94dcc43fde4d46ade6809322ab25560b@projects.linpro.no> #78: URLS without trailing / direct to backend . ----------------------+----------------------------------------------------- Reporter: kevinm | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 23 09:07:37 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Jan 2007 09:07:37 -0000 Subject: [Varnish] #71: Missing errorhandling code in PassSession() In-Reply-To: <077.a4957bbf8e561e1f0af9d5640d5e1a0a@projects.linpro.no> References: <077.a4957bbf8e561e1f0af9d5640d5e1a0a@projects.linpro.no> Message-ID: <086.9870fb97d072957d2f745d9a522825d3@projects.linpro.no> #71: Missing errorhandling code in PassSession() ----------------------+----------------------------------------------------- Reporter: mark | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => closed * resolution: => duplicate -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 29 03:39:03 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Jan 2007 03:39:03 -0000 Subject: [Varnish] #42: Support gzip / deflate In-Reply-To: <077.078cea0d53d298cc5a4236cb85aa76c6@projects.linpro.no> References: <077.078cea0d53d298cc5a4236cb85aa76c6@projects.linpro.no> Message-ID: <086.ab27b5dbca1677d5f92e1c8af14de616@projects.linpro.no> #42: Support gzip / deflate -------------------------+-------------------------------------------------- Reporter: des | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by xing_litespeed): Just a note if/when this feature is on the fast track. When the backend returns a compressed format, it will most likely contain "chunked" transfer-encoding header and not contain a "length" header. If varnish decides to cache this, varnish should "clean-up" and remove the chunked header and calculate/insert length value. This would be the most correct way I think since any subsequent cache hits is sent in full and we already know the content-length. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 29 03:49:34 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Jan 2007 03:49:34 -0000 Subject: [Varnish] #80: Missing errorhandler causes crash In-Reply-To: <077.e97396144de555b7e05f93bb17097cd6@projects.linpro.no> References: <077.e97396144de555b7e05f93bb17097cd6@projects.linpro.no> Message-ID: <086.67e26d5f3fc3a8a825f91915235dcdb4@projects.linpro.no> #80: Missing errorhandler causes crash --------------------+------------------------------------------------------- Reporter: xingli | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Varnish 1.1 Component: build | Version: 1.0 Severity: major | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by xing_litespeed): Currently running the patched varnish. Thanks for the patch. Investigated the system and around the time those errors came up, I had some block errors on the scsi raid subsystem causing perhaps a few seconds of dead/blocked i/o. That's the best reason I can give for what caused it. Varnishd was all in ram with 0 swap used by the kernel so I think that's how it "lost" the file/link. The likelihood of it happening again is very slim. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 29 06:01:05 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Jan 2007 06:01:05 -0000 Subject: [Varnish] #81: Via: Varnish header duplicate Message-ID: <077.cfec158edcd74344396a44038c352bd8@projects.linpro.no> #81: Via: Varnish header duplicate ----------------------------+----------------------------------------------- Reporter: xing_litespeed | Owner: phk Type: enhancement | Status: new Priority: low | Milestone: Varnish 2.0 Component: varnishd | Version: 1.0 Severity: minor | Keywords: via header ----------------------------+----------------------------------------------- If the backend already sends back response with "Via: Varnish" header, it is probably not necessary to insert another one in there. It is not an error but not needed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 29 22:05:42 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Jan 2007 22:05:42 -0000 Subject: [Varnish] #82: varnishd -w argument parsing too forgiving Message-ID: <077.e322cf93beb0d568c8cca1f0b0ef66e7@projects.linpro.no> #82: varnishd -w argument parsing too forgiving ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- It is possible to specify -w 1,INF,15. Varnishd will stop at the 'I' and set both thread_pool.min and thread_pool.max to one without issuing a warning. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Jan 29 22:08:03 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Jan 2007 22:08:03 -0000 Subject: [Varnish] #82: varnishd -w argument parsing too forgiving In-Reply-To: <077.e322cf93beb0d568c8cca1f0b0ef66e7@projects.linpro.no> References: <077.e322cf93beb0d568c8cca1f0b0ef66e7@projects.linpro.no> Message-ID: <086.13a6d6cb255fb69711f97b6e6975da89@projects.linpro.no> #82: varnishd -w argument parsing too forgiving ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in revision 1239 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Jan 30 14:22:10 2007 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 30 Jan 2007 14:22:10 -0000 Subject: [Varnish] #60: Mailinglist(s) down In-Reply-To: <077.44da604d739b68f4af2aaf6a1e09b492@projects.linpro.no> References: <077.44da604d739b68f4af2aaf6a1e09b492@projects.linpro.no> Message-ID: <086.d38ca384d0a47003c536c84887b63e13@projects.linpro.no> #60: Mailinglist(s) down ---------------------+------------------------------------------------------ Reporter: tomster | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: website | Version: Severity: major | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: As far as I can see, the mailing lists work just fine and have for quite some time. -- Ticket URL: Varnish The Varnish HTTP Accelerator