From slink at schokola.de Thu Jul 1 17:05:17 2010 From: slink at schokola.de (Nils Goroll) Date: Thu, 01 Jul 2010 19:05:17 +0200 Subject: Limiting header & URI size Message-ID: <4C2CCACD.9090704@schokola.de> Hi, I am referring to Paul-Henning's closing comment in http://varnish-cache.org/ticket/701 : > We already have a length check on the total request: half the workspace. That > should probably become a parameter. Currently, this is enforced by HTC_Rx checking the available space on the ws with respect to the original reservation for half the workspace size made in HTC_Init, so if we wanted to properly enforce limits at that point (including a good HTTP response), we would either need to generate responses from within HTC_Rx or do additional checks wherever HTC_Rx is called (in center, fetch and all waiters), so I didn't find this option particularly attractive. My main motivation to suggest these parameters in this particular way was that someone had used statements like set req.http.someheader = req.http.someheader req.somethingelse multiple times, which makes it hard to control workspace usage (consider restarts, too). In particular, without any limitation of header/uri lengths significantly lower than half the workspace, varnish will easily crash with failed assertions on WS_Alloc() [because increasing the workspace doesn't help much as long as it implicitly increases the limits too]. I thought it was a good idea to make these limits generic parameters because - their existence might help raise awareness that those limits should be something to take note of, - there are specific http response codes (413, 414) to be generated when those limits are exceeded so I thought a generic implementation would be preferable over (user written) VCL code, - in the VCL, these generic checks should be the first thing to run in vcl_recv and vcl_fetch (because backend URI/, so they can't go into the default vcl and - backends will (or at least should) enforce these limits anyway, so it might be possible to make some general recommendations on how to set them or use good default values later. If there are good reasons why not to accept this suggested change, that's fine for me, but I wanted to explain the reasons for my particular approach. > I have moved this to the PostTwoShoppingList wiki page. > (We only use tickets to track actual bugs, not feature requests). I had thorught the best place for suggested patches was trac, so should I prefer the mailing list? Thank you, Nils From captkiddo at gmail.com Tue Jul 6 18:23:32 2010 From: captkiddo at gmail.com (David Brown) Date: Tue, 6 Jul 2010 14:23:32 -0400 Subject: Varnish showing hex characters from Jakarta-Tomcat connector protocol In-Reply-To: References: <73267.1277846564@critter.freebsd.dk> Message-ID: To All, Well I think I have varnish behaving the way that I expected when backend content has both Content-Length and Transfer-Encoding headers. (I know having both is a violation of HTTP 1.1 protocol but I have little control over the backend) I changed the order of logic in cache_fetch.c for determining how the body should be handled. I placed the Transfer-Encoding is statements before the Content-Length statements. That way if backend content has both headers it will used chunked instead of length and the chunked characters don't show up in the browser. >From new cache_fetch.c FetchReqBody(struct sess *sp) { ... /* Moved this if statement up */ if (http_GetHdr(sp->http, H_Transfer_Encoding, NULL)) { /* XXX: Handle chunked encoding. */ WSL(sp->wrk, SLT_Debug, sp->fd, "Transfer-Encoding in request"); return (1); } if (http_GetHdr(sp->http, H_Content_Length, &ptr)) { content_length = strtoul(ptr, &endp, 10); /* XXX should check result of conversion */ while (content_length) { if (content_length > sizeof buf) rdcnt = sizeof buf; else rdcnt = content_length; rdcnt = HTC_Read(sp->htc, buf, rdcnt); if (rdcnt <= 0) return (1); content_length -= rdcnt; if (!sp->sendbody) continue; (void)WRW_Write(sp->wrk, buf, rdcnt); /* XXX: stats ? */ if (WRW_Flush(sp->wrk)) return (2); } ... AND.... FetchBody(struct sess *sp) { ... /* moved this pair of if statements up */ } else if (http_HdrIs(hp, H_Transfer_Encoding, "chunked")) { sp->wrk->stats.fetch_chunked++; cls = fetch_chunked(sp, sp->wrk->htc); mklen = 1; } else if (http_GetHdr(hp, H_Transfer_Encoding, &b)) { sp->wrk->stats.fetch_bad++; /* XXX: AUGH! */ WSL(sp->wrk, SLT_Debug, vc->fd, "Invalid Transfer-Encoding"); VBE_ClosedFd(sp); return (__LINE__); } else if (http_GetHdr(hp, H_Content_Length, &b)) { sp->wrk->stats.fetch_length++; cls = fetch_straight(sp, sp->wrk->htc, b); mklen = 1; } else if (http_HdrIs(hp, H_Connection, "keep-alive")) { .... On Wed, Jun 30, 2010 at 9:08 AM, David Brown wrote: > You were right, it was wrong. The change I made to the VCL fixed the one > problem but screwed up the rest of the site so I had to back it out. > > Attached is a varnish log of the activity. I have some tcpdumps at various > points too if you need them. > > I still think it's connected to tomcat and specifically the JK connector. > It seems the JK connector has an 8K limit (AJP 1.3) and breaks up large > files in the transmission between tomcat and the webserver. The characters > may be (?) part of JK's breakup of the file. My reasoning is because I can > take the same file and place it directly on the web server and no problem, > only when it comes from tomcat/jk do we have these issues. ( I can't > convince the programmers to take static content out of their java apps and > put it on the server ) > > > > On Tue, Jun 29, 2010 at 5:22 PM, Poul-Henning Kamp wrote: > >> In message , >> Davi >> d Brown writes: >> >> >I checked and it seems the Transfer-Encoding header is being stripped by >> >Varnish. I can see it when I go directly to the web server but not when I >> >view the file through Varnish. >> > >> >I worked around the problem by adding this to my VCL >> >> That sounds positively wrong. >> >> Is it possible that you can capture a varnishlog of one of these >> transaction and send to me ? >> >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk at FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by >> incompetence. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andersonbrown8 at gmail.com Wed Jul 7 17:07:00 2010 From: andersonbrown8 at gmail.com (Anderson Brown) Date: Wed, 7 Jul 2010 13:07:00 -0400 Subject: Varnish Handling Redirects Message-ID: Hi All - I tried to search for "redirects" on the mailing list and the wiki, but couldn't find anything that would fit our needs. We have a CDN that, when queried, will return the following: http://router.domain.com/somefile -> will return a 302 to either: + http://sanjose.domain.com/somefile (if you are in the west coast); or + http://newyork.domain.com/somefile (if you are in the east coast) We are going to take baby steps and put varnish on the edge (instead of replacing the entire thing). Questions are: 1) We are planning to configure varnish to point to router.domain.com as parent. Is Varnish able to follow thru the subsequent redirects to [sanjose or newyork]; and return the content to the client? 2) Assuming the answer to number 1 is yes, and Varnish gets /somefile1.txt from sanjose, then when the caching expires and varnish does a "if-not-modified" query to the parent, but gets redirected to newyork. Would it treat the same object as the same (assuming server says file is the same)? Thanks Anderson From stephan.richter at gmail.com Tue Jul 13 21:14:36 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Tue, 13 Jul 2010 17:14:36 -0400 Subject: Varnish Storage API Message-ID: <201007131714.36161.stephan.richter@gmail.com> Hi everyone, I am trying to extend Varnish to fill its cache using an alternative mechanism. In particular, we would like to receive content via multicast and stuff the data into the Varnish cache. When users access the content, it will be served directly from the cache. (Note: I intend to implement the multicast part in a separate process and then send the data to Varnish via a simple Unix socket.) I have skimmed the code base a to determine the API to use to insert data into the cache but could not find it. I have also tried gdb and failed. Could anyone give me some pointers where to start? Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From sky at crucially.net Tue Jul 13 21:16:43 2010 From: sky at crucially.net (Artur Bergman) Date: Tue, 13 Jul 2010 23:16:43 +0200 Subject: Varnish Storage API In-Reply-To: <201007131714.36161.stephan.richter@gmail.com> References: <201007131714.36161.stephan.richter@gmail.com> Message-ID: Could you use a local http server and just pull from it? Artur On Jul 13, 2010, at 11:14 PM, Stephan Richter wrote: > Hi everyone, > > I am trying to extend Varnish to fill its cache using an alternative > mechanism. > > In particular, we would like to receive content via multicast and > stuff the > data into the Varnish cache. When users access the content, it will > be served > directly from the cache. (Note: I intend to implement the multicast > part in a > separate process and then send the data to Varnish via a simple Unix > socket.) > > I have skimmed the code base a to determine the API to use to insert > data into > the cache but could not find it. I have also tried gdb and failed. > Could anyone > give me some pointers where to start? > > Regards, > Stephan > -- > Entrepreneur and Software Geek > Google me. "Zope Stephan Richter" > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > http://lists.varnish-cache.org/mailman/listinfo/varnish-dev From phk at phk.freebsd.dk Tue Jul 13 21:58:50 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Jul 2010 21:58:50 +0000 Subject: Varnish Storage API In-Reply-To: Your message of "Tue, 13 Jul 2010 23:16:43 +0200." Message-ID: <41242.1279058330@critter.freebsd.dk> In message , Artur Bergman writes: >> I have skimmed the code base a to determine the API to use to insert >> data into >> the cache but could not find it. There is no such API. >Could you use a local http server and just pull from it? That is a much better idea for a large number of reasons, in particular testing & development: Write a process which receives the data via M/C, when an object is complete, it sends a HTTP request to Varnish which causes Varnish fetch the object by treating the process as a backend. I can all but guarantee you that this is the fastest and most efficient way to make it work. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From stephan.richter at gmail.com Wed Jul 14 00:25:05 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Tue, 13 Jul 2010 20:25:05 -0400 Subject: Varnish Storage API In-Reply-To: References: <201007131714.36161.stephan.richter@gmail.com> Message-ID: <201007132025.05083.stephan.richter@gmail.com> On Tuesday, July 13, 2010, Artur Bergman wrote: > Could you use a local http server and just pull from it? Hi Artur, thanks for the quick response. I had to smile when I saw this response, since it was exactly the solution I proposed as well. Especially, since I have the multicast component and a Web server for this written already (for another project). However, the powers above me considered this approach a hack, so I am stuck researching a way of modifying the C code to populate the cache. :-( Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From stephan.richter at gmail.com Wed Jul 14 00:36:21 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Tue, 13 Jul 2010 20:36:21 -0400 Subject: Varnish Storage API In-Reply-To: <41242.1279058330@critter.freebsd.dk> References: <41242.1279058330@critter.freebsd.dk> Message-ID: <201007132036.22060.stephan.richter@gmail.com> Hi Poul, thanks for your response as well. On Tuesday, July 13, 2010, Poul-Henning Kamp wrote: > In message , Artur > Bergman > > writes: > >> I have skimmed the code base a to determine the API to use to insert > >> data into > >> the cache but could not find it. > > There is no such API. So inserting into the cache is spread all over? (I would not be surprised. I guess you keep a store plus one or more indexes to find the content efficiently.) > > >Could you use a local http server and just pull from it? > > That is a much better idea for a large number of reasons, in particular > testing & development: > > Write a process which receives the data via M/C, when an object is > complete, it sends a HTTP request to Varnish which causes Varnish > fetch the object by treating the process as a backend. > > I can all but guarantee you that this is the fastest and most > efficient way to make it work. I could not agree more! :-) I am glad that you agree with me. The advantages I see are: 1. No bugs in the cache insertion code. 2. Clear division of concerns (M/C versus caching) 3. No proprietary protocol to communicate across processes (just HTTP). 4. No proprietary C code to maintain. (I am using Python for the rest of the system.) If you can come up with more advantages, I would love to hear them, so I can strengthen my argument. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From phk at phk.freebsd.dk Wed Jul 14 08:23:53 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Jul 2010 08:23:53 +0000 Subject: Varnish Storage API In-Reply-To: Your message of "Tue, 13 Jul 2010 20:25:05 -0400." <201007132025.05083.stephan.richter@gmail.com> Message-ID: <43030.1279095833@critter.freebsd.dk> In message <201007132025.05083.stephan.richter at gmail.com>, Stephan Richter writ es: >On Tuesday, July 13, 2010, Artur Bergman wrote: >However, the powers above me considered this approach a hack, so I am stuck >researching a way of modifying the C code to populate the cache. :-( The the powers that be, that the author of Varnish said that it is by far the least hackish way to get something working reliably. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From stephan.richter at gmail.com Wed Jul 14 13:12:49 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Wed, 14 Jul 2010 09:12:49 -0400 Subject: Varnish Storage API In-Reply-To: <43030.1279095833@critter.freebsd.dk> References: <43030.1279095833@critter.freebsd.dk> Message-ID: <201007140912.49344.stephan.richter@gmail.com> On Wednesday, July 14, 2010, Poul-Henning Kamp wrote: > >However, the powers above me considered this approach a hack, so I am > >stuck researching a way of modifying the C code to populate the cache. > >:-( > > The the powers that be, that the author of Varnish said that it is by > far the least hackish way to get something working reliably. He he. Will do. I already sent them the link to this thread. :-) Thanks a lot for your time and keep up the good work! Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From stephan.richter at gmail.com Wed Jul 14 14:56:42 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Wed, 14 Jul 2010 10:56:42 -0400 Subject: Varnish Storage API In-Reply-To: <43030.1279095833@critter.freebsd.dk> References: <43030.1279095833@critter.freebsd.dk> Message-ID: <201007141056.43132.stephan.richter@gmail.com> On Wednesday, July 14, 2010, Poul-Henning Kamp wrote: > The the powers that be, that the author of Varnish said that it is by > far the least hackish way to get something working reliably. Believe it or not, your and Artur's comments have helped to convince the powers. :-) While discussing the solution, one engineer brought up the following concern. Let's say Varnish gets hammered with user requests and is busy serving them. Now comes the driver HTTP client (the one that forces the retrieval of a file from the backend). If the system is very busy, the driver HTTP request will take a long time to be processed. The goal is to populate the cache as fast as possible, so that incoming user requests will always get the cached data. (This might be a dubious requirement, so tell me if it is so. ;-) Is there a way to give the driver request a higher priority? I have investigated two possibilities without any luck: 1. Run two Varnish instances against the same workspace/shared memory using identical "-n" settings but different frontend ports. This failed with an error message telling me I could not do that. The idea here is that one Varnish instance is "reserved" for the driver client. 2. Add VCL directives to prefer one request over another. I have read carefully through the VCL documentation but could not a way to give a particular request precedence over the rest. Does VCL support something like this? Thanks, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From scaunter at topscms.com Wed Jul 14 18:16:15 2010 From: scaunter at topscms.com (Caunter, Stefan) Date: Wed, 14 Jul 2010 14:16:15 -0400 Subject: Connection dropped, no sess/wrk showing up in varnishstat Message-ID: <7F0AA702B8A85A4A967C4C8EBAD6902C0C8814@TMG-EVS02.torstar.net> Hello list, We are seeing Connection dropped, no sess/wrk appear in varnishstat. I'm not able to find anything that tells me what that means; can anyone enlighten me? I'm fairly sure it's not good, but is it an upstream problem, or is it to do with backends? Anything I should look for in varnishlog? Thanks. Stefan Caunter :: Senior Systems Administrator :: TOPS e: scaunter at topscms.com :: m: (416) 561-4871 www.thestar.com www.topscms.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Jul 14 18:24:11 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Jul 2010 18:24:11 +0000 Subject: Varnish Storage API In-Reply-To: Your message of "Wed, 14 Jul 2010 10:56:42 -0400." <201007141056.43132.stephan.richter@gmail.com> Message-ID: <44645.1279131851@critter.freebsd.dk> In message <201007141056.43132.stephan.richter at gmail.com>, Stephan Richter writ es: >While discussing the solution, one engineer brought up the following concern. >Let's say Varnish gets hammered with user requests and is busy serving them. >Now comes the driver HTTP client (the one that forces the retrieval of a file >from the backend). If the system is very busy, the driver HTTP request will >take a long time to be processed. If that happens, there isn't really anything you can do about it, because the delay will be disk-I/O which will also hit your MC/HTTP process. Without knowing how big your object set/hot set size is, it is hard to predict what the actual pattern will be. What happens if a client asks for an object the varnish does not have ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From stephan.richter at gmail.com Wed Jul 14 18:37:16 2010 From: stephan.richter at gmail.com (Stephan Richter) Date: Wed, 14 Jul 2010 14:37:16 -0400 Subject: Varnish Storage API In-Reply-To: <44645.1279131851@critter.freebsd.dk> References: <44645.1279131851@critter.freebsd.dk> Message-ID: <201007141437.16324.stephan.richter@gmail.com> On Wednesday, July 14, 2010, Poul-Henning Kamp wrote: > If that happens, there isn't really anything you can do about it, because > the delay will be disk-I/O which will also hit your MC/HTTP process. I understand. I thought that would be the answer but did not want to lead to the answer through my question. > Without knowing how big your object set/hot set size is, it is hard to > predict what the actual pattern will be. Unfortunately we do not know that either yet. But it will be in the order of 1k clients asking for video stream data (such as Smooth Streaming or similar HTTP-based video streams). There will be, let's say, 100 channels to watch. Data only has to be kept for a few seconds (since it is live streaming), so thats roughly 500-1000MB of cached files. Of course each client will usually only access one stream at a time. > What happens if a client asks for an object the varnish does not have ? It will fetch it from the backend and the driver request will get the already cached version. So there is a definite fail-safe there. In addition of pre- populating the Varnish cache, the driver makes sure that the data is picked up from the backend, so that the backend's memory footprint is controlled. I much rather have Varnish worry about cache and memory management. :-) Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" From jdzstz at gmail.com Tue Jul 20 22:23:27 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 00:23:27 +0200 Subject: Migration to Cygwin plataform Message-ID: It will be nice to support Varnish in Cygwin plataform ( http://www.cygwin.com ) I have opened a ticket in http://varnish-cache.org/ticket/736 After weeks making some tests I was able to build successful Varnish in Cygwin, the problems that I have found are: 1) Cygwin doesn't support CLOCK_MONOTONIC but HAVE_CLOCK_GETTIME is defined 2) RTLD_LOCAL is not defined in dlfcn.h headers 3) madvise function and MADV_RANDOM define does not exists, in Cygwin their correct names are posix_madvise and POSIX_MADV_RANDOM 4) In Cygwin SO_RCVTIMEO_WORKS and SO_SNDTIMEO_WORKS doesn't work properly because in Windows setsockopt/getsockopt expects time-out in "int" milliseconds instead of "struct timeval" (in future, i think it could be fixed) 5) Linkage problems ("Undefined reference" errors). The undefined reference is because fundamentally ELF (UNIX) and PE/COFF (Windows) are very different in terms of how linking works under the hood. The short explanation is that PE/COFF requires all references to be resolved at link-time: - http://www.cygwin.com/ml/cygwin/2006-12/msg00592.html - http://www.cygwin.com/ml/cygwin/2005-07/msg00675.html - http://www.mail-archive.com/cygwin at cygwin.com/msg81837.html 6) VCL compilation problems ("Undefined reference" errors). VCL compiled DLL uses simbols from EXE. It is necesary to create a fake import file from EXE to allow compilation. I have solved all problems modifing source code and automake scripts. I attach all modification to this ticket. It is also necessary to execute varnishd with cc_command parameter in order to compile VCL correctly: -p cc_command='cc -shared /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_vrt.o /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_backend_cfg.o -L/usr/local/lib -L/tmp/varnish-2.1.2/bin/varnishd/ -lvarnish -lvarnishd -Wl,--export-all-symbols -Wl,-x -o %o %s' I have tested varnish and works OK. I think it will be interesting to add this information to wiki: - http://www.varnish-cache.org/wiki/Installation I have worked with varnish 2.1.2 version, I don't know if there is any change in trunk. The modifications works OK in SOLARIS and CYGWIN platforms, I need somebody to test in Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cygwin_changes.zip Type: application/zip Size: 12063 bytes Desc: not available URL: From phk at phk.freebsd.dk Wed Jul 21 08:13:57 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 21 Jul 2010 08:13:57 +0000 Subject: Migration to Cygwin plataform In-Reply-To: Your message of "Wed, 21 Jul 2010 00:23:27 +0200." Message-ID: <10018.1279700037@critter.freebsd.dk> In message , =?IS O-8859-1?Q?Jorge_D=EDaz?= writes: >After weeks making some tests I was able to build successful Varnish in >Cygwin, the problems that I have found are: Does it pass the regression tests ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From jdzstz at gmail.com Wed Jul 21 09:03:01 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 11:03:01 +0200 Subject: Migration to Cygwin plataform In-Reply-To: <10018.1279700037@critter.freebsd.dk> References: <10018.1279700037@critter.freebsd.dk> Message-ID: Hello, Yesterday, I forgot to ask about the regression test. If I launch it, I have problems with VCL compilation, because tests does not uses the modified "cc_command" that I use with varnishd: *PASS: ./tests/a00006.vtc # top TEST ././tests/a00007.vtc passed (0.052s) PASS: ./tests/a00007.vtc # top TEST ././tests/a00008.vtc passed (1.856s) PASS: ./tests/a00008.vtc Message from C-compiler: ./vcl.1P9zoqAU.c:1: warning: -fpic ignored for target (all code is position independent) /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x16): undefined reference to `_VRT_count' /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x29): undefined reference to `_VRT_count' /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x44): undefined reference to `_VRT_GetHdr' [...] /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x900): undefined reference to `_VRT_handling' /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x93f): undefined reference to `_VRT_init_dir' /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x95d): undefined reference to `_VRT_fini_dir' collect2: ld returned 1 exit status Running C-compiler failed, exit 1Compiled VCL program failed to load: No such file or directory# top TEST ././tests/a00009.vtc passed (3.970s) PASS: ./tests/a00009.vtc # top TEST ././tests/a00010.vtc passed (0.045s) PASS: ./tests/a00010.vtc ---- v1 FAIL VCL does not compile * The VCL command that I use was 'cc -shared /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_vrt.o /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_backend_cfg.o -L/usr/local/lib -L/tmp/varnish-2.1.2/bin/varnishd/ -lvarnish -lvarnishd -Wl,--export-all-symbols -Wl,-x -o %o %s' How can I change default VCL compilation command in order to execute regression tests?? 2010/7/21 Poul-Henning Kamp > In message , > =?IS > O-8859-1?Q?Jorge_D=EDaz?= writes: > > >After weeks making some tests I was able to build successful Varnish in > >Cygwin, the problems that I have found are: > > Does it pass the regression tests ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdzstz at gmail.com Wed Jul 21 09:41:34 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 11:41:34 +0200 Subject: Migration to Cygwin plataform In-Reply-To: References: <10018.1279700037@critter.freebsd.dk> Message-ID: I have run regresion tests both in Cygwin and Solaris platform and I have this results: - Solaris - Varnish 2.1.2 release : 20 of 174 tests failed - Solaris - Varnish 2.1.2 + conditional cygwin modifications : 20 of 174 tests failed - Cygwin - Varnish 2.1.2 + conditional cygwin modifications : problems with VCL compilation because cc_command is different. Solaris has the same results with or without cygwin modifications. I have no Linux platform to run regression tests. About Solaris test error, are you aware of this errors? Thank you 2010/7/21 Jorge D?az > Hello, > > Yesterday, I forgot to ask about the regression test. > > If I launch it, I have problems with VCL compilation, because tests does > not uses the modified "cc_command" that I use with varnishd: > > *PASS: ./tests/a00006.vtc > # top TEST ././tests/a00007.vtc passed (0.052s) > PASS: ./tests/a00007.vtc > # top TEST ././tests/a00008.vtc passed (1.856s) > PASS: ./tests/a00008.vtc > Message from C-compiler: > ./vcl.1P9zoqAU.c:1: warning: -fpic ignored for target (all code is position > independent) > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x16): undefined reference to > `_VRT_count' > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x29): undefined reference to > `_VRT_count' > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x44): undefined reference to > `_VRT_GetHdr' > > [...] > > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x900): undefined reference to > `_VRT_handling' > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x93f): undefined reference to > `_VRT_init_dir' > /tmp/ccJkyGC4.o:vcl.1P9zoqAU.c:(.text+0x95d): undefined reference to > `_VRT_fini_dir' > collect2: ld returned 1 exit status > Running C-compiler failed, exit 1Compiled VCL program failed to load: > No such file or directory# top TEST ././tests/a00009.vtc passed > (3.970s) > PASS: ./tests/a00009.vtc > # top TEST ././tests/a00010.vtc passed (0.045s) > PASS: ./tests/a00010.vtc > ---- v1 FAIL VCL does not compile > * > > The VCL command that I use was 'cc -shared /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_vrt.o > /tmp/varnish-2.1.2/bin/varnishd/varnishd-cache_backend_cfg.o > -L/usr/local/lib -L/tmp/varnish-2.1.2/bin/varnishd/ -lvarnish -lvarnishd > -Wl,--export-all-symbols -Wl,-x -o %o %s' > > How can I change default VCL compilation command in order to execute > regression tests?? > > > > 2010/7/21 Poul-Henning Kamp > > In message , >> =?IS >> O-8859-1?Q?Jorge_D=EDaz?= writes: >> >> >After weeks making some tests I was able to build successful Varnish in >> >Cygwin, the problems that I have found are: >> >> Does it pass the regression tests ? >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk at FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by >> incompetence. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Jul 21 09:42:04 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 21 Jul 2010 09:42:04 +0000 Subject: Migration to Cygwin plataform In-Reply-To: Your message of "Wed, 21 Jul 2010 11:03:01 +0200." Message-ID: <10299.1279705324@critter.freebsd.dk> In message , =?IS O-8859-1?Q?Jorge_D=EDaz?= writes: >--001485f1a0bc9ac095048be2110d >Content-Type: text/plain; charset=ISO-8859-1 > >Hello, > >Yesterday, I forgot to ask about the regression test. > >If I launch it, I have problems with VCL compilation, because tests does not >uses the modified "cc_command" that I use with varnishd: You need to fix the parameter default for the cc_command. Look for how the Solaris platform does it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From jdzstz at gmail.com Wed Jul 21 09:44:25 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 11:44:25 +0200 Subject: Migration to Cygwin plataform In-Reply-To: <10299.1279705324@critter.freebsd.dk> References: <10299.1279705324@critter.freebsd.dk> Message-ID: But I have to change it and recompile all Varnish, or is there any parameter for regression tests like varnishd? 2010/7/21 Poul-Henning Kamp > In message , > =?IS > O-8859-1?Q?Jorge_D=EDaz?= writes: > >--001485f1a0bc9ac095048be2110d > >Content-Type: text/plain; charset=ISO-8859-1 > > > >Hello, > > > >Yesterday, I forgot to ask about the regression test. > > > >If I launch it, I have problems with VCL compilation, because tests does > not > >uses the modified "cc_command" that I use with varnishd: > > You need to fix the parameter default for the cc_command. Look for how > the Solaris platform does it. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Jul 21 09:47:33 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 21 Jul 2010 09:47:33 +0000 Subject: Migration to Cygwin plataform In-Reply-To: Your message of "Wed, 21 Jul 2010 11:44:25 +0200." Message-ID: <10335.1279705653@critter.freebsd.dk> In message , =?IS O-8859-1?Q?Jorge_D=EDaz?= writes: >But I have to change it and recompile all Varnish, or is there any parameter >for regression tests like varnishd? You have to compile it in from the start. The regression test assume that you have a functioning varnishd binary. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From jdzstz at gmail.com Wed Jul 21 16:24:59 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 18:24:59 +0200 Subject: Migration to Cygwin plataform In-Reply-To: <10335.1279705653@critter.freebsd.dk> References: <10335.1279705653@critter.freebsd.dk> Message-ID: Hello, After some problems launching regression tests, I have changed VCC_CC definition in configure.ac for Cygwin platform, and now cc_command parameter is not needed for varnishd. Now, I am able to execute all regression tests, with some errors. I have executed the tests and this is the result: *14 of 174 tests failed* I have some problems with in-use ports: bind(): Address already in use Assert error in server_start(), vtc_server.c line 181: Condition(s->sock >= 0) not true. errno = 112 (Address already in use) /bin/sh: line 5: 5836 Aborted (core dumped) ./varnishtest *Which ports does regression tests need to be free?? perhaps I have to stop some software of my machine * I have also detected some problems with VCL compilation for complex configuration files: #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x59): undefined reference to `_VRT_re_match'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0xc0): undefined reference to `_VRT_re_match'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x628): undefined reference to `_VRT_re_init'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x63c): undefined reference to `_VRT_re_init'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x667): undefined reference to `_VRT_re_fini'\n #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x674): undefined reference to `_VRT_re_fini'\n I think I have to add some dependencies to VCC_CC. The final results are: - Solaris - Varnish 2.1.2 release : 20 of 174 tests failed - Solaris - Varnish 2.1.2 + conditional cygwin modifications : 20 of 174 tests failed - Cygwin - Varnish 2.1.2 + conditional cygwin modifications : 14 of 174 tests failed I attach to the email and Trac ticket last version of my modifications. 2010/7/21 Poul-Henning Kamp > In message , > =?IS > O-8859-1?Q?Jorge_D=EDaz?= writes: > > >But I have to change it and recompile all Varnish, or is there any > parameter > >for regression tests like varnishd? > > You have to compile it in from the start. > > The regression test assume that you have a functioning varnishd binary. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cygwin_changes_v2.zip Type: application/zip Size: 12254 bytes Desc: not available URL: From jdzstz at gmail.com Wed Jul 21 17:48:56 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 21 Jul 2010 19:48:56 +0200 Subject: Migration to Cygwin plataform In-Reply-To: References: <10335.1279705653@critter.freebsd.dk> Message-ID: After one small change in configure.ac (I have added file "varnishd-cache_vrt_re.o" to VCC_C command) the VCL compilation problem has disappear and now regression tests problems are only 9: *9 of 174 tests failed* I attach the new version. I continue having problems of "bind(): Address already in use" *Which ports does regression tests need to be free?? perhaps I have to stop some software of my machine * Assert error in server_start(), vtc_server.c line 181: Condition(s->sock >= 0) not true. errno = 112 (Address already in use) /bin/sh: line 5: 3376 Aborted (core dumped) ./varnishtest ${dir}$tst FAIL: ./tests/v00014.vtc *I also need somebody to test script modifications in Linux. I have tested in my Solaris enviroment and it is ok.* Thank you. 2010/7/21 Jorge D?az > Hello, > > After some problems launching regression tests, I have changed VCC_CC > definition in configure.ac for Cygwin platform, and now cc_command > parameter is not needed for varnishd. > > Now, I am able to execute all regression tests, with some errors. > > I have executed the tests and this is the result: > > *14 of 174 tests failed* > > I have some problems with in-use ports: > > bind(): Address already in use > Assert error in server_start(), vtc_server.c line 181: > Condition(s->sock >= 0) not true. > errno = 112 (Address already in use) > > /bin/sh: line 5: 5836 Aborted (core dumped) ./varnishtest > > > *Which ports does regression tests need to be free?? perhaps I have to > stop some software of my machine * > > I have also detected some problems with VCL compilation for complex > configuration files: > > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x59): undefined reference to `_VRT_re_match'\n > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0xc0): undefined reference to `_VRT_re_match'\n > > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x628): undefined reference to `_VRT_re_init'\n > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x63c): undefined reference to `_VRT_re_init'\n > > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x667): undefined reference to `_VRT_re_fini'\n > #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x674): undefined reference to `_VRT_re_fini'\n > > > I think I have to add some dependencies to VCC_CC. > > The final results are: > > - Solaris - Varnish 2.1.2 release : 20 of 174 tests failed > - Solaris - Varnish 2.1.2 + conditional cygwin modifications : 20 of > 174 tests failed > - Cygwin - Varnish 2.1.2 + conditional cygwin modifications : 14 of 174 > tests failed > > > I attach to the email and Trac ticket last version of my modifications. > > > > > 2010/7/21 Poul-Henning Kamp > >> In message , >> =?IS >> >> O-8859-1?Q?Jorge_D=EDaz?= writes: >> >> >But I have to change it and recompile all Varnish, or is there any >> parameter >> >for regression tests like varnishd? >> >> You have to compile it in from the start. >> >> The regression test assume that you have a functioning varnishd binary. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk at FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by >> incompetence. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cygwin_changes_v3.zip Type: application/zip Size: 12260 bytes Desc: not available URL: From jdzstz at gmail.com Wed Jul 28 19:12:03 2010 From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=) Date: Wed, 28 Jul 2010 21:12:03 +0200 Subject: Migration to Cygwin plataform In-Reply-To: References: <10335.1279705653@critter.freebsd.dk> Message-ID: I have apply all my changes to svn trunk version of varnish. I attach it to email. Can I commit myself to subversion? With varnish trunk version I have executed regression tests and this is the result: 8 of 183 tests failed They are: FAIL: ./tests/b00004.vtc FAIL: ./tests/b00015.vtc FAIL: ./tests/b00030.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/p00002.vtc FAIL: ./tests/r00558.vtc FAIL: ./tests/v00009.vtc FAIL: ./tests/v00027.vtc I also attach regression test logs to email. Some of that error are [ * top Test timed out ] Do you know some issue with timeout in regression tests? 2010/7/21 Jorge D?az > After one small change in configure.ac (I have added file > "varnishd-cache_vrt_re.o" to VCC_C command) the VCL compilation problem has > disappear and now regression tests problems are only 9: > > *9 of 174 tests failed* > > I attach the new version. > > I continue having problems of "bind(): Address already in use" > > *Which ports does regression tests need to be free?? perhaps I have to > stop some software of my machine * > Assert error in server_start(), vtc_server.c line 181: > Condition(s->sock >= 0) not true. > errno = 112 (Address already in use) > /bin/sh: line 5: 3376 Aborted (core dumped) ./varnishtest > ${dir}$tst > FAIL: ./tests/v00014.vtc > > *I also need somebody to test script modifications in Linux. I have tested > in my Solaris enviroment and it is ok.* > > Thank you. > > 2010/7/21 Jorge D?az > >> Hello, >> >> >> After some problems launching regression tests, I have changed VCC_CC >> definition in configure.ac for Cygwin platform, and now cc_command >> parameter is not needed for varnishd. >> >> Now, I am able to execute all regression tests, with some errors. >> >> I have executed the tests and this is the result: >> >> *14 of 174 tests failed* >> >> I have some problems with in-use ports: >> >> bind(): Address already in use >> Assert error in server_start(), vtc_server.c line 181: >> >> >> Condition(s->sock >= 0) not true. >> errno = 112 (Address already in use) >> >> /bin/sh: line 5: 5836 Aborted (core dumped) ./varnishtest >> >> >> *Which ports does regression tests need to be free?? perhaps I have to >> stop some software of my machine * >> >> I have also detected some problems with VCL compilation for complex >> configuration files: >> >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x59): undefined reference to `_VRT_re_match'\n >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0xc0): undefined reference to `_VRT_re_match'\n >> >> >> >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x628): undefined reference to `_VRT_re_init'\n >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x63c): undefined reference to `_VRT_re_init'\n >> >> >> >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x667): undefined reference to `_VRT_re_fini'\n >> #### v1 CLI RX| /tmp/ccA54nFN.o:vcl.hfK6_VaS.c:(.text+0x674): undefined reference to `_VRT_re_fini'\n >> >> >> >> I think I have to add some dependencies to VCC_CC. >> >> The final results are: >> >> - Solaris - Varnish 2.1.2 release : 20 of 174 tests failed >> - Solaris - Varnish 2.1.2 + conditional cygwin modifications : 20 of >> 174 tests failed >> - Cygwin - Varnish 2.1.2 + conditional cygwin modifications : 14 of >> 174 tests failed >> >> >> I attach to the email and Trac ticket last version of my modifications. >> >> >> >> >> 2010/7/21 Poul-Henning Kamp >> >>> In message , >>> =?IS >>> >>> O-8859-1?Q?Jorge_D=EDaz?= writes: >>> >>> >But I have to change it and recompile all Varnish, or is there any >>> parameter >>> >for regression tests like varnishd? >>> >>> You have to compile it in from the start. >>> >>> The regression test assume that you have a functioning varnishd binary. >>> >>> -- >>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >>> phk at FreeBSD.ORG | TCP/IP since RFC 956 >>> FreeBSD committer | BSD since 4.3-tahoe >>> Never attribute to malice what can adequately be explained by >>> incompetence. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- $ make check Making check in include make[1]: Entering directory `/tmp/varnish-cache/include' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/tmp/varnish-cache/include' Making check in lib make[1]: Entering directory `/tmp/varnish-cache/lib' Making check in libvarnishcompat make[2]: Entering directory `/tmp/varnish-cache/lib/libvarnishcompat' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/lib/libvarnishcompat' Making check in libvarnish make[2]: Entering directory `/tmp/varnish-cache/lib/libvarnish' V="$(sh -c "git log -n 1 --pretty=format:%h" 2>/dev/null || LANG=C svnversion -n ../..)" \ H="$(head -n 1 svn_version.c 2>/dev/null || true)"; \ [ "$V" = "exported" ] && [ -e svn_version.c ] && exit 0 ; \ if [ "/* $V */" != "$H" ]; then \ ( \ echo "/* $V */" ;\ echo "#include " ;\ echo "const char* svn_version(void)" ;\ echo "{" ;\ echo " const char* SVN_Version = \"$V\";" ;\ echo " return SVN_Version;" ;\ echo "}" ;\ ) > svn_version.c ; \ fi /bin/sh: svnversion: command not found make check-TESTS make[3]: Entering directory `/tmp/varnish-cache/lib/libvarnish' ================== All 0 tests passed ================== make[3]: Leaving directory `/tmp/varnish-cache/lib/libvarnish' make[2]: Leaving directory `/tmp/varnish-cache/lib/libvarnish' Making check in libvarnishapi make[2]: Entering directory `/tmp/varnish-cache/lib/libvarnishapi' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/lib/libvarnishapi' Making check in libvcl make[2]: Entering directory `/tmp/varnish-cache/lib/libvcl' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/lib/libvcl' make[2]: Entering directory `/tmp/varnish-cache/lib' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/tmp/varnish-cache/lib' make[1]: Leaving directory `/tmp/varnish-cache/lib' Making check in bin make[1]: Entering directory `/tmp/varnish-cache/bin' Making check in varnishadm make[2]: Entering directory `/tmp/varnish-cache/bin/varnishadm' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishadm' Making check in varnishd make[2]: Entering directory `/tmp/varnish-cache/bin/varnishd' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishd' Making check in varnishlog make[2]: Entering directory `/tmp/varnish-cache/bin/varnishlog' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishlog' Making check in varnishncsa make[2]: Entering directory `/tmp/varnish-cache/bin/varnishncsa' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishncsa' Making check in varnishreplay make[2]: Entering directory `/tmp/varnish-cache/bin/varnishreplay' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishreplay' Making check in varnishtest make[2]: Entering directory `/tmp/varnish-cache/bin/varnishtest' make check-TESTS make[3]: Entering directory `/tmp/varnish-cache/bin/varnishtest' # top TEST ././tests/a00000.vtc passed (0.045s) PASS: ./tests/a00000.vtc # top TEST ././tests/a00001.vtc passed (0.027s) PASS: ./tests/a00001.vtc # top TEST ././tests/a00002.vtc passed (0.031s) PASS: ./tests/a00002.vtc # top TEST ././tests/a00003.vtc passed (0.029s) PASS: ./tests/a00003.vtc # top TEST ././tests/a00004.vtc passed (0.458s) PASS: ./tests/a00004.vtc # top TEST ././tests/a00005.vtc passed (0.032s) PASS: ./tests/a00005.vtc # top TEST ././tests/a00006.vtc passed (0.029s) PASS: ./tests/a00006.vtc # top TEST ././tests/a00007.vtc passed (0.033s) PASS: ./tests/a00007.vtc # top TEST ././tests/a00008.vtc passed (1.843s) PASS: ./tests/a00008.vtc # top TEST ././tests/a00009.vtc passed (3.586s) PASS: ./tests/a00009.vtc # top TEST ././tests/a00010.vtc passed (0.028s) PASS: ./tests/a00010.vtc # top TEST ././tests/b00000.vtc passed (5.750s) PASS: ./tests/b00000.vtc # top TEST ././tests/b00001.vtc passed (5.432s) PASS: ./tests/b00001.vtc # top TEST ././tests/b00002.vtc passed (5.243s) PASS: ./tests/b00002.vtc # top TEST ././tests/b00003.vtc passed (5.358s) PASS: ./tests/b00003.vtc **** top macro def tmpdir=/tmp/vtc.7472.10ea5ca5 **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/b00004.vtc starting *** top test * top TEST Torture Varnish with start/stop commands *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=1660 **** s1 macro def s1_sock=127.0.0.1:1660 * s1 Listen on 127.0.0.1:1660 *** top varnish ** s1 Started on 127.0.0.1:1660 ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.7472.10ea5ca5/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.7472.10ea5ca5/v1/_S -M 127.0.0.1:1661 -P /tmp/vtc.7472.10ea5ca5/v1/varnishd.pid -sfile,/tmp/vtc.7472.10ea5ca5/v1,10M *** v1 debug| storage_file: filename: /tmp/vtc.7472.10ea5ca5/v1/varnish.YtffYV size 10 MB.\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-sfile,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 5 *** v1 CLI RX 107 **** v1 CLI RX| gqrutwfhifbaekkyjxqtgsrigqnllyur\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth 8ffb388cd2ce9139645f003423e13339ba70c8410ab1b560d83613fab2dcf73a\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"1660\"; }\n " *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 *** top varnish ** v1 Start **** v1 CLI TX| start *** v1 debug| child (6392) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (6392) said \n *** v1 debug| Child (6392) said Child starts\n *** v1 debug| Child (6392) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 1663\n ** v1 Listen on 127.0.0.1 1663 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=1663 **** v1 macro def v1_sock=127.0.0.1:1663 *** top varnish **** v1 macro undef v1_addr **** v1 macro undef v1_port **** v1 macro undef v1_sock ** v1 Stop **** v1 CLI TX| stop *** v1 CLI RX 200 **** v1 CLI TX| status *** v1 debug| Stopping Child\n *** v1 debug| Child (6392) said Child dies\n *** v1 debug| Child (6392) died\n *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopping *** v1 debug| Child cleanup complete\n **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopped *** top varnish ** v1 Start **** v1 CLI TX| start *** v1 debug| child (6116) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (6116) said \n *** v1 debug| Child (6116) said Child starts\n *** v1 debug| Child (6116) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 1664\n ** v1 Listen on 127.0.0.1 1664 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=1664 **** v1 macro def v1_sock=127.0.0.1:1664 *** top varnish **** v1 macro undef v1_addr **** v1 macro undef v1_port **** v1 macro undef v1_sock ** v1 Stop **** v1 CLI TX| stop *** v1 CLI RX 200 **** v1 CLI TX| status *** v1 debug| Stopping Child\n *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopping *** v1 debug| Child (6116) said Child dies\n *** v1 debug| Child (6116) died\n *** v1 debug| Child cleanup complete\n **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopped *** top varnish ** v1 Start **** v1 CLI TX| start *** v1 debug| child (4200) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (4200) said \n *** v1 debug| Child (4200) said Child starts\n *** v1 debug| Child (4200) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 1665\n ** v1 Listen on 127.0.0.1 1665 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=1665 **** v1 macro def v1_sock=127.0.0.1:1665 *** top varnish **** v1 macro undef v1_addr **** v1 macro undef v1_port **** v1 macro undef v1_sock ** v1 Stop **** v1 CLI TX| stop *** v1 debug| Stopping Child\n *** v1 CLI RX 200 **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopping *** v1 debug| Child (4200) said Child dies\n *** v1 debug| Child (4200) died\n *** v1 debug| Child cleanup complete\n **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopped *** top varnish **** v1 CLI TX| start *** v1 debug| child (7604) Started\n *** v1 CLI RX 200 ** v1 CLI 200 *** top varnish **** v1 CLI TX| start *** v1 CLI RX 300 **** v1 CLI RX| Child in state running ** v1 CLI 300 *** top varnish **** v1 CLI TX| start *** v1 CLI RX 300 **** v1 CLI RX| Child in state running ** v1 CLI 300 *** top varnish **** v1 CLI TX| stop *** v1 CLI RX 200 ** v1 CLI 200 *** top varnish **** v1 CLI TX| stop *** v1 CLI RX 300 **** v1 CLI RX| Child in state stopping ** v1 CLI 300 *** top varnish **** v1 CLI TX| stop *** v1 CLI RX 300 **** v1 CLI RX| Child in state stopping ** v1 CLI 300 *** top varnish ** v1 Stop **** v1 CLI TX| stop *** v1 CLI RX 300 **** v1 CLI RX| Child in state stopping **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopping *** v1 debug| Child (7604) said \n *** v1 debug| Child (7604) said Child starts\n *** v1 debug| Child (7604) said managed to mmap 10485760 bytes of 10485760\n *** v1 debug| Stopping Child\n *** v1 debug| Child (7604) said Child dies\n *** v1 debug| Child (7604) died\n *** v1 debug| Child cleanup complete\n **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopped ** v1 Wait ** v1 R 5068 Status: 0000 * top RESETTING after ././tests/b00004.vtc ** s1 Waiting for server * top Test timed out * top TEST ././tests/b00004.vtc FAILED FAIL: ./tests/b00004.vtc # top TEST ././tests/b00005.vtc passed (5.535s) PASS: ./tests/b00005.vtc # top TEST ././tests/b00006.vtc passed (5.210s) PASS: ./tests/b00006.vtc # top TEST ././tests/b00007.vtc passed (4.848s) PASS: ./tests/b00007.vtc # top TEST ././tests/b00008.vtc passed (4.762s) PASS: ./tests/b00008.vtc # top TEST ././tests/b00009.vtc passed (5.031s) PASS: ./tests/b00009.vtc # top TEST ././tests/b00010.vtc passed (4.853s) PASS: ./tests/b00010.vtc # top TEST ././tests/b00011.vtc passed (5.121s) PASS: ./tests/b00011.vtc # top TEST ././tests/b00012.vtc passed (5.010s) PASS: ./tests/b00012.vtc # top TEST ././tests/b00013.vtc passed (5.060s) PASS: ./tests/b00013.vtc # top TEST ././tests/b00014.vtc passed (6.863s) PASS: ./tests/b00014.vtc bind(): Address already in use Assert error in server_start(), vtc_server.c line 183: Condition(s->sock >= 0) not true. errno = 112 (Address already in use) *** starting debugger for pid 7864, tid 7020 *** continuing pid 7864 from debugger call (1) /bin/sh: line 5: 2364 Aborted (core dumped) ./varnishtest ${dir}$tst FAIL: ./tests/b00015.vtc # top TEST ././tests/b00016.vtc passed (9.134s) PASS: ./tests/b00016.vtc # top TEST ././tests/b00017.vtc passed (5.546s) PASS: ./tests/b00017.vtc # top TEST ././tests/b00018.vtc passed (5.343s) PASS: ./tests/b00018.vtc # top TEST ././tests/b00019.vtc passed (6.062s) PASS: ./tests/b00019.vtc # top TEST ././tests/b00020.vtc passed (0.000s) PASS: ./tests/b00020.vtc # top TEST ././tests/b00021.vtc passed (0.000s) PASS: ./tests/b00021.vtc # top TEST ././tests/b00022.vtc passed (0.000s) PASS: ./tests/b00022.vtc # top TEST ././tests/b00023.vtc passed (0.000s) PASS: ./tests/b00023.vtc # top TEST ././tests/b00024.vtc passed (0.000s) PASS: ./tests/b00024.vtc # top TEST ././tests/b00025.vtc passed (0.015s) PASS: ./tests/b00025.vtc # top TEST ././tests/b00026.vtc passed (0.015s) PASS: ./tests/b00026.vtc # top TEST ././tests/b00027.vtc passed (5.421s) PASS: ./tests/b00027.vtc # top TEST ././tests/b00028.vtc passed (5.296s) PASS: ./tests/b00028.vtc # top TEST ././tests/b00029.vtc passed (8.515s) PASS: ./tests/b00029.vtc **** top macro def tmpdir=/tmp/vtc.7476.4384ff43 **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/b00030.vtc starting *** top test * top TEST Test formatting of timestamps *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=1780 **** s1 macro def s1_sock=127.0.0.1:1780 * s1 Listen on 127.0.0.1:1780 *** top varnish ** s1 Started on 127.0.0.1:1780 ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.7476.4384ff43/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.7476.4384ff43/v1/_S -M 127.0.0.1:1781 -P /tmp/vtc.7476.4384ff43/v1/varnishd.pid -sfile,/tmp/vtc.7476.4384ff43/v1,10M *** v1 debug| storage_file: filename: /tmp/vtc.7476.4384ff43/v1/varnish.zmIl16 size 10 MB.\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-sfile,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 5 *** v1 CLI RX 107 **** v1 CLI RX| nerglbrnmmkqjjdawxqdgipcrlxouaii\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth 93dcabd416b862fe7db2ad7abe8636fc84f76256210766773294e56bf338c11a\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"1780\"; }\n\n\tsub vcl_recv {\n\t\terror 200 req.grace;\n\t}\n\tsub vcl_error { \n\t\tset obj.http.x-timestamp = now;\n\t}\n" *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 ** v1 Start **** v1 CLI TX| start *** v1 debug| child (6176) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (6176) said \n *** v1 debug| Child (6176) said Child starts\n *** v1 debug| Child (6176) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 1783\n ** v1 Listen on 127.0.0.1 1783 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=1783 **** v1 macro def v1_sock=127.0.0.1:1783 *** top client ** c1 Starting client *** c1 Connect to 127.0.0.1:1783 ** c1 Waiting for client *** c1 connected fd 8 *** c1 txreq **** c1 txreq| GET / HTTP/1.1\r\n **** c1 txreq| \r\n *** c1 rxresp **** c1 rxhdr| HTTP/1.1 200 10.000\r\n **** c1 rxhdr| Server: Varnish\r\n **** c1 rxhdr| Retry-After: 0\r\n **** c1 rxhdr| x-timestamp: Wed, 28 Jul 2010 18:46:25 GMT\r\n **** c1 rxhdr| Content-Type: text/html; charset=utf-8\r\n **** c1 rxhdr| Content-Length: 374\r\n **** c1 rxhdr| Date: Wed, 28 Jul 2010 18:46:25 GMT\r\n **** c1 rxhdr| X-Varnish: 1001\r\n **** c1 rxhdr| Age: 0\r\n **** c1 rxhdr| Via: 1.1 varnish\r\n **** c1 rxhdr| Connection: close\r\n **** c1 rxhdr| \r\n **** c1 http[ 0] | HTTP/1.1 **** c1 http[ 1] | 200 **** c1 http[ 2] | 10.000 **** c1 http[ 3] | Server: Varnish **** c1 http[ 4] | Retry-After: 0 **** c1 http[ 5] | x-timestamp: Wed, 28 Jul 2010 18:46:25 GMT **** c1 http[ 6] | Content-Type: text/html; charset=utf-8 **** c1 http[ 7] | Content-Length: 374 **** c1 http[ 8] | Date: Wed, 28 Jul 2010 18:46:25 GMT **** c1 http[ 9] | X-Varnish: 1001 **** c1 http[10] | Age: 0 **** c1 http[11] | Via: 1.1 varnish **** c1 http[12] | Connection: close **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| 200 10.000\n **** c1 body| \n **** c1 body| \n **** c1 body|

Error 200 10.000

\n **** c1 body|

10.000

\n **** c1 body|

Guru Meditation:

\n **** c1 body|

XID: 1001

\n **** c1 body|
\n **** c1 body|

Varnish cache server

\n **** c1 body| \n **** c1 body| \n **** c1 bodylen = 374 *** c1 expect **** c1 EXPECT resp.msg (10.000) == 10.000 (10.000) match *** c1 closing fd 8 ** c1 Ending * top RESETTING after ././tests/b00030.vtc ** s1 Waiting for server * top Test timed out * top TEST ././tests/b00030.vtc FAILED FAIL: ./tests/b00030.vtc # top TEST ././tests/b00031.vtc passed (5.281s) PASS: ./tests/b00031.vtc # top TEST ././tests/b00032.vtc passed (1.906s) PASS: ./tests/b00032.vtc # top TEST ././tests/b00033.vtc passed (5.390s) PASS: ./tests/b00033.vtc # top TEST ././tests/c00001.vtc passed (5.484s) PASS: ./tests/c00001.vtc # top TEST ././tests/c00002.vtc passed (5.859s) PASS: ./tests/c00002.vtc # top TEST ././tests/c00003.vtc passed (5.484s) PASS: ./tests/c00003.vtc # top TEST ././tests/c00004.vtc passed (5.421s) PASS: ./tests/c00004.vtc ---- s1 HTTP rx failed (poll: No error) ---- v1 FAIL VCL does not compile **** top macro def tmpdir=/tmp/vtc.3576.6588c0a9 **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/c00005.vtc starting *** top test * top TEST Test simple ACL *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=1824 **** s1 macro def s1_sock=127.0.0.1:1824 * s1 Listen on 127.0.0.1:1824 *** top varnish ** s1 Started on 127.0.0.1:1824 ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.3576.6588c0a9/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.3576.6588c0a9/v1/_S -M 127.0.0.1:1825 -P /tmp/vtc.3576.6588c0a9/v1/varnishd.pid -sfile,/tmp/vtc.3576.6588c0a9/v1,10M -p vcl_trace=on *** v1 debug| storage_file: filename: /tmp/vtc.3576.6588c0a9/v1/varnish.bLvHVv size 10 MB.\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-sfile,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 5 *** v1 CLI RX 107 **** v1 CLI RX| ueuyhjmkjabbuixdejhrjlaqqluimuvg\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth 80465acc13e1b3f11e0636961f7f9a4c6c3b498c6cb3fc5566aa0e4623ce5f8a\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"1824\"; }\n\n\tacl acl1 {\n\t\t\"localhost\";\n\t}\n\n\tsub vcl_recv {\n\t\tif (client.ip ~ acl1) {\n\t\t\tset req.url = \"/\";\n\t\t}\n\t}\n" *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 ** v1 Start **** v1 CLI TX| start *** v1 debug| child (516) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (516) said \n *** v1 debug| Child (516) said Child starts\n *** v1 debug| Child (516) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 1827\n ** v1 Listen on 127.0.0.1 1827 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=1827 **** v1 macro def v1_sock=127.0.0.1:1827 *** top client ** c1 Starting client *** c1 Connect to 127.0.0.1:1827 ** c1 Waiting for client *** c1 connected fd 8 *** c1 txreq **** c1 txreq| GET foo HTTP/1.1\r\n **** c1 txreq| \r\n *** c1 rxresp *** s1 accepted fd 9 *** s1 rxreq **** s1 rxhdr| GET / HTTP/1.1\r\n **** s1 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 rxhdr| X-Varnish: 1001\r\n **** s1 rxhdr| Host: 127.0.0.1\r\n **** s1 rxhdr| \r\n **** s1 http[ 0] | GET **** s1 http[ 1] | / **** s1 http[ 2] | HTTP/1.1 **** s1 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 http[ 4] | X-Varnish: 1001 **** s1 http[ 5] | Host: 127.0.0.1 **** s1 bodylen = 0 *** s1 expect **** s1 EXPECT req.url (/) == / (/) match *** s1 txresp **** s1 txresp| HTTP/1.1 200 Ok\r\n **** s1 txresp| Content-Length: 5\r\n **** s1 txresp| \r\n **** s1 txresp| 1111\n *** s1 rxreq **** c1 rxhdr| HTTP/1.1 200 Ok\r\n **** c1 rxhdr| Content-Length: 5\r\n **** c1 rxhdr| Date: Wed, 28 Jul 2010 18:47:35 GMT\r\n **** c1 rxhdr| X-Varnish: 1001\r\n **** c1 rxhdr| Age: 0\r\n **** c1 rxhdr| Via: 1.1 varnish\r\n **** c1 rxhdr| Connection: keep-alive\r\n **** c1 rxhdr| \r\n **** c1 http[ 0] | HTTP/1.1 **** c1 http[ 1] | 200 **** c1 http[ 2] | Ok **** c1 http[ 3] | Content-Length: 5 **** c1 http[ 4] | Date: Wed, 28 Jul 2010 18:47:35 GMT **** c1 http[ 5] | X-Varnish: 1001 **** c1 http[ 6] | Age: 0 **** c1 http[ 7] | Via: 1.1 varnish **** c1 http[ 8] | Connection: keep-alive **** c1 body| 1111\n **** c1 bodylen = 5 *** c1 expect **** c1 EXPECT resp.status (200) == 200 (200) match *** c1 closing fd 8 ** c1 Ending *** top varnish **** v1 CLI TX| vcl.inline vcl2 "backend s1 { .host = \"127.0.0.1\"; .port = \"1824\"; }\n\n\tacl acl1 {\n\t\t! \"localhost\";\n\t\t\"0.0.0.0\" / 0;\n\t\t\":: \" / 0;\n\t}\n\n\tsub vcl_recv {\n\t\tif (client.ip ~ acl1) {\n\t\t\tset req.url = \"/\";\n\t\t}\n\t}\n" ---- s1 HTTP rx failed (poll: No error) *** v1 CLI RX 106 **** v1 CLI RX| Message from VCC-compiler:\n **** v1 CLI RX| DNS lookup(::): hostname nor servname provided, or not known\n **** v1 CLI RX| (input Line 6 Pos 17)\n **** v1 CLI RX| "::" / 0;\n **** v1 CLI RX| ----------------####-----\n **** v1 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 CLI RX| \n **** v1 CLI RX| VCL compilation failed ---- v1 FAIL VCL does not compile * top RESETTING after ././tests/c00005.vtc ** s1 Waiting for server ** v1 Wait ** v1 R 3952 Status: 0000 * top TEST ././tests/c00005.vtc FAILED FAIL: ./tests/c00005.vtc # top TEST ././tests/c00006.vtc passed (5.343s) PASS: ./tests/c00006.vtc # top TEST ././tests/c00007.vtc passed (5.265s) PASS: ./tests/c00007.vtc # top TEST ././tests/c00008.vtc passed (5.281s) PASS: ./tests/c00008.vtc # top TEST ././tests/c00009.vtc passed (5.328s) PASS: ./tests/c00009.vtc # top TEST ././tests/c00010.vtc passed (5.312s) PASS: ./tests/c00010.vtc # top TEST ././tests/c00011.vtc passed (5.312s) PASS: ./tests/c00011.vtc # top TEST ././tests/c00012.vtc passed (5.484s) PASS: ./tests/c00012.vtc # top TEST ././tests/c00013.vtc passed (6.250s) PASS: ./tests/c00013.vtc # top TEST ././tests/c00014.vtc passed (5.312s) PASS: ./tests/c00014.vtc # top TEST ././tests/c00015.vtc passed (7.359s) PASS: ./tests/c00015.vtc # top TEST ././tests/c00016.vtc passed (5.406s) PASS: ./tests/c00016.vtc # top TEST ././tests/c00017.vtc passed (6.703s) PASS: ./tests/c00017.vtc # top TEST ././tests/c00018.vtc passed (5.484s) PASS: ./tests/c00018.vtc # top TEST ././tests/c00019.vtc passed (5.891s) PASS: ./tests/c00019.vtc # top TEST ././tests/c00020.vtc passed (5.562s) PASS: ./tests/c00020.vtc # top TEST ././tests/c00021.vtc passed (6.906s) PASS: ./tests/c00021.vtc # top TEST ././tests/c00022.vtc passed (6.093s) PASS: ./tests/c00022.vtc # top TEST ././tests/c00023.vtc passed (5.687s) PASS: ./tests/c00023.vtc # top TEST ././tests/c00024.vtc passed (5.343s) PASS: ./tests/c00024.vtc # top TEST ././tests/c00025.vtc passed (5.328s) PASS: ./tests/c00025.vtc # top TEST ././tests/c00026.vtc passed (5.531s) PASS: ./tests/c00026.vtc # top TEST ././tests/c00027.vtc passed (5.328s) PASS: ./tests/c00027.vtc # top TEST ././tests/c00028.vtc passed (5.437s) PASS: ./tests/c00028.vtc # top TEST ././tests/c00029.vtc passed (10.281s) PASS: ./tests/c00029.vtc # top TEST ././tests/c00030.vtc passed (10.500s) PASS: ./tests/c00030.vtc # top TEST ././tests/c00031.vtc passed (5.281s) PASS: ./tests/c00031.vtc # top TEST ././tests/c00032.vtc passed (5.328s) PASS: ./tests/c00032.vtc # top TEST ././tests/c00033.vtc passed (5.421s) PASS: ./tests/c00033.vtc # top TEST ././tests/c00034.vtc passed (5.265s) PASS: ./tests/c00034.vtc # top TEST ././tests/e00000.vtc passed (5.187s) PASS: ./tests/e00000.vtc # top TEST ././tests/e00001.vtc passed (5.437s) PASS: ./tests/e00001.vtc # top TEST ././tests/e00002.vtc passed (5.312s) PASS: ./tests/e00002.vtc # top TEST ././tests/e00003.vtc passed (5.281s) PASS: ./tests/e00003.vtc # top TEST ././tests/e00004.vtc passed (5.906s) PASS: ./tests/e00004.vtc # top TEST ././tests/e00005.vtc passed (5.234s) PASS: ./tests/e00005.vtc # top TEST ././tests/e00006.vtc passed (5.250s) PASS: ./tests/e00006.vtc # top TEST ././tests/e00007.vtc passed (5.265s) PASS: ./tests/e00007.vtc # top TEST ././tests/e00008.vtc passed (5.406s) PASS: ./tests/e00008.vtc # top TEST ././tests/e00009.vtc passed (5.296s) PASS: ./tests/e00009.vtc # top TEST ././tests/e00010.vtc passed (5.312s) PASS: ./tests/e00010.vtc # top TEST ././tests/e00011.vtc passed (5.390s) PASS: ./tests/e00011.vtc # top TEST ././tests/e00012.vtc passed (5.296s) PASS: ./tests/e00012.vtc # top TEST ././tests/e00013.vtc passed (5.343s) PASS: ./tests/e00013.vtc # top TEST ././tests/e00014.vtc passed (5.296s) PASS: ./tests/e00014.vtc # top TEST ././tests/e00015.vtc passed (5.218s) PASS: ./tests/e00015.vtc # top TEST ././tests/e00016.vtc passed (5.250s) PASS: ./tests/e00016.vtc # top TEST ././tests/e00017.vtc passed (5.546s) PASS: ./tests/e00017.vtc # top TEST ././tests/e00018.vtc passed (5.359s) PASS: ./tests/e00018.vtc # top TEST ././tests/p00000.vtc passed (8.750s) PASS: ./tests/p00000.vtc # top TEST ././tests/p00001.vtc passed (15.515s) PASS: ./tests/p00001.vtc **** top macro def tmpdir=/tmp/vtc.4392.1d687a1a **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/p00002.vtc starting *** top test * top TEST Ban a persistent object *** top shell **** top shell| rm -f /tmp/vtc.4392.1d687a1a/_.per[12] *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=2207 **** s1 macro def s1_sock=127.0.0.1:2207 * s1 Listen on 127.0.0.1:2207 ** s1 Started on 127.0.0.1:2207 *** top varnish ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.4392.1d687a1a/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.4392.1d687a1a/v1/_S -M 127.0.0.1:2208 -P /tmp/vtc.4392.1d687a1a/v1/varnishd.pid -spersistent,/tmp/vtc.4392.1d687a1a/_.per2,10m -pdiag_bitmap=0x20000 -pba n_lurker_sleep=0 *** v1 debug| sizeof(struct smp_ident) = 112 = 0x70\n *** v1 debug| sizeof(struct smp_sign) = 32 = 0x20\n *** v1 debug| sizeof(struct smp_segptr) = 32 = 0x20\n *** v1 debug| sizeof(struct smp_object) = 56 = 0x38\n *** v1 debug| CHK(0x7e2aa0 SILO 0x7ecf0000 ) = 1\n *** v1 debug| min_nseg = 10, max_segl = 622585\n *** v1 debug| max_nseg = 26212, min_segl = 237\n *** v1 debug| aim_nseg = 511, aim_segl = 12183\n *** v1 debug| aim_nobj = 155\n *** v1 debug| free_reserve = 121830\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-spersistent,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 5 *** v1 CLI RX 107 **** v1 CLI RX| gorpfxklhzhjofsoyedhsmhvwhdqaqch\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth ac6a2ef537271add5de2f1c034a2b69833a9976c9a58068863af2d8539e61e34\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"2207\"; }\n " *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 ** v1 Start **** v1 CLI TX| start *** v1 debug| child (4160) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (4160) said \n *** v1 debug| Child (4160) said Child starts\n *** v1 debug| Child (4160) said Silo completely loaded\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 2212\n ** v1 Listen on 127.0.0.1 2212 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=2212 **** v1 macro def v1_sock=127.0.0.1:2212 *** top client ** c1 Starting client *** c1 Connect to 127.0.0.1:2212 ** c1 Waiting for client *** c1 connected fd 8 *** c1 txreq **** c1 txreq| GET / HTTP/1.1\r\n **** c1 txreq| \r\n *** c1 rxresp *** s1 accepted fd 9 *** s1 rxreq **** s1 rxhdr| GET / HTTP/1.1\r\n **** s1 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 rxhdr| X-Varnish: 1001\r\n **** s1 rxhdr| Host: 127.0.0.1\r\n **** s1 rxhdr| \r\n **** s1 http[ 0] | GET **** s1 http[ 1] | / **** s1 http[ 2] | HTTP/1.1 **** s1 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 http[ 4] | X-Varnish: 1001 **** s1 http[ 5] | Host: 127.0.0.1 **** s1 bodylen = 0 *** s1 txresp **** s1 txresp| HTTP/1.1 200 Ok\r\n **** s1 txresp| Foo: foo\r\n **** s1 txresp| \r\n *** s1 shutting fd 9 **** s1 macro undef s1_addr **** s1 macro undef s1_port **** s1 macro undef s1_sock ** s1 Ending **** c1 rxhdr| HTTP/1.1 200 Ok\r\n **** c1 rxhdr| Foo: foo\r\n **** c1 rxhdr| Content-Length: 0\r\n **** c1 rxhdr| Date: Wed, 28 Jul 2010 18:53:18 GMT\r\n **** c1 rxhdr| X-Varnish: 1001\r\n **** c1 rxhdr| Age: 0\r\n **** c1 rxhdr| Via: 1.1 varnish\r\n **** c1 rxhdr| Connection: keep-alive\r\n **** c1 rxhdr| \r\n **** c1 http[ 0] | HTTP/1.1 **** c1 http[ 1] | 200 **** c1 http[ 2] | Ok **** c1 http[ 3] | Foo: foo **** c1 http[ 4] | Content-Length: 0 **** c1 http[ 5] | Date: Wed, 28 Jul 2010 18:53:18 GMT **** c1 http[ 6] | X-Varnish: 1001 **** c1 http[ 7] | Age: 0 **** c1 http[ 8] | Via: 1.1 varnish **** c1 http[ 9] | Connection: keep-alive **** c1 bodylen = 0 *** c1 expect **** c1 EXPECT resp.status (200) == 200 (200) match *** c1 expect **** c1 EXPECT resp.http.X-Varnish (1001) == 1001 (1001) match *** c1 expect **** c1 EXPECT resp.http.foo (foo) == foo (foo) match *** c1 closing fd 8 ** c1 Ending *** top varnish **** v1 CLI TX| purge req.url == / && req.http.jam != session *** v1 CLI RX 200 ** v1 CLI 200 *** top varnish **** v1 macro undef v1_addr **** v1 macro undef v1_port **** v1 macro undef v1_sock ** v1 Stop **** v1 CLI TX| stop *** v1 CLI RX 200 **** v1 CLI TX| status *** v1 debug| Stopping Child\n *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopping *** v1 debug| Child (4160) died\n *** v1 debug| Child (-1) said Child dies\n *** v1 debug| Child cleanup complete\n **** v1 CLI TX| status *** v1 CLI RX 200 **** v1 CLI RX| Child in state stopped *** top server ** s1 Waiting for server *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=2207 **** s1 macro def s1_sock=127.0.0.1:2207 * s1 Listen on 127.0.0.1:2207 *** top varnish ** v1 Start ** s1 Started on 127.0.0.1:2207 **** v1 CLI TX| start *** v1 debug| child (7656) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (7656) said \n *** v1 debug| Child (7656) said Child starts\n *** v1 debug| Child (7656) said Dropped 0 segments to make free_reserve\n *** v1 debug| Child (7656) said Silo completely loaded\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 2215\n ** v1 Listen on 127.0.0.1 2215 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=2215 **** v1 macro def v1_sock=127.0.0.1:2215 *** top varnish **** v1 CLI TX| purge.list *** v1 CLI RX 200 **** v1 CLI RX| 0x7f0ac0 1280343200.657758 0G\t\n **** v1 CLI RX| 0x7f0ce8 1280343199.009918 0 \treq.url == / && req.http.jam != session\n **** v1 CLI RX| 0x7f0c68 1280343197.759918 1G\t\n ** v1 CLI 200 *** top varnish ** v1 as expected: n_purge (3) == 3 * top RESETTING after ././tests/p00002.vtc ** s1 Waiting for server * top Test timed out * top TEST ././tests/p00002.vtc FAILED FAIL: ./tests/p00002.vtc # top TEST ././tests/p00003.vtc passed (9.812s) PASS: ./tests/p00003.vtc # top TEST ././tests/p00004.vtc passed (7.453s) PASS: ./tests/p00004.vtc # top TEST ././tests/p00005.vtc passed (14.921s) PASS: ./tests/p00005.vtc # top TEST ././tests/p00006.vtc passed (7.859s) PASS: ./tests/p00006.vtc # top TEST ././tests/r00102.vtc passed (5.984s) PASS: ./tests/r00102.vtc # top TEST ././tests/r00251.vtc passed (6.140s) PASS: ./tests/r00251.vtc # top TEST ././tests/r00255.vtc passed (5.687s) PASS: ./tests/r00255.vtc # top TEST ././tests/r00262.vtc passed (5.515s) PASS: ./tests/r00262.vtc # top TEST ././tests/r00263.vtc passed (5.765s) PASS: ./tests/r00263.vtc # top TEST ././tests/r00292.vtc passed (5.375s) PASS: ./tests/r00292.vtc # top TEST ././tests/r00306.vtc passed (5.234s) PASS: ./tests/r00306.vtc # top TEST ././tests/r00318.vtc passed (5.421s) PASS: ./tests/r00318.vtc # top TEST ././tests/r00325.vtc passed (5.594s) PASS: ./tests/r00325.vtc # top TEST ././tests/r00326.vtc passed (5.734s) PASS: ./tests/r00326.vtc # top TEST ././tests/r00345.vtc passed (6.531s) PASS: ./tests/r00345.vtc # top TEST ././tests/r00365.vtc passed (5.375s) PASS: ./tests/r00365.vtc # top TEST ././tests/r00386.vtc passed (5.484s) PASS: ./tests/r00386.vtc # top TEST ././tests/r00387.vtc passed (6.015s) PASS: ./tests/r00387.vtc # top TEST ././tests/r00400.vtc passed (5.390s) PASS: ./tests/r00400.vtc # top TEST ././tests/r00409.vtc passed (1.953s) PASS: ./tests/r00409.vtc # top TEST ././tests/r00412.vtc passed (5.437s) PASS: ./tests/r00412.vtc # top TEST ././tests/r00416.vtc passed (5.421s) PASS: ./tests/r00416.vtc # top TEST ././tests/r00425.vtc passed (5.515s) PASS: ./tests/r00425.vtc # top TEST ././tests/r00427.vtc passed (5.312s) PASS: ./tests/r00427.vtc # top TEST ././tests/r00433.vtc passed (5.421s) PASS: ./tests/r00433.vtc # top TEST ././tests/r00444.vtc passed (5.375s) PASS: ./tests/r00444.vtc # top TEST ././tests/r00445.vtc passed (5.375s) PASS: ./tests/r00445.vtc # top TEST ././tests/r00466.vtc passed (5.297s) PASS: ./tests/r00466.vtc # top TEST ././tests/r00476.vtc passed (5.328s) PASS: ./tests/r00476.vtc # top TEST ././tests/r00494.vtc passed (5.281s) PASS: ./tests/r00494.vtc # top TEST ././tests/r00495.vtc passed (5.515s) PASS: ./tests/r00495.vtc # top TEST ././tests/r00498.vtc passed (5.718s) PASS: ./tests/r00498.vtc # top TEST ././tests/r00502.vtc passed (5.437s) PASS: ./tests/r00502.vtc # top TEST ././tests/r00506.vtc passed (5.328s) PASS: ./tests/r00506.vtc # top TEST ././tests/r00524.vtc passed (5.203s) PASS: ./tests/r00524.vtc # top TEST ././tests/r00549.vtc passed (5.531s) PASS: ./tests/r00549.vtc **** top macro def tmpdir=/tmp/vtc.1336.2064cb63 **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/r00558.vtc starting *** top test * top TEST error from vcl_recv{} has no numeric code *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=2500 **** s1 macro def s1_sock=127.0.0.1:2500 * s1 Listen on 127.0.0.1:2500 *** top varnish ** s1 Started on 127.0.0.1:2500 ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.1336.2064cb63/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.1336.2064cb63/v1/_S -M 127.0.0.1:2501 -P /tmp/vtc.1336.2064cb63/v1/varnishd.pid -sfile,/tmp/vtc.1336.2064cb63/v1,10M *** v1 debug| storage_file: filename: /tmp/vtc.1336.2064cb63/v1/varnish.sppLEg size 10 MB.\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-sfile,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 5 *** v1 CLI RX 107 **** v1 CLI RX| zwamifmcwgdsahzayzojiidmginuvmzx\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth c60804c37f983322bba2a2e3b0816a12727a0c789772647b8d64bdf57599651b\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"2500\"; }\n\n\tsub vcl_recv {\n\t\treturn (error);\n\t}\n" *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 ** v1 Start **** v1 CLI TX| start *** v1 debug| child (2172) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (2172) said \n *** v1 debug| Child (2172) said Child starts\n *** v1 debug| Child (2172) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 2503\n ** v1 Listen on 127.0.0.1 2503 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=2503 **** v1 macro def v1_sock=127.0.0.1:2503 *** top client ** c1 Starting client *** c1 Connect to 127.0.0.1:2503 ** c1 Waiting for client *** c1 connected fd 8 *** c1 txreq **** c1 txreq| GET / HTTP/1.1\r\n **** c1 txreq| \r\n *** c1 rxresp **** c1 rxhdr| HTTP/1.1 501 Not Implemented\r\n **** c1 rxhdr| Server: Varnish\r\n **** c1 rxhdr| Retry-After: 0\r\n **** c1 rxhdr| Content-Type: text/html; charset=utf-8\r\n **** c1 rxhdr| Content-Length: 401\r\n **** c1 rxhdr| Date: Wed, 28 Jul 2010 18:57:47 GMT\r\n **** c1 rxhdr| X-Varnish: 1001\r\n **** c1 rxhdr| Age: 0\r\n **** c1 rxhdr| Via: 1.1 varnish\r\n **** c1 rxhdr| Connection: close\r\n **** c1 rxhdr| \r\n **** c1 http[ 0] | HTTP/1.1 **** c1 http[ 1] | 501 **** c1 http[ 2] | Not Implemented **** c1 http[ 3] | Server: Varnish **** c1 http[ 4] | Retry-After: 0 **** c1 http[ 5] | Content-Type: text/html; charset=utf-8 **** c1 http[ 6] | Content-Length: 401 **** c1 http[ 7] | Date: Wed, 28 Jul 2010 18:57:47 GMT **** c1 http[ 8] | X-Varnish: 1001 **** c1 http[ 9] | Age: 0 **** c1 http[10] | Via: 1.1 varnish **** c1 http[11] | Connection: close **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| \n **** c1 body| 501 Not Implemented\n **** c1 body| \n **** c1 body| \n **** c1 body|

Error 501 Not Implemented

\n **** c1 body|

Not Implemented

\n **** c1 body|

Guru Meditation:

\n **** c1 body|

XID: 1001

\n **** c1 body|
\n **** c1 body|

Varnish cache server

\n **** c1 body| \n **** c1 body| \n **** c1 bodylen = 401 *** c1 expect **** c1 EXPECT resp.status (501) == 501 (501) match *** c1 closing fd 8 ** c1 Ending * top RESETTING after ././tests/r00558.vtc ** s1 Waiting for server * top Test timed out * top TEST ././tests/r00558.vtc FAILED FAIL: ./tests/r00558.vtc # top TEST ././tests/r00561.vtc passed (5.890s) PASS: ./tests/r00561.vtc # top TEST ././tests/r00590.vtc passed (5.640s) PASS: ./tests/r00590.vtc # top TEST ././tests/r00612.vtc passed (5.312s) PASS: ./tests/r00612.vtc # top TEST ././tests/r00641.vtc passed (5.203s) PASS: ./tests/r00641.vtc # top TEST ././tests/r00655.vtc passed (1.906s) PASS: ./tests/r00655.vtc # top TEST ././tests/r00667.vtc passed (6.468s) PASS: ./tests/r00667.vtc # top TEST ././tests/r00679.vtc passed (5.625s) PASS: ./tests/r00679.vtc # top TEST ././tests/r00693.vtc passed (0.000s) PASS: ./tests/r00693.vtc # top TEST ././tests/r00694.vtc passed (10.546s) PASS: ./tests/r00694.vtc # top TEST ././tests/r00700.vtc passed (5.484s) PASS: ./tests/r00700.vtc # top TEST ././tests/r00702.vtc passed (5.359s) PASS: ./tests/r00702.vtc # top TEST ././tests/r00704.vtc passed (5.421s) PASS: ./tests/r00704.vtc # top TEST ././tests/r00722.vtc passed (7.406s) PASS: ./tests/r00722.vtc # top TEST ././tests/s00000.vtc passed (8.203s) PASS: ./tests/s00000.vtc # top TEST ././tests/s00001.vtc passed (6.468s) PASS: ./tests/s00001.vtc # top TEST ././tests/s00002.vtc passed (11.421s) PASS: ./tests/s00002.vtc # top TEST ././tests/s00003.vtc passed (9.609s) PASS: ./tests/s00003.vtc # top TEST ././tests/v00000.vtc passed (5.312s) PASS: ./tests/v00000.vtc # top TEST ././tests/v00001.vtc passed (5.812s) PASS: ./tests/v00001.vtc # top TEST ././tests/v00002.vtc passed (13.671s) PASS: ./tests/v00002.vtc # top TEST ././tests/v00003.vtc passed (5.171s) PASS: ./tests/v00003.vtc # top TEST ././tests/v00004.vtc passed (16.901s) PASS: ./tests/v00004.vtc # top TEST ././tests/v00005.vtc passed (7.843s) PASS: ./tests/v00005.vtc # top TEST ././tests/v00006.vtc passed (9.625s) PASS: ./tests/v00006.vtc # top TEST ././tests/v00007.vtc passed (5.625s) PASS: ./tests/v00007.vtc # top TEST ././tests/v00008.vtc passed (7.296s) PASS: ./tests/v00008.vtc bind(): Address already in use Assert error in server_start(), vtc_server.c line 183: Condition(s->sock >= 0) not true. errno = 112 (Address already in use) *** starting debugger for pid 7124, tid 6872 *** continuing pid 7124 from debugger call (1) /bin/sh: line 5: 960 Aborted (core dumped) ./varnishtest ${dir}$tst FAIL: ./tests/v00009.vtc # top TEST ././tests/v00010.vtc passed (7.875s) PASS: ./tests/v00010.vtc # top TEST ././tests/v00011.vtc passed (5.265s) PASS: ./tests/v00011.vtc # top TEST ././tests/v00012.vtc passed (5.390s) PASS: ./tests/v00012.vtc # top TEST ././tests/v00013.vtc passed (5.484s) PASS: ./tests/v00013.vtc # top TEST ././tests/v00014.vtc passed (7.218s) PASS: ./tests/v00014.vtc # top TEST ././tests/v00015.vtc passed (5.843s) PASS: ./tests/v00015.vtc # top TEST ././tests/v00016.vtc passed (10.421s) PASS: ./tests/v00016.vtc # top TEST ././tests/v00017.vtc passed (22.120s) PASS: ./tests/v00017.vtc # top TEST ././tests/v00018.vtc passed (18.198s) PASS: ./tests/v00018.vtc # top TEST ././tests/v00019.vtc passed (8.078s) PASS: ./tests/v00019.vtc # top TEST ././tests/v00020.vtc passed (5.734s) PASS: ./tests/v00020.vtc # top TEST ././tests/v00021.vtc passed (2.671s) PASS: ./tests/v00021.vtc # top TEST ././tests/v00022.vtc passed (5.484s) PASS: ./tests/v00022.vtc # top TEST ././tests/v00023.vtc passed (5.187s) PASS: ./tests/v00023.vtc # top TEST ././tests/v00024.vtc passed (5.703s) PASS: ./tests/v00024.vtc # top TEST ././tests/v00025.vtc passed (5.296s) PASS: ./tests/v00025.vtc # top TEST ././tests/v00026.vtc passed (5.328s) PASS: ./tests/v00026.vtc **** top macro def tmpdir=/tmp/vtc.3328.6b1e3ffc **** top macro def bad_ip=10.255.255.255 * top TEST ././tests/v00027.vtc starting *** top test * top TEST Check that backend named 'default' is the default *** top server ** s1 Starting server **** s1 macro def s1_addr=127.0.0.1 **** s1 macro def s1_port=2802 **** s1 macro def s1_sock=127.0.0.1:2802 * s1 Listen on 127.0.0.1:2802 *** top server ** s1 Started on 127.0.0.1:2802 ** s2 Starting server **** s2 macro def s2_addr=127.0.0.1 **** s2 macro def s2_port=2803 **** s2 macro def s2_sock=127.0.0.1:2803 * s2 Listen on 127.0.0.1:2803 *** top varnish ** s2 Started on 127.0.0.1:2803 ** v1 Launch *** v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.3328.6b1e3ffc/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tm p/vtc.3328.6b1e3ffc/v1/_S -M 127.0.0.1:2804 -P /tmp/vtc.3328.6b1e3ffc/v1/varnishd.pid -sfile,/tmp/vtc.3328.6b1e3ffc/v1,10M *** v1 debug| storage_file: filename: /tmp/vtc.3328.6b1e3ffc/v1/varnish.7n841a size 10 MB.\n *** v1 debug| Platform: CYGWIN_NT-5.1,1.7.5(0.225/5/3),i686,-sfile,-hcritbit\n *** v1 debug| 200 193 \n *** v1 debug| -----------------------------\n *** v1 debug| Varnish HTTP accelerator CLI.\n *** v1 debug| -----------------------------\n *** v1 debug| Type 'help' for command list.\n *** v1 debug| Type 'quit' to close CLI session.\n *** v1 debug| Type 'start' to launch worker process.\n *** v1 debug| \n *** v1 CLI connection fd = 6 *** v1 CLI RX 107 **** v1 CLI RX| esawihptchniltawisekwwfezmzaiwfm\n **** v1 CLI RX| \n **** v1 CLI RX| Authentication required.\n **** v1 CLI TX| auth c4c3972257471ab63bb3cd0aa99336f1eb2729185a5fd024d58ffc11ab447f89\n *** v1 CLI RX 200 **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Varnish HTTP accelerator CLI.\n **** v1 CLI RX| -----------------------------\n **** v1 CLI RX| Type 'help' for command list.\n **** v1 CLI RX| Type 'quit' to close CLI session.\n **** v1 CLI RX| Type 'start' to launch worker process.\n **** v1 CLI TX| vcl.inline vcl1 "\n\tbackend s1 {\n\t\t.host = \"127.0.0.1\"; \n\t\t.port = \"2802\";\n\t}\n\tbackend default {\n\t\t.host = \"127.0.0.1\";\n\ t\t.port = \"2803\";\n\t}\n\n\tsub vcl_recv {\n\t\tif (req.url != req.url) {\n\t\t\tset req.backend = s1;\n\t\t}\n\t}\n" *** v1 CLI RX 200 **** v1 CLI RX| VCL compiled. **** v1 CLI TX| vcl.use vcl1 *** v1 CLI RX 200 ** v1 Start **** v1 CLI TX| start *** v1 debug| child (6636) Started\n *** v1 CLI RX 200 **** v1 CLI TX| debug.xid 1000 *** v1 debug| Child (6636) said \n *** v1 debug| Child (6636) said Child starts\n *** v1 debug| Child (6636) said managed to mmap 10485760 bytes of 10485760\n *** v1 CLI RX 200 **** v1 CLI RX| XID is 1000 **** v1 CLI TX| debug.listen_address *** v1 CLI RX 200 **** v1 CLI RX| 127.0.0.1 2806\n ** v1 Listen on 127.0.0.1 2806 **** v1 macro def v1_addr=127.0.0.1 **** v1 macro def v1_port=2806 **** v1 macro def v1_sock=127.0.0.1:2806 *** top client ** c1 Starting client ** c1 Waiting for client *** c1 Connect to 127.0.0.1:2806 *** c1 connected fd 9 *** c1 txreq **** c1 txreq| GET / HTTP/1.1\r\n **** c1 txreq| \r\n *** c1 rxresp *** s2 accepted fd 10 *** s2 rxreq **** s2 rxhdr| GET / HTTP/1.1\r\n **** s2 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s2 rxhdr| X-Varnish: 1001\r\n **** s2 rxhdr| Host: 127.0.0.1\r\n **** s2 rxhdr| \r\n **** s2 http[ 0] | GET **** s2 http[ 1] | / **** s2 http[ 2] | HTTP/1.1 **** s2 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s2 http[ 4] | X-Varnish: 1001 **** s2 http[ 5] | Host: 127.0.0.1 **** s2 bodylen = 0 *** s2 txresp **** s2 txresp| HTTP/1.1 200 Ok\r\n **** s2 txresp| Content-Length: 52\r\n **** s2 txresp| \r\n **** s2 txresp| !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRS\n *** s2 shutting fd 10 **** s2 macro undef s2_addr **** s2 macro undef s2_port **** s2 macro undef s2_sock ** s2 Ending **** c1 rxhdr| HTTP/1.1 200 Ok\r\n **** c1 rxhdr| Content-Length: 52\r\n **** c1 rxhdr| Date: Wed, 28 Jul 2010 19:04:13 GMT\r\n **** c1 rxhdr| X-Varnish: 1001\r\n **** c1 rxhdr| Age: 0\r\n **** c1 rxhdr| Via: 1.1 varnish\r\n **** c1 rxhdr| Connection: keep-alive\r\n **** c1 rxhdr| \r\n **** c1 http[ 0] | HTTP/1.1 **** c1 http[ 1] | 200 **** c1 http[ 2] | Ok **** c1 http[ 3] | Content-Length: 52 **** c1 http[ 4] | Date: Wed, 28 Jul 2010 19:04:13 GMT **** c1 http[ 5] | X-Varnish: 1001 **** c1 http[ 6] | Age: 0 **** c1 http[ 7] | Via: 1.1 varnish **** c1 http[ 8] | Connection: keep-alive **** c1 body| !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRS\n **** c1 bodylen = 52 *** c1 expect **** c1 EXPECT resp.bodylen (52) == 52 (52) match *** c1 closing fd 9 ** c1 Ending * top RESETTING after ././tests/v00027.vtc ** s1 Waiting for server * top Test timed out * top TEST ././tests/v00027.vtc FAILED FAIL: ./tests/v00027.vtc ============================================== 8 of 183 tests failed Please report to varnish-dev at varnish-cache.org ============================================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/tmp/varnish-cache/bin/varnishtest' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/tmp/varnish-cache/bin/varnishtest' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/varnish-cache/bin' make: *** [check-recursive] Error 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: cygwin_changes_r_5048.zip Type: application/zip Size: 12715 bytes Desc: not available URL: From joec1502 at gmail.com Fri Jul 30 21:20:58 2010 From: joec1502 at gmail.com (Joe Chen) Date: Fri, 30 Jul 2010 15:20:58 -0600 Subject: Adding a new feature to Update Current Backend in VCL Message-ID: Hi, I have a question about modifying and adding some C code to update a current backend structure with new hostname and port number. Background: I am trying to add a feature of using VCL to update the current Backend with the new host and port returned from a fetch status 302. My VCL section looks like this: sub vcl_fetch { if (beresp.status == 302) { set req.url = beresp.http.ocation; set req.backend.hostport = beresp.http.location; # new syntac introduced here restart; } } My added Function: After adding an entry in the TCL file, and adding a function VRT_l_req.backend_hostport(), now my modified Varnish can parse the newly introduced syntax line and call the right function. Inside the function, I was able to extract the new hostname and port number. My Question: What's the best way to do the coding so the current Backend data structure has the new hostname and port number, and the subsequent opening socket will connect to the new host? I believe that inside the new function, the session pointer is supplied and then I can get access to a director through sp->director. and from there I can get access to the current backend data structure. Any help would be appreciated, --Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssm at redpill-linpro.com Sat Jul 31 15:50:07 2010 From: ssm at redpill-linpro.com (Stig Sandbeck Mathisen) Date: Sat, 31 Jul 2010 17:50:07 +0200 Subject: Varnish 2.1.3 buildd reports, build/test failures on some platforms Message-ID: <87iq3ssf29.fsf@mavis.fnord.no> I've uploaded the new varnish 2.1.3 to Debian, and as of this version I've enabled (or rather, stopped disabling) testing during the build. The root of the buildd information for varnish is at: https://buildd.debian.org/pkg.cgi?pkg=varnish The following kernels/architectures had no problem: Linux: alpha, amd64, i386, mips, mipsel, powerpc, s390 kFreeBSD: kfreebsd-amd64, kfreebsd-i386 The GNU Hurd build did not come very far: GNU Hurd, i386 https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=hurd-i386;stamp=1280475581 The following experienced problems with the tests: Linux, armel: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=armel;stamp=1280477633 19 tests failed, same tests as on the "sparc" build" FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00612.vtc Linux, sparc: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=sparc;stamp=1280443006 19 tests failed, same tests as on the "armel" build. FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00612.vtc Linux, hppa: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=hppa;stamp=1280447024 30 tests failed FAIL: ./tests/b00001.vtc FAIL: ./tests/b00011.vtc FAIL: ./tests/b00029.vtc FAIL: ./tests/c00003.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/c00008.vtc FAIL: ./tests/c00011.vtc FAIL: ./tests/c00013.vtc FAIL: ./tests/c00014.vtc FAIL: ./tests/c00019.vtc FAIL: ./tests/c00021.vtc FAIL: ./tests/c00023.vtc FAIL: ./tests/c00024.vtc FAIL: ./tests/c00027.vtc FAIL: ./tests/c00029.vtc FAIL: ./tests/e00001.vtc FAIL: ./tests/e00003.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00009.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00013.vtc FAIL: ./tests/r00262.vtc FAIL: ./tests/r00318.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00466.vtc FAIL: ./tests/r00704.vtc FAIL: ./tests/v00011.vtc FAIL: ./tests/v00013.vtc FAIL: ./tests/v00026.vtc Linux, ia64: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=ia64;stamp=1280447652 169 tests failed, something funky indeed here.... FAIL: ./tests/a00009.vtc FAIL: ./tests/b00000.vtc FAIL: ./tests/b00001.vtc FAIL: ./tests/b00002.vtc FAIL: ./tests/b00003.vtc FAIL: ./tests/b00004.vtc FAIL: ./tests/b00005.vtc FAIL: ./tests/b00006.vtc FAIL: ./tests/b00007.vtc FAIL: ./tests/b00008.vtc FAIL: ./tests/b00009.vtc FAIL: ./tests/b00010.vtc FAIL: ./tests/b00011.vtc FAIL: ./tests/b00012.vtc FAIL: ./tests/b00013.vtc FAIL: ./tests/b00014.vtc FAIL: ./tests/b00015.vtc FAIL: ./tests/b00016.vtc FAIL: ./tests/b00017.vtc FAIL: ./tests/b00018.vtc FAIL: ./tests/b00019.vtc FAIL: ./tests/b00020.vtc FAIL: ./tests/b00021.vtc FAIL: ./tests/b00022.vtc FAIL: ./tests/b00023.vtc FAIL: ./tests/b00024.vtc FAIL: ./tests/b00025.vtc FAIL: ./tests/b00026.vtc FAIL: ./tests/b00027.vtc FAIL: ./tests/b00028.vtc FAIL: ./tests/b00029.vtc FAIL: ./tests/b00030.vtc FAIL: ./tests/b00031.vtc FAIL: ./tests/b00033.vtc FAIL: ./tests/c00001.vtc FAIL: ./tests/c00002.vtc FAIL: ./tests/c00003.vtc FAIL: ./tests/c00004.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/c00006.vtc FAIL: ./tests/c00007.vtc FAIL: ./tests/c00008.vtc FAIL: ./tests/c00009.vtc FAIL: ./tests/c00010.vtc FAIL: ./tests/c00011.vtc FAIL: ./tests/c00012.vtc FAIL: ./tests/c00013.vtc FAIL: ./tests/c00014.vtc FAIL: ./tests/c00015.vtc FAIL: ./tests/c00016.vtc FAIL: ./tests/c00017.vtc FAIL: ./tests/c00018.vtc FAIL: ./tests/c00019.vtc FAIL: ./tests/c00020.vtc FAIL: ./tests/c00021.vtc FAIL: ./tests/c00022.vtc FAIL: ./tests/c00023.vtc FAIL: ./tests/c00024.vtc FAIL: ./tests/c00025.vtc FAIL: ./tests/c00026.vtc FAIL: ./tests/c00027.vtc FAIL: ./tests/c00028.vtc FAIL: ./tests/c00029.vtc FAIL: ./tests/c00030.vtc FAIL: ./tests/c00031.vtc FAIL: ./tests/c00033.vtc FAIL: ./tests/c00034.vtc FAIL: ./tests/e00000.vtc FAIL: ./tests/e00001.vtc FAIL: ./tests/e00002.vtc FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00007.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00009.vtc FAIL: ./tests/e00010.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00013.vtc FAIL: ./tests/e00014.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/p00000.vtc FAIL: ./tests/p00001.vtc FAIL: ./tests/p00002.vtc FAIL: ./tests/p00003.vtc FAIL: ./tests/p00004.vtc FAIL: ./tests/p00005.vtc FAIL: ./tests/p00006.vtc FAIL: ./tests/r00102.vtc FAIL: ./tests/r00251.vtc FAIL: ./tests/r00255.vtc FAIL: ./tests/r00262.vtc FAIL: ./tests/r00263.vtc FAIL: ./tests/r00292.vtc FAIL: ./tests/r00306.vtc FAIL: ./tests/r00318.vtc FAIL: ./tests/r00325.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00345.vtc FAIL: ./tests/r00365.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00387.vtc FAIL: ./tests/r00400.vtc FAIL: ./tests/r00409.vtc FAIL: ./tests/r00412.vtc FAIL: ./tests/r00416.vtc FAIL: ./tests/r00425.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00444.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00466.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00494.vtc FAIL: ./tests/r00495.vtc FAIL: ./tests/r00498.vtc FAIL: ./tests/r00502.vtc FAIL: ./tests/r00506.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00549.vtc FAIL: ./tests/r00558.vtc FAIL: ./tests/r00561.vtc FAIL: ./tests/r00590.vtc FAIL: ./tests/r00612.vtc FAIL: ./tests/r00641.vtc FAIL: ./tests/r00655.vtc FAIL: ./tests/r00667.vtc FAIL: ./tests/r00679.vtc FAIL: ./tests/r00694.vtc FAIL: ./tests/r00700.vtc FAIL: ./tests/r00702.vtc FAIL: ./tests/r00704.vtc FAIL: ./tests/r00722.vtc FAIL: ./tests/s00000.vtc FAIL: ./tests/s00001.vtc FAIL: ./tests/s00002.vtc FAIL: ./tests/s00003.vtc FAIL: ./tests/v00000.vtc FAIL: ./tests/v00001.vtc FAIL: ./tests/v00002.vtc FAIL: ./tests/v00003.vtc FAIL: ./tests/v00004.vtc FAIL: ./tests/v00005.vtc FAIL: ./tests/v00006.vtc FAIL: ./tests/v00007.vtc FAIL: ./tests/v00008.vtc FAIL: ./tests/v00009.vtc FAIL: ./tests/v00010.vtc FAIL: ./tests/v00011.vtc FAIL: ./tests/v00012.vtc FAIL: ./tests/v00013.vtc FAIL: ./tests/v00014.vtc FAIL: ./tests/v00015.vtc FAIL: ./tests/v00016.vtc FAIL: ./tests/v00017.vtc FAIL: ./tests/v00018.vtc FAIL: ./tests/v00019.vtc FAIL: ./tests/v00020.vtc FAIL: ./tests/v00021.vtc FAIL: ./tests/v00022.vtc FAIL: ./tests/v00023.vtc FAIL: ./tests/v00024.vtc FAIL: ./tests/v00025.vtc FAIL: ./tests/v00026.vtc -- Stig Sandbeck Mathisen ooo, shiny! From ssm at debian.org Sat Jul 31 15:50:25 2010 From: ssm at debian.org (Stig Sandbeck Mathisen) Date: Sat, 31 Jul 2010 15:50:25 -0000 Subject: Varnish 2.1.3 buildd reports, build/test failures on some platforms Message-ID: <871vajtzv4.fsf@mavis.fnord.no> I've uploaded the new varnish 2.1.3 to Debian, and as of this version I've enabled (or rather, stopped disabling) testing during the build. The root of the buildd information for varnish is at: https://buildd.debian.org/pkg.cgi?pkg=varnish The following kernels/architectures had no problem: Linux: alpha, amd64, i386, mips, mipsel, powerpc, s390 kFreeBSD: kfreebsd-amd64, kfreebsd-i386 The GNU Hurd build did not come very far: GNU Hurd, i386 https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=hurd-i386;stamp=1280475581 The following experienced problems with the tests: Linux, armel: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=armel;stamp=1280477633 19 tests failed, same tests as on the "sparc" build" FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00612.vtc Linux, sparc: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=sparc;stamp=1280443006 19 tests failed, same tests as on the "armel" build. FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00612.vtc Linux, hppa: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=hppa;stamp=1280447024 30 tests failed FAIL: ./tests/b00001.vtc FAIL: ./tests/b00011.vtc FAIL: ./tests/b00029.vtc FAIL: ./tests/c00003.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/c00008.vtc FAIL: ./tests/c00011.vtc FAIL: ./tests/c00013.vtc FAIL: ./tests/c00014.vtc FAIL: ./tests/c00019.vtc FAIL: ./tests/c00021.vtc FAIL: ./tests/c00023.vtc FAIL: ./tests/c00024.vtc FAIL: ./tests/c00027.vtc FAIL: ./tests/c00029.vtc FAIL: ./tests/e00001.vtc FAIL: ./tests/e00003.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00009.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00013.vtc FAIL: ./tests/r00262.vtc FAIL: ./tests/r00318.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00466.vtc FAIL: ./tests/r00704.vtc FAIL: ./tests/v00011.vtc FAIL: ./tests/v00013.vtc FAIL: ./tests/v00026.vtc Linux, ia64: https://buildd.debian.org/fetch.cgi?pkg=varnish;ver=2.1.3-2;arch=ia64;stamp=1280447652 169 tests failed, something funky indeed here.... FAIL: ./tests/a00009.vtc FAIL: ./tests/b00000.vtc FAIL: ./tests/b00001.vtc FAIL: ./tests/b00002.vtc FAIL: ./tests/b00003.vtc FAIL: ./tests/b00004.vtc FAIL: ./tests/b00005.vtc FAIL: ./tests/b00006.vtc FAIL: ./tests/b00007.vtc FAIL: ./tests/b00008.vtc FAIL: ./tests/b00009.vtc FAIL: ./tests/b00010.vtc FAIL: ./tests/b00011.vtc FAIL: ./tests/b00012.vtc FAIL: ./tests/b00013.vtc FAIL: ./tests/b00014.vtc FAIL: ./tests/b00015.vtc FAIL: ./tests/b00016.vtc FAIL: ./tests/b00017.vtc FAIL: ./tests/b00018.vtc FAIL: ./tests/b00019.vtc FAIL: ./tests/b00020.vtc FAIL: ./tests/b00021.vtc FAIL: ./tests/b00022.vtc FAIL: ./tests/b00023.vtc FAIL: ./tests/b00024.vtc FAIL: ./tests/b00025.vtc FAIL: ./tests/b00026.vtc FAIL: ./tests/b00027.vtc FAIL: ./tests/b00028.vtc FAIL: ./tests/b00029.vtc FAIL: ./tests/b00030.vtc FAIL: ./tests/b00031.vtc FAIL: ./tests/b00033.vtc FAIL: ./tests/c00001.vtc FAIL: ./tests/c00002.vtc FAIL: ./tests/c00003.vtc FAIL: ./tests/c00004.vtc FAIL: ./tests/c00005.vtc FAIL: ./tests/c00006.vtc FAIL: ./tests/c00007.vtc FAIL: ./tests/c00008.vtc FAIL: ./tests/c00009.vtc FAIL: ./tests/c00010.vtc FAIL: ./tests/c00011.vtc FAIL: ./tests/c00012.vtc FAIL: ./tests/c00013.vtc FAIL: ./tests/c00014.vtc FAIL: ./tests/c00015.vtc FAIL: ./tests/c00016.vtc FAIL: ./tests/c00017.vtc FAIL: ./tests/c00018.vtc FAIL: ./tests/c00019.vtc FAIL: ./tests/c00020.vtc FAIL: ./tests/c00021.vtc FAIL: ./tests/c00022.vtc FAIL: ./tests/c00023.vtc FAIL: ./tests/c00024.vtc FAIL: ./tests/c00025.vtc FAIL: ./tests/c00026.vtc FAIL: ./tests/c00027.vtc FAIL: ./tests/c00028.vtc FAIL: ./tests/c00029.vtc FAIL: ./tests/c00030.vtc FAIL: ./tests/c00031.vtc FAIL: ./tests/c00033.vtc FAIL: ./tests/c00034.vtc FAIL: ./tests/e00000.vtc FAIL: ./tests/e00001.vtc FAIL: ./tests/e00002.vtc FAIL: ./tests/e00003.vtc FAIL: ./tests/e00004.vtc FAIL: ./tests/e00005.vtc FAIL: ./tests/e00006.vtc FAIL: ./tests/e00007.vtc FAIL: ./tests/e00008.vtc FAIL: ./tests/e00009.vtc FAIL: ./tests/e00010.vtc FAIL: ./tests/e00011.vtc FAIL: ./tests/e00012.vtc FAIL: ./tests/e00013.vtc FAIL: ./tests/e00014.vtc FAIL: ./tests/e00015.vtc FAIL: ./tests/e00016.vtc FAIL: ./tests/e00017.vtc FAIL: ./tests/e00018.vtc FAIL: ./tests/p00000.vtc FAIL: ./tests/p00001.vtc FAIL: ./tests/p00002.vtc FAIL: ./tests/p00003.vtc FAIL: ./tests/p00004.vtc FAIL: ./tests/p00005.vtc FAIL: ./tests/p00006.vtc FAIL: ./tests/r00102.vtc FAIL: ./tests/r00251.vtc FAIL: ./tests/r00255.vtc FAIL: ./tests/r00262.vtc FAIL: ./tests/r00263.vtc FAIL: ./tests/r00292.vtc FAIL: ./tests/r00306.vtc FAIL: ./tests/r00318.vtc FAIL: ./tests/r00325.vtc FAIL: ./tests/r00326.vtc FAIL: ./tests/r00345.vtc FAIL: ./tests/r00365.vtc FAIL: ./tests/r00386.vtc FAIL: ./tests/r00387.vtc FAIL: ./tests/r00400.vtc FAIL: ./tests/r00409.vtc FAIL: ./tests/r00412.vtc FAIL: ./tests/r00416.vtc FAIL: ./tests/r00425.vtc FAIL: ./tests/r00427.vtc FAIL: ./tests/r00433.vtc FAIL: ./tests/r00444.vtc FAIL: ./tests/r00445.vtc FAIL: ./tests/r00466.vtc FAIL: ./tests/r00476.vtc FAIL: ./tests/r00494.vtc FAIL: ./tests/r00495.vtc FAIL: ./tests/r00498.vtc FAIL: ./tests/r00502.vtc FAIL: ./tests/r00506.vtc FAIL: ./tests/r00524.vtc FAIL: ./tests/r00549.vtc FAIL: ./tests/r00558.vtc FAIL: ./tests/r00561.vtc FAIL: ./tests/r00590.vtc FAIL: ./tests/r00612.vtc FAIL: ./tests/r00641.vtc FAIL: ./tests/r00655.vtc FAIL: ./tests/r00667.vtc FAIL: ./tests/r00679.vtc FAIL: ./tests/r00694.vtc FAIL: ./tests/r00700.vtc FAIL: ./tests/r00702.vtc FAIL: ./tests/r00704.vtc FAIL: ./tests/r00722.vtc FAIL: ./tests/s00000.vtc FAIL: ./tests/s00001.vtc FAIL: ./tests/s00002.vtc FAIL: ./tests/s00003.vtc FAIL: ./tests/v00000.vtc FAIL: ./tests/v00001.vtc FAIL: ./tests/v00002.vtc FAIL: ./tests/v00003.vtc FAIL: ./tests/v00004.vtc FAIL: ./tests/v00005.vtc FAIL: ./tests/v00006.vtc FAIL: ./tests/v00007.vtc FAIL: ./tests/v00008.vtc FAIL: ./tests/v00009.vtc FAIL: ./tests/v00010.vtc FAIL: ./tests/v00011.vtc FAIL: ./tests/v00012.vtc FAIL: ./tests/v00013.vtc FAIL: ./tests/v00014.vtc FAIL: ./tests/v00015.vtc FAIL: ./tests/v00016.vtc FAIL: ./tests/v00017.vtc FAIL: ./tests/v00018.vtc FAIL: ./tests/v00019.vtc FAIL: ./tests/v00020.vtc FAIL: ./tests/v00021.vtc FAIL: ./tests/v00022.vtc FAIL: ./tests/v00023.vtc FAIL: ./tests/v00024.vtc FAIL: ./tests/v00025.vtc FAIL: ./tests/v00026.vtc -- Stig Sandbeck Mathisen ooo, shiny! From jim at bonetruck.org Thu Jul 1 00:10:07 2010 From: jim at bonetruck.org (Jim Razmus) Date: Thu, 01 Jul 2010 00:10:07 -0000 Subject: Make Test Mostly Fails Although Varnishd Works Message-ID: <20100701000953.GQ6085@mail.bonetruck.org> Attached log file contains the output from "make check". Is there anything else I can provide that may be helpful for diagnostic purposes? Note this is the result of a build on OpenBSD -current amd64. Best regards, jim -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish.log.gz Type: application/x-gunzip Size: 11800 bytes Desc: not available URL: From eran at sandler.co.il Wed Jul 28 07:22:47 2010 From: eran at sandler.co.il (Eran Sandler) Date: Wed, 28 Jul 2010 07:22:47 -0000 Subject: Retries after X amount of time Message-ID: Hello all, Is it possible to have Varnish retry another backend if a certain backend doesn't response after a certain timeout when using a director? If I understand correctly, the .retries option in the random director is used to find a healthy director and doesn't account of a request to a certain director that died after a timeout. Is it a correct statement? Thanks, Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: