From ssm at linpro.no  Fri Feb  1 11:14:16 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Fri, 01 Feb 2008 12:14:16 +0100
Subject: Not caching immediately?
In-Reply-To: <2c7df3ed0801311514h1faa5f1dq573ce0ef5a193421@mail.gmail.com>
	(Aaron Pfeifer's message of "Thu, 31 Jan 2008 18:14:24 -0500")
References: <2c7df3ed0801311348t759eb02eyf7cb5cfaaf567d3f@mail.gmail.com>
	<2c7df3ed0801311514h1faa5f1dq573ce0ef5a193421@mail.gmail.com>
Message-ID: <7xir19lyif.fsf@iostat.linpro.no>

"Aaron Pfeifer" <aaron.pfeifer at gmail.com> writes:

> (1) Upgrade to trunk (I was using 1.1.2)

May not be the best choice for all, I think

> (2) Add "set req.http.connection = "close";" immediately before the
> pipe for a POST

Would this be an appropriate config snippet?

vcl_pipe {
  set req.http.connection = "close";
}

-- 
Stig Sandbeck Mathisen, Linpro


From aaron.pfeifer at gmail.com  Fri Feb  1 19:09:57 2008
From: aaron.pfeifer at gmail.com (Aaron Pfeifer)
Date: Fri, 1 Feb 2008 14:09:57 -0500
Subject: Not caching immediately?
In-Reply-To: <7xir19lyif.fsf@iostat.linpro.no>
References: <2c7df3ed0801311348t759eb02eyf7cb5cfaaf567d3f@mail.gmail.com>
	<2c7df3ed0801311514h1faa5f1dq573ce0ef5a193421@mail.gmail.com>
	<7xir19lyif.fsf@iostat.linpro.no>
Message-ID: <2c7df3ed0802011109r46918505y31ee48233b21dcdf@mail.gmail.com>

Good question.  I actually tried that and it didn't seem to have the same
effect.  I didn't try diving into why it wouldn't have the same effect as
the config I'm currently using:

sub vcl_recv {
  ...stuff to determine whether to lookup...

  if (req.request == "POST") {
    set req.http.connection = "close";
    pipe;
  }
}

On Feb 1, 2008 6:14 AM, Stig Sandbeck Mathisen <ssm at linpro.no> wrote:

> "Aaron Pfeifer" <aaron.pfeifer at gmail.com> writes:
>
> > (1) Upgrade to trunk (I was using 1.1.2)
>
> May not be the best choice for all, I think
>
> > (2) Add "set req.http.connection = "close";" immediately before the
> > pipe for a POST
>
> Would this be an appropriate config snippet?
>
> vcl_pipe {
>  set req.http.connection = "close";
> }
>
> --
> Stig Sandbeck Mathisen, Linpro
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080201/33c8a0d3/attachment.html>

From ric at digitalmarbles.com  Sun Feb  3 06:10:12 2008
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Sat, 2 Feb 2008 22:10:12 -0800
Subject: hash with Accept-Encoding
Message-ID: <56F36529-29BF-417F-B314-6C72127751EA@digitalmarbles.com>


I came across this line in an example vcl which confused me...

sub vcl_hash {
     set req.hash += req.http.Accept-Encoding;
}


This line seemed superfluous to me since it was my impression that  
varnish already took care of this automatically as long as the Vary  
header was set correctly.  Is this not the case?

Ric




From phk at phk.freebsd.dk  Sun Feb  3 08:38:06 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 03 Feb 2008 08:38:06 +0000
Subject: hash with Accept-Encoding 
In-Reply-To: Your message of "Sat, 02 Feb 2008 22:10:12 PST."
	<56F36529-29BF-417F-B314-6C72127751EA@digitalmarbles.com> 
Message-ID: <14403.1202027886@critter.freebsd.dk>

In message <56F36529-29BF-417F-B314-6C72127751EA at digitalmarbles.com>, Ricardo N
ewbery writes:
>
>I came across this line in an example vcl which confused me...
>
>sub vcl_hash {
>     set req.hash += req.http.Accept-Encoding;
>}
>
>
>This line seemed superfluous to me since it was my impression that  
>varnish already took care of this automatically as long as the Vary  
>header was set correctly.  Is this not the case?

Correct.

-- 
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 rhermon at chicagosuntimes.com  Tue Feb  5 17:42:50 2008
From: rhermon at chicagosuntimes.com (Ramon A Hermon)
Date: Tue, 05 Feb 2008 11:42:50 -0600
Subject: error page not delivered
Message-ID: <47A8A01A.3030900@chicagosuntimes.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am unable to get varnish to deliver the customized error page when
requesting a non-existent url.
For instance:
If I request http://mysite/xyz ( request to
http://mysite/xyz/notthere.html also fails) results in a blank page.

apache error.log =
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(129): Adding CACHE_SAVE
filter for /xyz/
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(136): Adding
CACHE_REMOVE_URL filter for /xyz/
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(509): cache: /xyz/ not
cached. Reason: Response status 302
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(129): Adding CACHE_SAVE
filter for /xyz/index.html
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(136): Adding
CACHE_REMOVE_URL filter for /xyz/index.html
[Tue Feb 05 10:54:42 2008] [debug] mod_cache.c(509): cache:
/xyz/index.html not cached. Reason: Response status 404

apache access.log =
192.168.130.6 - - [05/Feb/2008:10:54:42 -0600] "GET /xyz/ HTTP/1.1" 302
- - "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like
Gecko)"
192.168.130.6 - - [05/Feb/2008:10:54:42 -0600] "GET /xyz/index.html
HTTP/1.1" 404 450 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux)
KHTML/3.5.8 (like Gecko)"



in contrast: http://mysite/xyz/index.htm results in the proper error
page being displayed.

apache error.log =
[Tue Feb 05 10:58:12 2008] [debug] mod_cache.c(129): Adding CACHE_SAVE
filter for /xyz/index.htm
[Tue Feb 05 10:58:12 2008] [debug] mod_cache.c(136): Adding
CACHE_REMOVE_URL filter for /xyz/index.htm
[Tue Feb 05 10:58:14 2008] [debug] mod_cache.c(509): cache:
/xyz/index.htm not cached. Reason: Response status 404

apache access.log =
192.168.130.6 - - [05/Feb/2008:10:58:12 -0600] "GET /xyz/index.htm
HTTP/1.1" 404 450 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux)
KHTML/3.5.8 (like Gecko)"


All test are successful w/o Varnish and going straight to apache. Any
ideas will be greatly appreciated.

Regards,
Ramon A Hermon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqKAa2nBs00uoHhwRAqsqAJ9nz165J7w3xF1xyUa2T0TZxHNAcQCfTR9T
EqFW1XhGrn+tnqY9ydAEBFE=
=MqYZ
-----END PGP SIGNATURE-----



From janis.putrams at delfi.lv  Wed Feb  6 13:29:43 2008
From: janis.putrams at delfi.lv (Janis Putrams)
Date: Wed, 6 Feb 2008 15:29:43 +0200
Subject: Assert error in exp_hangman()
Message-ID: <200802061529.44110.janis.putrams@delfi.lv>

Hi!

Child dies from time to time. Is there a solution to this?

15:35:04 root[pts/2]@slow ~# varnishd -V
varnishd (varnish-1.1.2)

...
Child said (2, 28732): <<Assert error in exp_hangman(), cache_expire.c line 
113:
  Condition((o)->magic == 0x32851d42) not true.
  errno = 0 (Success)
>>
Cache child died pid=28732 status=0x86
Clean child
...

Thanks,
Janis Putrams


From marco.molinari at gmail.com  Thu Feb  7 15:30:53 2008
From: marco.molinari at gmail.com (Marco Molinari)
Date: Thu, 7 Feb 2008 16:30:53 +0100
Subject: A few users see a blank page
In-Reply-To: <47A91407.5000703@openplans.org>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
Message-ID: <e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>

On Feb 6, 2008 2:57 AM, Arne Kepp <ak at openplans.org> wrote:
> (Maybe this should be on -misc ?)

Ok, moved.

Thank you for your reply. I'm using PHP and I had it gzip'ing, then I
tried to use mod_deflate, but they're reporting the problem anyway.

But I think the problem is similar. In fact, thanks to a user, I did
some tests and I discovered that:
- they can see static content, even html, any length
- they can see content generated by PHP if it's smaller than 7500 bytes
- they get a blank page if PHP output is more than 8000 bytes
- they see everything if the accelerator is Squid

I disabled compression during these tests. Maybe your users see a
blank page just sometimes, when they request a page that, compressed,
is larger than 7500/8000 bytes?

Sorry I don't have a precise number, but I didn't want to stress my
user too much, but I suppose I can work that out.

I can't replicate this myself; I tried to use Squid (even different
versions) on the client side, to replicate their setup, but I just see
everything.

My VCL is quite simple, too, lookup for images/css and pipe/pass for
everything else.

Any idea of what's happening? What can I do to find more clues?

Thanks
Marco




> I've seen one odd (to me) problem like this that I was able to reproduce
> consistently, thanks to the help of a user. If you are serving PHP, and
> PHP is gzip'ing the output then clients behind a Squid proxy (on their
> end) only get blank pages.
>
> Squid records something like "TCP_MISS/200 416 GET <script name>? -
> DIRECT/<ip address> text/html" in the logs, but doesn't appear to get
> the page.
>
> Moving gzip compression from PHP to Apache solved this particular
> problem, but I still have users reporting blank pages every now and
> then. I've been accused of blocking all sorts of clients for this reason.
>
> My VCL file is simple, it's the standard logic + lookup for image and
> css extensions and pass for everything else (also tried pipe).
>
> -Arne
>
>
> Marco Molinari wrote:
> > Hi,
> > I recently deployed Varnish and its performance is simply incredible.
> > I'm having a problem, though, which made me jump back to Squid. In the
> > week I used Varnish I had some users mailing me that they couldn't see
> > the site anymore, they just saw a blank page.
> > It seems this affects a small percentage of the users, as I got just
> > about 10 emails in a week and my users are in the 10000s, and in fact
> > I didn't notice any problem in the stats; so I setup two servers, one
> > with Squid and the other with Varnish, and the affected users see the
> > site only through Squid.
> >
> > I'm trying to understand what's happening and with the help of some
> > users here's what I discovered:
> > - every user who has problems connects from an office (completely
> > different places, of course)
> > - at least one user connects via a proxy (she has a header that says
> > "Via: 1.1 SRVFW1")
> > - Apache serves the page, which is logged with the correct size
> > - they can see very small pages (a test I did just printed "Thanks " +
> > the timestamp)
> >
> > This happens both with 1.1.2 and trunk.
> >
> > On standard log files I can't find anything, I couldn't even know it
> > was happening if those users didn't email me. I'd like to have more
> > data before submitting a bug report; do you have any suggestion on how
> > and what I could collect?
> >
> > Thanks
> > Marco Molinari
> > _______________________________________________
> > varnish-dev mailing list
> > varnish-dev at projects.linpro.no
> > http://projects.linpro.no/mailman/listinfo/varnish-dev
> >
> > !DSPAM:4038,47a7621398828992556831!
> >
> >
>
>


From daviddebeer at gmail.com  Sun Feb 10 14:39:01 2008
From: daviddebeer at gmail.com (David de Beer)
Date: Sun, 10 Feb 2008 16:39:01 +0200
Subject: Fetch from Socks server.
Message-ID: <d01483560802100639o5dc495c6h82a4229c81736eb3@mail.gmail.com>

Greetings,

I have not been able to find any info on this subject: Is it possible to
have proxy server forward requests to a socks server i.e. using ssh to
tunnel to another machine and then poiting the local caching server to the
port on the local machine (which gets forwarded to another host via)

something like this:

ssh -f -p 22 -D 45000 -l myname myfriends.host.net -N

this will create a SOCKS5 server on 127.0.0.1:45000

Can then one basically ask the caching server to retrieve everything through
socks server on 127.0.0.1:45000 ?

Thanks!

-- 
recovery is forever...
..... if you can take it that long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080210/a67a8bd9/attachment.html>

From fragfutter at gmail.com  Sun Feb 10 15:10:59 2008
From: fragfutter at gmail.com (C. Handel)
Date: Sun, 10 Feb 2008 16:10:59 +0100
Subject: Fetch from Socks server.
In-Reply-To: <d01483560802100639o5dc495c6h82a4229c81736eb3@mail.gmail.com>
References: <d01483560802100639o5dc495c6h82a4229c81736eb3@mail.gmail.com>
Message-ID: <3d62bd5f0802100710n6849a1f7o805b74e2c963afaf@mail.gmail.com>

Just create your SSH Tunnel with port forwarding (no need for Socks)
and point varnish to localhost:port as a source.

ssh -L 8080:www.example.com:80 user at sshhost.example.com

But you will pass all traffic through the encryption of the SSH
Tunnel, which will produce quite some CPU Load on both the Systems.

Greetings
   Christoph

On Feb 10, 2008 3:39 PM, David de Beer <daviddebeer at gmail.com> wrote:
>
> Greetings,
>
> I have not been able to find any info on this subject: Is it possible to
> have proxy server forward requests to a socks server i.e. using ssh to
> tunnel to another machine and then poiting the local caching server to the
> port on the local machine (which gets forwarded to another host via)
>
> something like this:
>
> ssh -f -p 22 -D 45000 -l myname myfriends.host.net -N
>
> this will create a SOCKS5 server on 127.0.0.1:45000
>
> Can then one basically ask the caching server to retrieve everything through
> socks server on 127.0.0.1:45000 ?
>
> Thanks!
>
> --
>  recovery is forever...
> ..... if you can take it that long.
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>


From daviddebeer at gmail.com  Sun Feb 10 15:25:02 2008
From: daviddebeer at gmail.com (David de Beer)
Date: Sun, 10 Feb 2008 17:25:02 +0200
Subject: Fetch from Socks server.
In-Reply-To: <3d62bd5f0802100710n6849a1f7o805b74e2c963afaf@mail.gmail.com>
References: <d01483560802100639o5dc495c6h82a4229c81736eb3@mail.gmail.com>
	<3d62bd5f0802100710n6849a1f7o805b74e2c963afaf@mail.gmail.com>
Message-ID: <d01483560802100725l17cb5cf9iad706fe6b44c1cf9@mail.gmail.com>

Hi, would that mean that I would have to create a tunnel for each http
server that i would need to connect to?

Sounds like a lot of work, if I understand you correctly.

I know privoxy supports socks forwarding, but it does not do caching. I'm
looking for something that will be able to do both.

Thanks!


On Feb 10, 2008 5:10 PM, C. Handel <fragfutter at gmail.com> wrote:

> Just create your SSH Tunnel with port forwarding (no need for Socks)
> and point varnish to localhost:port as a source.
>
> ssh -L 8080:www.example.com:80 user at sshhost.example.com
>
> But you will pass all traffic through the encryption of the SSH
> Tunnel, which will produce quite some CPU Load on both the Systems.
>
> Greetings
>   Christoph
>
> On Feb 10, 2008 3:39 PM, David de Beer <daviddebeer at gmail.com> wrote:
> >
> > Greetings,
> >
> > I have not been able to find any info on this subject: Is it possible to
> > have proxy server forward requests to a socks server i.e. using ssh to
> > tunnel to another machine and then poiting the local caching server to
> the
> > port on the local machine (which gets forwarded to another host via)
> >
> > something like this:
> >
> > ssh -f -p 22 -D 45000 -l myname myfriends.host.net -N
> >
> > this will create a SOCKS5 server on 127.0.0.1:45000
> >
> > Can then one basically ask the caching server to retrieve everything
> through
> > socks server on 127.0.0.1:45000 ?
> >
> > Thanks!
> >
> > --
> >  recovery is forever...
> > ..... if you can take it that long.
> > _______________________________________________
> > varnish-misc mailing list
> > varnish-misc at projects.linpro.no
> > http://projects.linpro.no/mailman/listinfo/varnish-misc
> >
> >
>



-- 
recovery is forever...
..... if you can take it that long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080210/c6653582/attachment.html>

From ak at openplans.org  Sun Feb 10 16:54:40 2008
From: ak at openplans.org (Arne Kepp)
Date: Sun, 10 Feb 2008 11:54:40 -0500
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
Message-ID: <47AF2C50.8000800@openplans.org>

Pretty much all my pages are in the 10k to 30k range, so I guess I am 
confirming this. It sucks that this is so hard to reproduce :(

I'm considering moving all the stuff I want cached to a different 
hostname / ip address, and let the clients talk directly to Apache again 
for the pages themselves, but that defeats half the purpose.

-Arne


Marco Molinari wrote:
> On Feb 6, 2008 2:57 AM, Arne Kepp <ak at openplans.org> wrote:
>   
>> (Maybe this should be on -misc ?)
>>     
>
> Ok, moved.
>
> Thank you for your reply. I'm using PHP and I had it gzip'ing, then I
> tried to use mod_deflate, but they're reporting the problem anyway.
>
> But I think the problem is similar. In fact, thanks to a user, I did
> some tests and I discovered that:
> - they can see static content, even html, any length
> - they can see content generated by PHP if it's smaller than 7500 bytes
> - they get a blank page if PHP output is more than 8000 bytes
> - they see everything if the accelerator is Squid
>
> I disabled compression during these tests. Maybe your users see a
> blank page just sometimes, when they request a page that, compressed,
> is larger than 7500/8000 bytes?
>
> Sorry I don't have a precise number, but I didn't want to stress my
> user too much, but I suppose I can work that out.
>
> I can't replicate this myself; I tried to use Squid (even different
> versions) on the client side, to replicate their setup, but I just see
> everything.
>
> My VCL is quite simple, too, lookup for images/css and pipe/pass for
> everything else.
>
> Any idea of what's happening? What can I do to find more clues?
>
> Thanks
> Marco
>
>
>
>
>   
>> I've seen one odd (to me) problem like this that I was able to reproduce
>> consistently, thanks to the help of a user. If you are serving PHP, and
>> PHP is gzip'ing the output then clients behind a Squid proxy (on their
>> end) only get blank pages.
>>
>> Squid records something like "TCP_MISS/200 416 GET <script name>? -
>> DIRECT/<ip address> text/html" in the logs, but doesn't appear to get
>> the page.
>>
>> Moving gzip compression from PHP to Apache solved this particular
>> problem, but I still have users reporting blank pages every now and
>> then. I've been accused of blocking all sorts of clients for this reason.
>>
>> My VCL file is simple, it's the standard logic + lookup for image and
>> css extensions and pass for everything else (also tried pipe).
>>
>> -Arne
>>
>>
>> Marco Molinari wrote:
>>     
>>> Hi,
>>> I recently deployed Varnish and its performance is simply incredible.
>>> I'm having a problem, though, which made me jump back to Squid. In the
>>> week I used Varnish I had some users mailing me that they couldn't see
>>> the site anymore, they just saw a blank page.
>>> It seems this affects a small percentage of the users, as I got just
>>> about 10 emails in a week and my users are in the 10000s, and in fact
>>> I didn't notice any problem in the stats; so I setup two servers, one
>>> with Squid and the other with Varnish, and the affected users see the
>>> site only through Squid.
>>>
>>> I'm trying to understand what's happening and with the help of some
>>> users here's what I discovered:
>>> - every user who has problems connects from an office (completely
>>> different places, of course)
>>> - at least one user connects via a proxy (she has a header that says
>>> "Via: 1.1 SRVFW1")
>>> - Apache serves the page, which is logged with the correct size
>>> - they can see very small pages (a test I did just printed "Thanks " +
>>> the timestamp)
>>>
>>> This happens both with 1.1.2 and trunk.
>>>
>>> On standard log files I can't find anything, I couldn't even know it
>>> was happening if those users didn't email me. I'd like to have more
>>> data before submitting a bug report; do you have any suggestion on how
>>> and what I could collect?
>>>
>>> Thanks
>>> Marco Molinari
>>> _______________________________________________
>>> varnish-dev mailing list
>>> varnish-dev at projects.linpro.no
>>> http://projects.linpro.no/mailman/listinfo/varnish-dev
>>>
>>>
>>>
>>>
>>>       
>>     
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
> !DSPAM:4038,47ab243e203721015089218!
>
>   



From ltning at anduin.net  Sun Feb 10 16:30:44 2008
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Sun, 10 Feb 2008 17:30:44 +0100
Subject: Fetch from Socks server.
In-Reply-To: <d01483560802100725l17cb5cf9iad706fe6b44c1cf9@mail.gmail.com>
References: <d01483560802100639o5dc495c6h82a4229c81736eb3@mail.gmail.com>
	<3d62bd5f0802100710n6849a1f7o805b74e2c963afaf@mail.gmail.com>
	<d01483560802100725l17cb5cf9iad706fe6b44c1cf9@mail.gmail.com>
Message-ID: <3C4EE3F7-9070-4B66-88E3-A6FB6163999C@anduin.net>

On Feb 10, 2008, at 4:25 PM, David de Beer wrote:

>
> Hi, would that mean that I would have to create a tunnel for each  
> http server that i would need to connect to?
>
> Sounds like a lot of work, if I understand you correctly.
>
> I know privoxy supports socks forwarding, but it does not do  
> caching. I'm looking for something that will be able to do both.

Hi,

I don't know on which platform you are running Varnish, but I've just  
tested the following on FreeBSD:

- Install varnish
- Install tsocks (/usr/ports/net/tsocks)
- Configure tsocks to use socks proxy for connections to back-end subnet
- Start ssh tunnel like you describe in your original mailing
- Start varnish like this (example):
	tsocks varnishd -a listen-host:port -b backend:port -s file,/tmp/ 
varnishcache,$((1024*1024*10))

This works nicely. You might want to add -c blowfish to your sshd  
commandline, to minimize CPU overhead in encryption. Whether -C  
(compresson) makes sense or not depends on the back-end config, data  
types, volume and CPU cycles available.

Have fun!
/Eirik


>
>
> Thanks!
>
>
> On Feb 10, 2008 5:10 PM, C. Handel <fragfutter at gmail.com> wrote:
> Just create your SSH Tunnel with port forwarding (no need for Socks)
> and point varnish to localhost:port as a source.
>
> ssh -L 8080:www.example.com:80 user at sshhost.example.com
>
> But you will pass all traffic through the encryption of the SSH
> Tunnel, which will produce quite some CPU Load on both the Systems.
>
> Greetings
>   Christoph
>
> On Feb 10, 2008 3:39 PM, David de Beer <daviddebeer at gmail.com> wrote:
> >
> > Greetings,
> >
> > I have not been able to find any info on this subject: Is it  
> possible to
> > have proxy server forward requests to a socks server i.e. using  
> ssh to
> > tunnel to another machine and then poiting the local caching  
> server to the
> > port on the local machine (which gets forwarded to another host via)
> >
> > something like this:
> >
> > ssh -f -p 22 -D 45000 -l myname myfriends.host.net -N
> >
> > this will create a SOCKS5 server on 127.0.0.1:45000
> >
> > Can then one basically ask the caching server to retrieve  
> everything through
> > socks server on 127.0.0.1:45000 ?
> >
> > Thanks!
> >
> > --
> >  recovery is forever...
> > ..... if you can take it that long.
> > _______________________________________________
> > varnish-misc mailing list
> > varnish-misc at projects.linpro.no
> > http://projects.linpro.no/mailman/listinfo/varnish-misc
> >
> >
>
>
>
> -- 
> recovery is forever...
> ..... if you can take it that long.  
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080210/7e05de91/attachment.html>

From fredrik.nygren at gotamedia.se  Mon Feb 11 14:34:26 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Mon, 11 Feb 2008 15:34:26 +0100
Subject: Varnish answering multiple incoming ports
Message-ID: <53BA0E06-8579-47A6-BD45-224C1C1CB2B2@gotamedia.se>

Hi,
I've browsed the mail archives but I can't find an answer for this  
question. Please point me to the thread if I've missed something.

I use a hardware load balancer in front of my web environment which  
forward the traffic to my web servers on different ports depending on  
the requested domain. For example:

domain1.com => port 81
domain2.com => port 82
domain3.com => port 83

Because of this I would like Varnish to listen for multiple incoming  
ports. Is it possible? I've tried this with no luck:

# varnish -a localhost:81 -a localhost:82 -a localhost:83

Better suggestions?

Regards
</Fredrik>



From ssm at linpro.no  Mon Feb 11 15:25:17 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Mon, 11 Feb 2008 16:25:17 +0100
Subject: Varnish answering multiple incoming ports
In-Reply-To: <53BA0E06-8579-47A6-BD45-224C1C1CB2B2@gotamedia.se> (Fredrik
	Nygren's message of "Mon, 11 Feb 2008 15:34:26 +0100")
References: <53BA0E06-8579-47A6-BD45-224C1C1CB2B2@gotamedia.se>
Message-ID: <7xhcgf7bxe.fsf@iostat.linpro.no>

Fredrik Nygren <fredrik.nygren at gotamedia.se> writes:

> Better suggestions?

Why split the traffic at all, if only to collect it in the same
varnish instance?

-- 
Stig Sandbeck Mathisen, Linpro


From phk at phk.freebsd.dk  Mon Feb 11 18:13:19 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 11 Feb 2008 18:13:19 +0000
Subject: Varnish answering multiple incoming ports 
In-Reply-To: Your message of "Mon, 11 Feb 2008 15:34:26 +0100."
	<53BA0E06-8579-47A6-BD45-224C1C1CB2B2@gotamedia.se> 
Message-ID: <98940.1202753599@critter.freebsd.dk>

In message <53BA0E06-8579-47A6-BD45-224C1C1CB2B2 at gotamedia.se>, Fredrik Nygren 
writes:

>Because of this I would like Varnish to listen for multiple incoming  
>ports. Is it possible? I've tried this with no luck:
>
># varnish -a localhost:81 -a localhost:82 -a localhost:83

I think the syntax is 

	varnish -a "localhost:81 localhost:82 localhost:83"

-- 
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 fredrik.nygren at gotamedia.se  Mon Feb 11 19:46:30 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Mon, 11 Feb 2008 20:46:30 +0100
Subject: Varnish answering multiple incoming ports 
In-Reply-To: <98940.1202753599@critter.freebsd.dk>
References: <98940.1202753599@critter.freebsd.dk>
Message-ID: <C8EE7416-A64C-4FFA-B4EE-0B1182743648@gotamedia.se>

Exactly what I needed.Thank you! Now it looks like Varnish rocks like  
I want. Impressive software by the way.

Regards
</Fredrik>

On 11 feb 2008, at 19.13, Poul-Henning Kamp wrote:

In message <53BA0E06-8579-47A6-BD45-224C1C1CB2B2 at gotamedia.se>,  
Fredrik Nygren
writes:

> Because of this I would like Varnish to listen for multiple incoming
> ports. Is it possible? I've tried this with no luck:
>
> # varnish -a localhost:81 -a localhost:82 -a localhost:83

I think the syntax is

	varnish -a "localhost:81 localhost:82 localhost:83"

-- 
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 michael at dynamine.net  Mon Feb 11 20:23:27 2008
From: michael at dynamine.net (Michael S. Fischer)
Date: Mon, 11 Feb 2008 12:23:27 -0800
Subject: Miscellaneous questions
Message-ID: <86db848d0802111223i29377d37k922307c11b4d6014@mail.gmail.com>

(1) Feature request: Can a knob be added to turn down the verbosity of
Varnish logging?  Right now on a quad-core Xeon we can service about
14k conn/s, which is good, but I wonder whether we could eke out even
more performance by quelling information that we don't need to log.

(2) HTTP/1.1 keep-alive connection reuse:  Does Varnish have the
ability to reuse origin server connections (assuming they are HTTP/1.1
Keep-Alive connections)?  Or, is there a strict 1:1 mapping between
client-proxy connections and proxy-origin server connections?

(3) Feature request: Request hashing.  It would be really cool if
Varnish were able to select the origin server (in reality another
Varnish proxy) by hashing the Request URI.  Having this ability would
improve the cache hit ratio overall where a pool of caching proxies is
used.

Best regards,

--Michael


From phk at phk.freebsd.dk  Mon Feb 11 22:58:25 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 11 Feb 2008 22:58:25 +0000
Subject: Miscellaneous questions 
In-Reply-To: Your message of "Mon, 11 Feb 2008 12:23:27 PST."
	<86db848d0802111223i29377d37k922307c11b4d6014@mail.gmail.com> 
Message-ID: <1167.1202770705@critter.freebsd.dk>

In message <86db848d0802111223i29377d37k922307c11b4d6014 at mail.gmail.com>, "Mich
ael S. Fischer" writes:

>(1) Feature request: Can a knob be added to turn down the verbosity of
>Varnish logging?  Right now on a quad-core Xeon we can service about
>14k conn/s, which is good, but I wonder whether we could eke out even
>more performance by quelling information that we don't need to log.

The shared memory log is practically free, the trick is to only
pick the stuff out of it that you need to store on disk.

>(2) HTTP/1.1 keep-alive connection reuse:  Does Varnish have the
>ability to reuse origin server connections (assuming they are HTTP/1.1
>Keep-Alive connections)?  Or, is there a strict 1:1 mapping between
>client-proxy connections and proxy-origin server connections?

They should already be reused by default.

>(3) Feature request: Request hashing.  It would be really cool if
>Varnish were able to select the origin server (in reality another
>Varnish proxy) by hashing the Request URI.  Having this ability would
>improve the cache hit ratio overall where a pool of caching proxies is
>used.

We have sort of given up on the peer-to-peer cache fetches using
dedicated protocols, but if you are able to tell that another
varnish is a better place to pick up something, nothing prevents
you from making that a backend of this varnish and doing
a pass on the request.

-- 
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 marco.molinari at gmail.com  Tue Feb 12 14:01:37 2008
From: marco.molinari at gmail.com (Marco Molinari)
Date: Tue, 12 Feb 2008 15:01:37 +0100
Subject: A few users see a blank page
In-Reply-To: <47AF2C50.8000800@openplans.org>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
Message-ID: <e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>

I can now reproduce it and I found a lot of info.

I wrote a simple script that keeps on reloading itself, adding some
chars each time; I disabled compression both in Apache and in PHP and
I connect my browser through a 2.6 Squid proxy; and now I can't see
PHP pages larger than 8000 bytes. I also found an interesting
connection with cookies.

Here are the log lines for Varnish requesting two pages to Apache:

Apache:
127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
/test_varnish2.php?n=10&t=1202822659 HTTP/1.0" 200 8000 "-"
"{MY-USER-AGENT}"
127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
/test_varnish2.php?n=11&t=1202822659 HTTP/1.0" 200 8001 "-"
"{MY-USER-AGENT}"

Varnish:
10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
http://dev.{MY-SITE}:2280/test_varnish2.php?n=10&t=1202822659
HTTP/1.0" 200 8000 "-" "{MY-USER-AGENT}"
10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
http://dev.{MY-SITE}:2280/test_varnish2.php?n=11&t=1202822659
HTTP/1.0" 200 0 "-" "{MY-USER-AGENT}"


As you can see Varnish logs a 0 size for the 8001 bytes request.


Here is the extended log (as per varnishlog) for those requests (sorry
for the length):

   15 ReqStart     c 10.0.2.2 43859 67671826
   15 RxRequest    c GET
   15 RxURL        c /test_varnish2.php?n=10&t=1202822659
   15 RxProtocol   c HTTP/1.0
   15 RxHeader     c Host: dev.{MY-SITE}:2280
   15 RxHeader     c User-Agent: {MY-USER-AGENT}
   15 RxHeader     c Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   15 RxHeader     c Accept-Language: en-us,en;q=0.5
   15 RxHeader     c Accept-Encoding: gzip,deflate
   15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   15 RxHeader     c Cookie:
__utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
__utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
__utmz=xxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
   15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   15 RxHeader     c X-Forwarded-For: 127.0.0.1
   15 RxHeader     c Cache-Control: max-age=259200
   15 RxHeader     c Connection: keep-alive
   15 VCL_call     c recv
   15 VCL_return   c pass
   15 VCL_call     c pass
   15 VCL_return   c pass
   18 BackendOpen  b default 127.0.0.1 32988 127.0.0.1 8080
   18 BackendXID   b 67671826
   15 Backend      c 18 default
   18 TxRequest    b GET
   18 TxURL        b /test_varnish2.php?n=10&t=1202822659
   18 TxProtocol   b HTTP/1.0
   18 TxHeader     b Host: dev.{MY-SITE}:2280
   18 TxHeader     b User-Agent: {MY-USER-AGENT}
   18 TxHeader     b Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   18 TxHeader     b Accept-Language: en-us,en;q=0.5
   18 TxHeader     b Accept-Encoding: gzip,deflate
   18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   18 TxHeader     b Cookie:
__utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
__utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
__utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
   18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   18 TxHeader     b X-Forwarded-For: 127.0.0.1
   18 TxHeader     b X-Varnish: 67671826
   18 TxHeader     b X-Forwarded-for: 10.0.2.2
   18 RxProtocol   b HTTP/1.1
   18 RxStatus     b 200
   18 RxResponse   b OK
   18 RxHeader     b Date: Tue, 12 Feb 2008 13:24:26 GMT
   18 RxHeader     b Server: Apache/2.0.52 (CentOS)
   18 RxHeader     b X-Powered-By: PHP/4.3.9
   18 RxHeader     b Content-Length: 8000
   18 RxHeader     b Connection: close
   18 RxHeader     b Content-Type: text/html; charset=UTF-8
   15 ObjProtocol  c HTTP/1.1
   15 ObjStatus    c 200
   15 ObjResponse  c OK
   15 ObjHeader    c Date: Tue, 12 Feb 2008 13:24:26 GMT
   15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
   15 ObjHeader    c X-Powered-By: PHP/4.3.9
   15 ObjHeader    c Content-Type: text/html; charset=UTF-8
   18 BackendClose b default
   15 TTL          c 67671826 RFC 120 1202822666 1202822666 0 0 0
   15 VCL_call     c fetch
   15 VCL_return   c insert
   15 Length       c 8000
   15 VCL_call     c deliver
   15 VCL_return   c deliver
   15 TxProtocol   c HTTP/1.1
   15 TxStatus     c 200
   15 TxResponse   c OK
   15 TxHeader     c Server: Apache/2.0.52 (CentOS)
   15 TxHeader     c X-Powered-By: PHP/4.3.9
   15 TxHeader     c Content-Type: text/html; charset=UTF-8
   15 TxHeader     c Content-Length: 8000
   15 TxHeader     c Date: Tue, 12 Feb 2008 13:24:26 GMT
   15 TxHeader     c X-Varnish: 67671826
   15 TxHeader     c Age: 0
   15 TxHeader     c Via: 1.1 varnish
   15 TxHeader     c Connection: keep-alive
   15 ReqEnd       c 67671826 1202822666.438220024
1202822666.440738916 3.759930134 0.002374887 0.000144005
    0 StatAddr       10.0.2.2 0 4217 31 171 0 0 171 41937 1114752
    0 CLI            Rd ping
    0 CLI            Wr 0 200 PONG 1202822669

    second request:

   15 ReqStart     c 10.0.2.2 43859 67671827
   15 RxRequest    c GET
   15 RxURL        c /test_varnish2.php?n=11&t=1202822659
   15 RxProtocol   c HTTP/1.0
   15 RxHeader     c Host: dev.{MY-SITE}:2280
   15 RxHeader     c User-Agent: {MY-USER-AGENT}
   15 RxHeader     c Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   15 RxHeader     c Accept-Language: en-us,en;q=0.5
   15 RxHeader     c Accept-Encoding: gzip,deflate
   15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   15 RxHeader     c Cookie:
__utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
__utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
__utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
   15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   15 RxHeader     c X-Forwarded-For: 127.0.0.1
   15 RxHeader     c Cache-Control: max-age=259200
   15 RxHeader     c Connection: keep-alive
   15 VCL_call     c recv
   15 VCL_return   c pass
   15 VCL_call     c pass
   15 VCL_return   c pass
   18 BackendOpen  b default 127.0.0.1 32989 127.0.0.1 8080
   18 BackendXID   b 67671827
   15 Backend      c 18 default
   18 TxRequest    b GET
   18 TxURL        b /test_varnish2.php?n=11&t=1202822659
   18 TxProtocol   b HTTP/1.0
   18 TxHeader     b Host: dev.{MY-SITE}:2280
   18 TxHeader     b User-Agent: {MY-USER-AGENT}
   18 TxHeader     b Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   18 TxHeader     b Accept-Language: en-us,en;q=0.5
   18 TxHeader     b Accept-Encoding: gzip,deflate
   18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   18 TxHeader     b Cookie:
__utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
__utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
__utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
   18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   18 TxHeader     b X-Forwarded-For: 127.0.0.1
   18 TxHeader     b X-Varnish: 67671827
   18 TxHeader     b X-Forwarded-for: 10.0.2.2
   18 RxProtocol   b HTTP/1.1
   18 RxStatus     b 200
   18 RxResponse   b OK
   18 RxHeader     b Date: Tue, 12 Feb 2008 13:24:29 GMT
   18 RxHeader     b Server: Apache/2.0.52 (CentOS)
   18 RxHeader     b X-Powered-By: PHP/4.3.9
   18 RxHeader     b Connection: close
   18 RxHeader     b Content-Type: text/html; charset=UTF-8
   15 ObjProtocol  c HTTP/1.1
   15 ObjStatus    c 200
   15 ObjResponse  c OK
   15 ObjHeader    c Date: Tue, 12 Feb 2008 13:24:29 GMT
   15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
   15 ObjHeader    c X-Powered-By: PHP/4.3.9
   15 ObjHeader    c Content-Type: text/html; charset=UTF-8
   18 BackendClose b default
   15 TTL          c 67671827 RFC 120 1202822669 1202822669 0 0 0
   15 VCL_call     c fetch
   15 VCL_return   c insert
   15 Length       c 0
   15 VCL_call     c deliver
   15 VCL_return   c deliver
   15 TxProtocol   c HTTP/1.1
   15 TxStatus     c 200
   15 TxResponse   c OK
   15 TxHeader     c Server: Apache/2.0.52 (CentOS)
   15 TxHeader     c X-Powered-By: PHP/4.3.9
   15 TxHeader     c Content-Type: text/html; charset=UTF-8
   15 TxHeader     c Date: Tue, 12 Feb 2008 13:24:29 GMT
   15 TxHeader     c X-Varnish: 67671827
   15 TxHeader     c Age: 0
   15 TxHeader     c Via: 1.1 varnish
   15 TxHeader     c Connection: keep-alive
   15 ReqEnd       c 67671827 1202822669.762167931
1202822669.765445948 3.321429014 0.003173113 0.000104904
    0 StatAddr       10.0.2.2 0 4221 31 172 0 0 172 42161 1114752
    0 CLI            Rd ping
    0 CLI            Wr 0 200 PONG 1202822672
   15 SessionClose c timeout
   15 StatSess     c 10.0.2.2 43859 11 1 4 0 0 4 962 23995

As you can see in the 8001 bytes request there seems to be no
Content-Length header in the Apache response, but I checked with
LiveHttpHeaders (without Squid) and the header is there.

You can also notice that cookies in the extended logs are cut (I
replaced the numbers with "xxx"); so I tried to disable the cookies in
the browser, and everything works!

   15 ReqStart     c 10.0.2.2 57522 67671865
   15 RxRequest    c GET
   15 RxURL        c /test_varnish2.php?n=11&t=1202823345
   15 RxProtocol   c HTTP/1.0
   15 RxHeader     c Host: dev.{MY-SITE}:2280
   15 RxHeader     c User-Agent: {MY-USER-AGENT}
   15 RxHeader     c Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   15 RxHeader     c Accept-Language: en-us,en;q=0.5
   15 RxHeader     c Accept-Encoding: gzip,deflate
   15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   15 RxHeader     c X-Forwarded-For: 127.0.0.1
   15 RxHeader     c Cache-Control: max-age=259200
   15 RxHeader     c Connection: keep-alive
   15 VCL_call     c recv
   15 VCL_return   c lookup
   15 VCL_call     c hash
   15 VCL_return   c hash
   15 VCL_call     c miss
   15 VCL_return   c fetch
   18 BackendOpen  b default 127.0.0.1 33028 127.0.0.1 8080
   18 BackendXID   b 67671865
   15 Backend      c 18 default
   18 TxRequest    b GET
   18 TxURL        b /test_varnish2.php?n=11&t=1202823345
   18 TxProtocol   b HTTP/1.1
   18 TxHeader     b Host: dev.{MY-SITE}:2280
   18 TxHeader     b User-Agent: {MY-USER-AGENT}
   18 TxHeader     b Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   18 TxHeader     b Accept-Language: en-us,en;q=0.5
   18 TxHeader     b Accept-Encoding: gzip,deflate
   18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
   18 TxHeader     b X-Forwarded-For: 127.0.0.1
   18 TxHeader     b X-Varnish: 67671865
   18 TxHeader     b X-Forwarded-for: 10.0.2.2
   18 RxProtocol   b HTTP/1.1
   18 RxStatus     b 200
   18 RxResponse   b OK
   18 RxHeader     b Date: Tue, 12 Feb 2008 13:35:57 GMT
   18 RxHeader     b Server: Apache/2.0.52 (CentOS)
   18 RxHeader     b X-Powered-By: PHP/4.3.9
   18 RxHeader     b Connection: close
   18 RxHeader     b Transfer-Encoding: chunked
   18 RxHeader     b Content-Type: text/html; charset=UTF-8
   15 ObjProtocol  c HTTP/1.1
   15 ObjStatus    c 200
   15 ObjResponse  c OK
   15 ObjHeader    c Date: Tue, 12 Feb 2008 13:35:57 GMT
   15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
   15 ObjHeader    c X-Powered-By: PHP/4.3.9
   15 ObjHeader    c Content-Type: text/html; charset=UTF-8
   18 BackendClose b default
   15 TTL          c 67671865 RFC 120 1202823357 1202823357 0 0 0
   15 VCL_call     c fetch
   15 VCL_return   c insert
   15 Length       c 8001
   15 VCL_call     c deliver
   15 VCL_return   c deliver
   15 TxProtocol   c HTTP/1.1
   15 TxStatus     c 200
   15 TxResponse   c OK
   15 TxHeader     c Server: Apache/2.0.52 (CentOS)
   15 TxHeader     c X-Powered-By: PHP/4.3.9
   15 TxHeader     c Content-Type: text/html; charset=UTF-8
   15 TxHeader     c Content-Length: 8001
   15 TxHeader     c Date: Tue, 12 Feb 2008 13:35:57 GMT
   15 TxHeader     c X-Varnish: 67671865
   15 TxHeader     c Age: 0
   15 TxHeader     c Via: 1.1 varnish
   15 TxHeader     c Connection: keep-alive
   15 ReqEnd       c 67671865 1202823357.593729973
1202823357.596472979 3.786515951 0.002630949 0.000112057
    0 StatAddr       10.0.2.2 0 4908 34 210 0 0 210 52216 1395936


This could explain why the problem seems so erratic, as a user can see
a page or not depending on the page length and their cookies.

My configuration:
- web server: Centos 4 + Apache 2.0.52 + PHP 4.3.9 + Varnish 1.1.2
(everything installed through rpms)
- proxy server: Ubuntu 7.10 + Squid 2.6
- client: Ubuntu 7.10 + Firefox (actually it's the same pc that runs
the proxy server)



Uncommented parts in my vcl:
backend default {
        set backend.host = "127.0.0.1";
        set backend.port = "8080";
}

sub vcl_recv {
        if (req.http.Pragma == "no-cache") {
                pipe;
        }

        if (req.request == "GET" && req.url ~
"\.(gif|jpg|swf|css|js|swf|flv|png|jpeg)$") {
                lookup;
        }

        if (req.request != "GET" && req.request != "HEAD") {
                pipe;
        }

        if (req.http.Expect) {
                pipe;
        }

        if (req.http.Authenticate || req.http.Cookie) {
                pass;
        }

        lookup;
}


Is this enough to post a bug report?

Thanks
Marco


From janis.putrams at delfi.lv  Tue Feb 12 14:02:02 2008
From: janis.putrams at delfi.lv (Janis Putrams)
Date: Tue, 12 Feb 2008 16:02:02 +0200
Subject: Assert error in exp_hangman()
In-Reply-To: <200802061529.44110.janis.putrams@delfi.lv>
References: <200802061529.44110.janis.putrams@delfi.lv>
Message-ID: <200802121602.03194.janis.putrams@delfi.lv>

Hi!
I thought that probably its more productive to test and fix the trunk version 
so i switched to trunk and indeed this error has disappeared.
I have attached debug log from the trunk revision 2442

Assert errors still encountered:
Assert error in STV_alloc(), stevedore.c line 70
Assert error in SES_Delete(), cache_session.c line 339
Assert error in CNT_Session(), cache_center.c line 913

hope it helps.
Regards,
Janis Putrams


On Wednesday 06 February 2008 15:29, Janis Putrams wrote:
> Hi!
>
> Child dies from time to time. Is there a solution to this?
>
> 15:35:04 root[pts/2]@slow ~# varnishd -V
> varnishd (varnish-1.1.2)
>
> ...
> Child said (2, 28732): <<Assert error in exp_hangman(), cache_expire.c line
> 113:
>   Condition((o)->magic == 0x32851d42) not true.
>   errno = 0 (Success)
>
> Cache child died pid=28732 status=0x86
> Clean child
> ...
>
> Thanks,
> Janis Putrams
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
-------------- next part --------------

13:38:39 root[pts/5]@slow ~# varnishd -d -d -u root -f /etc/varnishd/varnishd_trunk.conf -T 127.0.0.1:81 -P /var/run/varnishd.pid -s file,/var/spool/varnishd/varnishd_storage.bin,512M -w 20,250,120
storage_file: filename: /var/spool/varnishd/varnishd_storage.bin size 512 MB.
Using old SHMFILE
rolling(1)...
rolling(2)...
Debugging mode, enter "start" to start child
start
start child pid 13188
200 0

Child said (2, 13188): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>

200 0

At revision 2442
101 32
all commands are in lower-case.

Child said (2, 13188): <<flunk 5391 2272
>>
Child said (2, 13188): <<flunk 8192 7164
>>
Child said (2, 13188): <<flunk 5391 2272
>>
Child said (2, 13188): <<flunk 5388 2272
>>
Child said (2, 13188): <<flunk 5391 2272
>>
Child said (2, 13188): <<flunk 5391 2272
>>
Child said (2, 13188): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 13188): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=13188 status=0x86
Clean child
Child cleaned
start child pid 13526
Child said (2, 13526): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 13526): <<flunk 8192 1000
>>
Child said (2, 13526): <<flunk 8192 7776
>>
Child said (2, 13526): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 13526): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=13526 status=0x86
Clean child
Child cleaned
start child pid 13698
Child said (2, 13698): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 13698): <<flunk 8192 3112
>>
Child said (2, 13698): <<flunk 8192 1984
>>
Child said (2, 13698): <<flunk 8192 1984
>>
Child said (2, 13698): <<flunk 8192 2082
>>
Child said (2, 13698): <<flunk 8192 4056
>>
Child said (2, 13698): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 13698): <<  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=13698 status=0x86
Clean child
Child cleaned
start child pid 14077
Child said (2, 14077): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 14077): <<flunk 8192 5266
>>
Child said (2, 14077): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Cache child died pid=14077 status=0x86
Clean child
Child cleaned
start child pid 14319
Child said (2, 14319): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 14319): <<flunk 8192 6784
>>
Child said (2, 14319): <<flunk 8192 3376
>>
Child said (2, 14319): <<flunk 8192 5436
>>
Child said (2, 14319): <<flunk 8192 1792
>>
Child said (2, 14319): <<flunk 8192 6288
>>
Child said (2, 14319): <<flunk 8192 48
>>
Child said (2, 14319): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 14319): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=14319 status=0x86
Clean child
Child cleaned
start child pid 14636
Child said (2, 14636): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 14636): <<flunk 8192 100
>>
Child said (2, 14636): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=14636 status=0x86
Clean child
Child cleaned
start child pid 14985
Child said (2, 14985): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 14985): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=14985 status=0x86
Clean child
Child cleaned
start child pid 15395
Child said (2, 15395): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 15395): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=15395 status=0x86
Clean child
Child cleaned
start child pid 15653
Child said (2, 15653): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 15653): <<flunk 8192 2512
>>
Child said (2, 15653): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 104 (Connection reset by peer)
>>
Cache child died pid=15653 status=0x86
Clean child
Child cleaned
start child pid 15986
Child said (2, 15986): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 15986): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 15986): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=15986 status=0x86
Clean child
Child cleaned
start child pid 16178
Child said (2, 16178): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16178): <<flunk 8192 6976
>>
Child said (2, 16178): <<flunk 8192 1984
>>
Child said (2, 16178): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 16178): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=16178 status=0x86
Clean child
Child cleaned
start child pid 16456
Child said (2, 16456): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16456): <<flunk 8192 1108
>>
Child said (2, 16456): <<flunk 8192 2480
>>
Child said (2, 16456): <<flunk 8192 1072
>>
Child said (2, 16456): <<flunk 8192 2520
>>
Child said (2, 16456): <<flunk 7825 6288
>>
Child said (2, 16456): <<flunk 8192 4384
>>
Child said (2, 16456): <<flunk 8192 4384
>>
Child said (2, 16456): <<flunk 8192 2440
>>
Child said (2, 16456): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=16456 status=0x86
Clean child
Child cleaned
start child pid 16925
Child said (2, 16925): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16925): <<flunk 8192 4840
>>
Child said (2, 16925): <<flunk 8192 5899
>>
Child said (2, 16925): <<flunk 8192 2272
>>
Child said (2, 16925): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 16925): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=16925 status=0x86
Clean child
Child cleaned
start child pid 17186
Child said (2, 17186): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 17186): <<flunk 8192 5961
>>
Child said (2, 17186): <<flunk 8192 2272
>>
Child said (2, 17186): <<flunk 8192 5934
>>
Child said (2, 17186): <<flunk 8192 2549
>>
Child said (2, 17186): <<flunk 8192 2272
>>
Child said (2, 17186): <<flunk 8192 5746
>>
Child said (2, 17186): <<flunk 8192 4056
>>
Child said (2, 17186): <<flunk 8192 4647
>>
Child said (2, 17186): <<flunk 8192 1984
>>
Child said (2, 17186): <<flunk 6208 5792
>>
Child said (2, 17186): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 17186): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=17186 status=0x86
Clean child
Child cleaned
start child pid 17772
Child said (2, 17772): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 17772): <<flunk 8192 5504
>>
Child said (2, 17772): <<flunk 8192 1032
>>
Child said (2, 17772): <<flunk 8192 6640
>>
Child said (2, 17772): <<flunk 8192 5954
>>
Child said (2, 17772): <<flunk 8192 2272
>>
Child said (2, 17772): <<flunk 8192 4158
>>
Child said (2, 17772): <<flunk 8192 1840
>>
Child said (2, 17772): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 17772): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=17772 status=0x86
Clean child
Child cleaned
start child pid 18725
Child said (2, 18725): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 18725): <<flunk 5060 2068
>>
Child said (2, 18725): <<flunk 8192 2440
>>
Child said (2, 18725): <<flunk 8192 5873
>>
Child said (2, 18725): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 18725): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=18725 status=0x86
Clean child
Child cleaned
start child pid 19094
Child said (2, 19094): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19094): <<flunk 8192 4384
>>
Child said (2, 19094): <<flunk 8192 2130
>>
Child said (2, 19094): <<flunk 8192 2272
>>
Child said (2, 19094): <<flunk 8192 4056
>>
Child said (2, 19094): <<flunk 8192 4614
>>
Child said (2, 19094): <<flunk 8192 2656
>>
Child said (2, 19094): <<flunk 8192 4056
>>
Child said (2, 19094): <<flunk 8192 1984
>>
Child said (2, 19094): <<flunk 8192 6848
>>
Child said (2, 19094): <<flunk 8192 1732
>>
Child said (2, 19094): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 19094): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=19094 status=0x86
Clean child
Child cleaned
start child pid 19897
Child said (2, 19897): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19897): <<flunk 8192 6784
>>
Child said (2, 19897): <<flunk 6453 1984
>>
Child said (2, 19897): <<flunk 8192 992
>>
Child said (2, 19897): <<flunk 8192 3848
>>
Child said (2, 19897): <<flunk 8192 1984
>>
Child said (2, 19897): <<flunk 8192 2272
>>
Child said (2, 19897): <<flunk 8192 2272
>>
Child said (2, 19897): <<flunk 8192 2480
>>
Child said (2, 19897): <<flunk 8192 1032
>>
Child said (2, 19897): <<flunk 8192 992
>>
Child said (2, 19897): <<flunk 8192 2272
>>
Child said (2, 19897): <<flunk 8192 1984
>>
Child said (2, 19897): <<flunk 8192 3928
>>
Child said (2, 19897): <<flunk 8192 5828
>>
Child said (2, 19897): <<flunk 8192 1984
>>
Child said (2, 19897): <<flunk 8192 1984
>>
Child said (2, 19897): <<flunk 8192 1914
>>
Child said (2, 19897): <<flunk 8192 1984
>>
Child said (2, 19897): <<flunk 8015 6652
>>
Child said (2, 19897): <<flunk 8192 6784
>>
Child said (2, 19897): <<flunk 8192 4384
>>
Child said (2, 19897): <<flunk 8192 2280
>>
Child said (2, 19897): <<flunk 8192 3928
>>
Child said (2, 19897): <<flunk 8192 4920
>>
Child said (2, 19897): <<flunk 8192 3432
>>
Child said (2, 19897): <<flunk 8192 2272
>>
Child said (2, 19897): <<flunk 8192 6288
>>
Child said (2, 19897): <<flunk 8192 992
>>
Child said (2, 19897): <<flunk 6231 2480
>>
Child said (2, 19897): <<flunk 8192 6652
>>
Child said (2, 19897): <<flunk 8192 5832
>>
Child said (2, 19897): <<flunk 8192 6135
>>
Child said (2, 19897): <<flunk 8192 5504
>>
Child said (2, 19897): <<flunk 8192 2272
>>
Child said (2, 19897): <<flunk 8192 5504
>>
Child said (2, 19897): <<flunk 8192 3164
>>
Child said (2, 19897): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 19897): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=19897 status=0x86
Clean child
Child cleaned
start child pid 21804
Child said (2, 21804): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 21804): <<flunk 8192 3888
>>
Child said (2, 21804): <<flunk 8192 2976
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 4056
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 7736
>>
Child said (2, 21804): <<flunk 8192 2280
>>
Child said (2, 21804): <<flunk 8192 3928
>>
Child said (2, 21804): <<flunk 8192 2232
>>
Child said (2, 21804): <<flunk 8192 3859
>>
Child said (2, 21804): <<flunk 8192 4756
>>
Child said (2, 21804): <<flunk 8192 1732
>>
Child said (2, 21804): <<flunk 7473 2840
>>
Child said (2, 21804): <<flunk 8192 4424
>>
Child said (2, 21804): <<flunk 8192 5668
>>
Child said (2, 21804): <<flunk 8192 1996
>>
Child said (2, 21804): <<flunk 8192 2840
>>
Child said (2, 21804): <<flunk 8192 4300
>>
Child said (2, 21804): <<flunk 8192 6288
>>
Child said (2, 21804): <<flunk 2716 1056
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 8192 3053
>>
Child said (2, 21804): <<flunk 8192 1704
>>
Child said (2, 21804): <<flunk 8192 488
>>
Child said (2, 21804): <<flunk 2084 244
>>
Child said (2, 21804): <<flunk 8192 3432
>>
Child said (2, 21804): <<flunk 8192 3432
>>
Child said (2, 21804): <<flunk 8192 635
>>
Child said (2, 21804): <<flunk 8192 3432
>>
Child said (2, 21804): <<flunk 8192 3796
>>
Child said (2, 21804): <<flunk 8192 3432
>>
Child said (2, 21804): <<flunk 8192 3432
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 3928
>>
Child said (2, 21804): <<flunk 8192 6824
>>
Child said (2, 21804): <<flunk 3477 1131
>>
Child said (2, 21804): <<flunk 8192 2480
>>
Child said (2, 21804): <<flunk 8192 3928
>>
Child said (2, 21804): <<flunk 8192 3928
>>
Child said (2, 21804): <<flunk 8192 3112
>>
Child said (2, 21804): <<flunk 6644 5490
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 2480
>>
Child said (2, 21804): <<flunk 8192 6288
>>
Child said (2, 21804): <<flunk 8192 6288
>>
Child said (2, 21804): <<flunk 8192 1488
>>
Child said (2, 21804): <<flunk 8192 6784
>>
Child said (2, 21804): <<flunk 8192 2064
>>
Child said (2, 21804): <<flunk 8192 5504
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 5872
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 8192 4384
>>
Child said (2, 21804): <<flunk 8192 4705
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 5376
>>
Child said (2, 21804): <<flunk 3863 2272
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 1792
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 2592
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 1732
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 6824
>>
Child said (2, 21804): <<flunk 8192 2592
>>
Child said (2, 21804): <<flunk 8192 6784
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 5832
>>
Child said (2, 21804): <<flunk 8192 2480
>>
Child said (2, 21804): <<flunk 8192 1488
>>
Child said (2, 21804): <<flunk 8192 904
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 6084
>>
Child said (2, 21804): <<flunk 8192 904
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 1032
>>
Child said (2, 21804): <<flunk 8192 2480
>>
Child said (2, 21804): <<flunk 8192 5336
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 6001 3232
>>
Child said (2, 21804): <<flunk 8192 4056
>>
Child said (2, 21804): <<flunk 4247 2840
>>
Child said (2, 21804): <<flunk 6643 992
>>
Child said (2, 21804): <<flunk 8192 1488
>>
Child said (2, 21804): <<flunk 3002 2592
>>
Child said (2, 21804): <<flunk 8192 2592
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 4572
>>
Child said (2, 21804): <<flunk 8192 1984
>>
Child said (2, 21804): <<flunk 8192 5376
>>
Child said (2, 21804): <<flunk 8192 2592
>>
Child said (2, 21804): <<flunk 8192 7084
>>
Child said (2, 21804): <<flunk 8192 992
>>
Child said (2, 21804): <<flunk 8192 7736
>>
Child said (2, 21804): <<flunk 8192 40
>>
Child said (2, 21804): <<flunk 8192 2272
>>
Child said (2, 21804): <<flunk 7384 4056
>>
Child said (2, 21804): <<flunk 8192 2480
>>
Child said (2, 21804): <<flunk 8192 2448
>>
Child said (2, 21804): <<flunk 5418 2272
>>
Child said (2, 21804): <<flunk 5418 2272
>>
Child said (2, 21804): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 21804): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=21804 status=0x86
Clean child
Child cleaned
start child pid 25530
Child said (2, 25530): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 25530): <<flunk 8192 6656
>>
Child said (2, 25530): <<flunk 8192 6288
>>
Child said (2, 25530): <<flunk 8192 992
>>
Child said (2, 25530): <<flunk 8192 6976
>>
Child said (2, 25530): <<flunk 8192 6288
>>
Child said (2, 25530): <<flunk 8192 536
>>
Child said (2, 25530): <<flunk 8192 5416
>>
Child said (2, 25530): <<flunk 8192 1984
>>
Child said (2, 25530): <<flunk 8192 1488
>>
Child said (2, 25530): <<flunk 8192 4624
>>
Child said (2, 25530): <<flunk 8192 1984
>>
Child said (2, 25530): <<flunk 8192 5376
>>
Child said (2, 25530): <<flunk 8192 6288
>>
Child said (2, 25530): <<flunk 8192 2440
>>
Child said (2, 25530): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 25530): <<  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=25530 status=0x86
Clean child
Child cleaned
start child pid 26314
Child said (2, 26314): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 26314): <<flunk 8192 4384
>>
Child said (2, 26314): <<flunk 2801 244
>>
Child said (2, 26314): <<flunk 5388 2272
>>
Child said (2, 26314): <<flunk 5418 2272
>>
Child said (2, 26314): <<flunk 5391 2272
>>
Child said (2, 26314): <<flunk 5391 2272
>>
Child said (2, 26314): <<flunk 5138 1992
>>
Child said (2, 26314): <<flunk 8192 1488
>>
Child said (2, 26314): <<flunk 5418 2272
>>
Child said (2, 26314): <<flunk 8192 1984
>>
Child said (2, 26314): <<flunk 5391 2272
>>
Child said (2, 26314): <<flunk 5388 2272
>>
Child said (2, 26314): <<flunk 8192 616
>>
Child said (2, 26314): <<flunk 8192 4880
>>
Child said (2, 26314): <<flunk 8192 576
>>
Child said (2, 26314): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 26314): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=26314 status=0x86
Clean child
Child cleaned
start child pid 27210
Child said (2, 27210): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 27210): <<flunk 8192 2272
>>
Child said (2, 27210): <<flunk 8192 4880
>>
Child said (2, 27210): <<flunk 8192 4056
>>
Child said (2, 27210): <<flunk 8192 6288
>>
Child said (2, 27210): <<flunk 8192 3376
>>
Child said (2, 27210): <<flunk 8192 4756
>>
Child said (2, 27210): <<flunk 8192 6288
>>
Child said (2, 27210): <<flunk 8192 6784
>>
Child said (2, 27210): <<flunk 8192 7736
>>
Child said (2, 27210): <<flunk 8192 4056
>>
Child said (2, 27210): <<flunk 8192 2272
>>
Child said (2, 27210): <<flunk 8192 3432
>>
Child said (2, 27210): <<flunk 8192 5938
>>
Child said (2, 27210): <<flunk 8192 488
>>
Child said (2, 27210): <<flunk 8192 6288
>>
Child said (2, 27210): <<flunk 8192 6288
>>
Child said (2, 27210): <<flunk 8192 7736
>>
Child said (2, 27210): <<flunk 8192 4880
>>
Child said (2, 27210): <<flunk 8192 7360
>>
Child said (2, 27210): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 27210): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=27210 status=0x86
Clean child
Child cleaned
start child pid 27956
Child said (2, 27956): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 27956): <<flunk 8192 2936
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 8192 1136
>>
Child said (2, 27956): <<flunk 8192 7428
>>
Child said (2, 27956): <<flunk 8192 1528
>>
Child said (2, 27956): <<flunk 8192 1984
>>
Child said (2, 27956): <<flunk 8192 5304
>>
Child said (2, 27956): <<flunk 8192 3928
>>
Child said (2, 27956): <<flunk 8192 5436
>>
Child said (2, 27956): <<flunk 8192 5436
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 3839 2024
>>
Child said (2, 27956): <<flunk 8192 536
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 8192 7320
>>
Child said (2, 27956): <<flunk 8192 6450
>>
Child said (2, 27956): <<flunk 8192 7776
>>
Child said (2, 27956): <<flunk 8192 7776
>>
Child said (2, 27956): <<flunk 8192 3432
>>
Child said (2, 27956): <<flunk 8192 3432
>>
Child said (2, 27956): <<flunk 8192 3432
>>
Child said (2, 27956): <<flunk 8192 3432
>>
Child said (2, 27956): <<flunk 8192 3432
>>
Child said (2, 27956): <<flunk 8192 6288
>>
Child said (2, 27956): <<flunk 8192 4056
>>
Child said (2, 27956): <<flunk 8192 4056
>>
Child said (2, 27956): <<flunk 8192 6976
>>
Child said (2, 27956): <<flunk 8192 992
>>
Child said (2, 27956): <<flunk 8192 6288
>>
Child said (2, 27956): <<flunk 8192 6288
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 8192 6784
>>
Child said (2, 27956): <<flunk 8192 4056
>>
Child said (2, 27956): <<flunk 8192 7377
>>
Child said (2, 27956): <<flunk 8192 1732
>>
Child said (2, 27956): <<flunk 8192 992
>>
Child said (2, 27956): <<flunk 7667 5497
>>
Child said (2, 27956): <<flunk 8192 2272
>>
Child said (2, 27956): <<flunk 8192 4056
>>
Child said (2, 27956): <<flunk 8192 6723
>>
Child said (2, 27956): <<flunk 8192 3463
>>
Child said (2, 27956): <<flunk 8192 3741
>>
Child said (2, 27956): <<flunk 8192 2924
>>
Child said (2, 27956): <<flunk 8192 6288
>>
Child said (2, 27956): <<flunk 8192 1528
>>
Child said (2, 27956): <<flunk 8192 6288
>>
Child said (2, 27956): <<flunk 8192 4056
>>
Child said (2, 27956): <<flunk 8192 3888
>>
Child said (2, 27956): <<flunk 7462 992
>>
Child said (2, 27956): <<flunk 8192 1984
>>
Child said (2, 27956): <<flunk 8140 6455
>>
Child said (2, 27956): <<flunk 8192 3530
>>
Child said (2, 27956): <<flunk 8192 3554
>>
Child said (2, 27956): <<flunk 8192 3867
>>
Child said (2, 27956): <<flunk 8192 4880
>>
Child said (2, 27956): <<flunk 8192 3928
>>
Child said (2, 27956): <<flunk 8192 536
>>
Child said (2, 27956): <<flunk 8192 992
>>
Child said (2, 27956): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 27956): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=27956 status=0x86
Clean child
Child cleaned
start child pid 30611
Child said (2, 30611): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 30611): <<flunk 8192 5376
>>
Child said (2, 30611): <<flunk 8192 4056
>>
Child said (2, 30611): <<flunk 8192 2440
>>
Child said (2, 30611): <<flunk 8192 2592
>>
Child said (2, 30611): <<flunk 8192 4056
>>
Child said (2, 30611): <<flunk 8192 4056
>>
Child said (2, 30611): <<flunk 8192 4880
>>
Child said (2, 30611): <<flunk 8192 4056
>>
Child said (2, 30611): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 30611): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=30611 status=0x86
Clean child
Child cleaned
start child pid 30968
Child said (2, 30968): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 30968): <<flunk 8192 2480
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 6784
>>
Child said (2, 30968): <<flunk 8192 2195
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 6652
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 4880
>>
Child said (2, 30968): <<flunk 8192 2480
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2440
>>
Child said (2, 30968): <<flunk 8192 5514
>>
Child said (2, 30968): <<flunk 8192 1984
>>
Child said (2, 30968): <<flunk 8192 4880
>>
Child said (2, 30968): <<flunk 8192 4880
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 6288
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 7736
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 1676 1366
>>
Child said (2, 30968): <<flunk 8192 4880
>>
Child said (2, 30968): <<flunk 5989 5872
>>
Child said (2, 30968): <<flunk 8192 6784
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 5336
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 5336
>>
Child said (2, 30968): <<flunk 8192 2134
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 7280
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 3888
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 4880
>>
Child said (2, 30968): <<flunk 8192 5336
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 3512
>>
Child said (2, 30968): <<flunk 5600 4080
>>
Child said (2, 30968): <<flunk 8192 6408
>>
Child said (2, 30968): <<flunk 8192 6408
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 5418 2272
>>
Child said (2, 30968): <<flunk 5391 2272
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 2925
>>
Child said (2, 30968): <<flunk 5391 2272
>>
Child said (2, 30968): <<flunk 5391 2272
>>
Child said (2, 30968): <<flunk 8192 1488
>>
Child said (2, 30968): <<flunk 8192 1984
>>
Child said (2, 30968): <<flunk 8192 4424
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 5336
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 2480
>>
Child said (2, 30968): <<flunk 5418 2272
>>
Child said (2, 30968): <<flunk 8192 2480
>>
Child said (2, 30968): <<flunk 8192 576
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 5418 2272
>>
Child said (2, 30968): <<flunk 5388 2272
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 1984
>>
Child said (2, 30968): <<flunk 5418 2272
>>
Child said (2, 30968): <<flunk 8192 5376
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 2592
>>
Child said (2, 30968): <<flunk 8192 2480
>>
Child said (2, 30968): <<flunk 8192 8112
>>
Child said (2, 30968): <<flunk 8192 4384
>>
Child said (2, 30968): <<flunk 8192 8112
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 1488
>>
Child said (2, 30968): <<flunk 8192 1488
>>
Child said (2, 30968): <<flunk 8192 2024
>>
Child said (2, 30968): <<flunk 6699 2596
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 1984
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 5376
>>
Child said (2, 30968): <<flunk 8192 6288
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 2440
>>
Child said (2, 30968): <<flunk 8192 5872
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 7320
>>
Child said (2, 30968): <<flunk 8192 6328
>>
Child said (2, 30968): <<flunk 8192 3676
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 5418 2272
>>
Child said (2, 30968): <<flunk 5382 2272
>>
Child said (2, 30968): <<flunk 8192 4424
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2192
>>
Child said (2, 30968): <<flunk 8192 4384
>>
Child said (2, 30968): <<flunk 8192 7826
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 7280
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<flunk 8192 3432
>>
Child said (2, 30968): <<flunk 8192 992
>>
Child said (2, 30968): <<flunk 8192 1840
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 2272
>>
Child said (2, 30968): <<flunk 8192 4056
>>
Child said (2, 30968): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 30968): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=30968 status=0x86
Clean child
Child cleaned
start child pid 3282
Child said (2, 3282): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3282): <<flunk 8192 7648
>>
Child said (2, 3282): <<flunk 8192 992
>>
Child said (2, 3282): <<flunk 8192 6288
>>
Child said (2, 3282): <<flunk 8192 3432
>>
Child said (2, 3282): <<flunk 8192 3432
>>
Child said (2, 3282): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Cache child died pid=3282 status=0x86
Clean child
Child cleaned
start child pid 3619
Child said (2, 3619): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3619): <<flunk 8192 3676
>>
Child said (2, 3619): <<flunk 8192 5872
>>
Child said (2, 3619): <<flunk 8192 992
>>
Child said (2, 3619): <<flunk 8192 1732
>>
Child said (2, 3619): <<flunk 8192 6404
>>
Child said (2, 3619): <<flunk 8192 4880
>>
Child said (2, 3619): <<flunk 8192 6288
>>
Child said (2, 3619): <<flunk 5391 2272
>>
Child said (2, 3619): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 3619): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=3619 status=0x86
Clean child
Child cleaned
start child pid 3971
Child said (2, 3971): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3971): <<flunk 8192 4880
>>
Child said (2, 3971): <<flunk 5099 4880
>>
Child said (2, 3971): <<flunk 8192 4880
>>
Child said (2, 3971): <<flunk 8192 6360
>>
Child said (2, 3971): <<flunk 8192 2272
>>
Child said (2, 3971): <<flunk 8192 6288
>>
Child said (2, 3971): <<flunk 8192 992
>>
Child said (2, 3971): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 3971): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=3971 status=0x86
Clean child
Child cleaned
start child pid 4395
Child said (2, 4395): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 4395): <<flunk 8192 6976
>>
Child said (2, 4395): <<flunk 8192 6454
>>
Child said (2, 4395): <<flunk 8192 6422
>>
Child said (2, 4395): <<flunk 2737 1327
>>
Child said (2, 4395): <<flunk 8192 4847
>>
Child said (2, 4395): <<flunk 8192 4424
>>
Child said (2, 4395): <<flunk 2764 1732
>>
Child said (2, 4395): <<flunk 8192 3432
>>
Child said (2, 4395): <<flunk 8192 4056
>>
Child said (2, 4395): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Cache child died pid=4395 status=0x86
Clean child
Child cleaned
start child pid 5044
Child said (2, 5044): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 5044): <<flunk 8192 2272
>>
Child said (2, 5044): <<flunk 8192 2272
>>
Child said (2, 5044): <<flunk 3022 992
>>
Child said (2, 5044): <<flunk 8192 3432
>>
Child said (2, 5044): <<flunk 8192 6974
>>
Child said (2, 5044): <<flunk 8192 2272
>>
Child said (2, 5044): <<flunk 4915 2272
>>
Child said (2, 5044): <<flunk 8192 1984
>>
Child said (2, 5044): <<flunk 8192 3944
>>
Child said (2, 5044): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 5044): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=5044 status=0x86
Clean child
Child cleaned
start child pid 5904
Child said (2, 5904): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 5904): <<flunk 8192 1792
>>
Child said (2, 5904): <<flunk 8192 4880
>>
Child said (2, 5904): <<flunk 8192 7816
>>
Child said (2, 5904): <<flunk 8192 2272
>>
Child said (2, 5904): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 5904): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=5904 status=0x86
Clean child
Child cleaned
start child pid 6388
Child said (2, 6388): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 6388): <<flunk 8192 1136
>>
Child said (2, 6388): <<flunk 8192 7736
>>
Child said (2, 6388): <<flunk 8192 4424
>>
Child said (2, 6388): <<flunk 8192 2272
>>
Child said (2, 6388): <<flunk 8192 5336
>>
Child said (2, 6388): <<flunk 8192 2480
>>
Child said (2, 6388): <<flunk 8192 2480
>>
Child said (2, 6388): <<flunk 8192 3432
>>
Child said (2, 6388): <<flunk 8192 1984
>>
Child said (2, 6388): <<flunk 8192 4056
>>
Child said (2, 6388): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 6388): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=6388 status=0x86
Clean child
Child cleaned
start child pid 6883
Child said (2, 6883): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 6883): <<flunk 4149 3984
>>
Child said (2, 6883): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 6883): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=6883 status=0x86
Clean child
Child cleaned
start child pid 6999
Child said (2, 6999): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 6999): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 6999): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=6999 status=0x86
Clean child
Child cleaned
start child pid 7133
Child said (2, 7133): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 7133): <<flunk 8192 5834
>>
Child said (2, 7133): <<flunk 8192 2272
>>
Child said (2, 7133): <<flunk 8192 3432
>>
Child said (2, 7133): <<flunk 8192 2272
>>
Child said (2, 7133): <<flunk 8192 6288
>>
Child said (2, 7133): <<flunk 8192 6288
>>
Child said (2, 7133): <<flunk 8192 2272
>>
Child said (2, 7133): <<flunk 8192 2272
>>
Child said (2, 7133): <<flunk 8192 6408
>>
Child said (2, 7133): <<flunk 8192 4880
>>
Child said (2, 7133): <<flunk 8192 1792
>>
Child said (2, 7133): <<flunk 8192 3582
>>
Child said (2, 7133): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=7133 status=0x86
Clean child
Child cleaned
start child pid 7663
Child said (2, 7663): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 7663): <<flunk 8192 992
>>
Child said (2, 7663): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 7663): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=7663 status=0x86
Clean child
Child cleaned
start child pid 7822
Child said (2, 7822): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 7822): <<flunk 8192 992
>>
Child said (2, 7822): <<flunk 8192 3432
>>
Child said (2, 7822): <<flunk 8192 6976
>>
Child said (2, 7822): <<flunk 8157 4840
>>
Child said (2, 7822): <<flunk 8192 4056
>>
Child said (2, 7822): <<flunk 8192 1488
>>
Child said (2, 7822): <<flunk 8192 6288
>>
Child said (2, 7822): <<flunk 8192 7772
>>
Child said (2, 7822): <<flunk 8159 7544
>>
Child said (2, 7822): <<flunk 8192 6288
>>
Child said (2, 7822): <<flunk 8192 2596
>>
Child said (2, 7822): <<flunk 8192 6288
>>
Child said (2, 7822): <<flunk 8192 3432
>>
Child said (2, 7822): <<flunk 8192 992
>>
Child said (2, 7822): <<flunk 8192 992
>>
Child said (2, 7822): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 104 (Connection reset by peer)
>>
Cache child died pid=7822 status=0x86
Clean child
Child cleaned
start child pid 8578
Child said (2, 8578): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 8578): <<flunk 8192 1840
>>
Child said (2, 8578): <<flunk 8192 1732
>>
Child said (2, 8578): <<flunk 8192 992
>>
Child said (2, 8578): <<flunk 8192 1984
>>
Child said (2, 8578): <<flunk 8192 6288
>>
Child said (2, 8578): <<flunk 8192 2592
>>
Child said (2, 8578): <<flunk 8192 3432
>>
Child said (2, 8578): <<flunk 8192 2592
>>
Child said (2, 8578): <<flunk 8192 2592
>>
Child said (2, 8578): <<flunk 8192 3209
>>
Child said (2, 8578): <<flunk 8192 6784
>>
Child said (2, 8578): <<flunk 8192 4049
>>
Child said (2, 8578): <<flunk 8192 3084
>>
Child said (2, 8578): <<flunk 8192 4880
>>
Child said (2, 8578): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 8578): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=8578 status=0x86
Clean child
Child cleaned
start child pid 8981
Child said (2, 8981): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 8981): <<flunk 8192 1432
>>
Child said (2, 8981): <<flunk 8192 4424
>>
Child said (2, 8981): <<flunk 8192 992
>>
Child said (2, 8981): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 8981): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=8981 status=0x86
Clean child
Child cleaned
start child pid 9166
Child said (2, 9166): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 9166): <<flunk 8192 7390
>>
Child said (2, 9166): <<flunk 8192 1032
>>
Child said (2, 9166): <<flunk 8192 4384
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 6208 4344
>>
Child said (2, 9166): <<flunk 8192 7320
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 5504
>>
Child said (2, 9166): <<flunk 8192 4384
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 7417
>>
Child said (2, 9166): <<flunk 8144 1704
>>
Child said (2, 9166): <<flunk 6321 4736
>>
Child said (2, 9166): <<flunk 8192 4977
>>
Child said (2, 9166): <<flunk 8192 4880
>>
Child said (2, 9166): <<flunk 8192 6576
>>
Child said (2, 9166): <<flunk 8192 1783
>>
Child said (2, 9166): <<flunk 8192 5821
>>
Child said (2, 9166): <<flunk 8192 7736
>>
Child said (2, 9166): <<flunk 8192 4880
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 3481
>>
Child said (2, 9166): <<flunk 8192 3864
>>
Child said (2, 9166): <<flunk 8192 7884
>>
Child said (2, 9166): <<flunk 8192 5045
>>
Child said (2, 9166): <<flunk 8192 7544
>>
Child said (2, 9166): <<flunk 2933 2440
>>
Child said (2, 9166): <<flunk 8192 5872
>>
Child said (2, 9166): <<flunk 2190 1136
>>
Child said (2, 9166): <<flunk 8192 2480
>>
Child said (2, 9166): <<flunk 5749 1032
>>
Child said (2, 9166): <<flunk 8192 3464
>>
Child said (2, 9166): <<flunk 8192 1732
>>
Child said (2, 9166): <<flunk 4728 1380
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 2440
>>
Child said (2, 9166): <<flunk 8192 6185
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 2440
>>
Child said (2, 9166): <<flunk 8192 3861
>>
Child said (2, 9166): <<flunk 8192 2285
>>
Child said (2, 9166): <<flunk 6026 5872
>>
Child said (2, 9166): <<flunk 8192 4384
>>
Child said (2, 9166): <<flunk 7763 992
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 5336
>>
Child said (2, 9166): <<flunk 8192 2144
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 80
>>
Child said (2, 9166): <<flunk 8192 686
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 4880
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 2936
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 4056
>>
Child said (2, 9166): <<flunk 8192 1488
>>
Child said (2, 9166): <<flunk 8192 5336
>>
Child said (2, 9166): <<flunk 8192 1072
>>
Child said (2, 9166): <<flunk 8192 2520
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 2579
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 5920 4380
>>
Child said (2, 9166): <<flunk 6208 4344
>>
Child said (2, 9166): <<flunk 8192 6049
>>
Child said (2, 9166): <<flunk 7998 1840
>>
Child said (2, 9166): <<flunk 8192 4384
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 5832
>>
Child said (2, 9166): <<flunk 8192 5336
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 5376
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 4371 3432
>>
Child said (2, 9166): <<flunk 8192 2480
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 4880
>>
Child said (2, 9166): <<flunk 8192 2272
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 4880
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 992
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 8192 1732
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 4272
>>
Child said (2, 9166): <<flunk 6208 4344
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 8192 4384
>>
Child said (2, 9166): <<flunk 8192 2440
>>
Child said (2, 9166): <<flunk 8192 1488
>>
Child said (2, 9166): <<flunk 8192 1056
>>
Child said (2, 9166): <<flunk 5493 4880
>>
Child said (2, 9166): <<flunk 7670 1636
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 2024
>>
Child said (2, 9166): <<flunk 2950 2272
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 3566 2936
>>
Child said (2, 9166): <<flunk 8192 7544
>>
Child said (2, 9166): <<flunk 8192 3888
>>
Child said (2, 9166): <<flunk 8192 6288
>>
Child said (2, 9166): <<flunk 8192 904
>>
Child said (2, 9166): <<flunk 8192 3888
>>
Child said (2, 9166): <<flunk 8192 3824
>>
Child said (2, 9166): <<flunk 8192 2667
>>
Child said (2, 9166): <<flunk 8192 3888
>>
Child said (2, 9166): <<flunk 8192 3432
>>
Child said (2, 9166): <<flunk 8192 1984
>>
Child said (2, 9166): <<flunk 5543 1994
>>
Child said (2, 9166): <<flunk 8192 2440
>>
Child said (2, 9166): <<flunk 8192 2440
>>
Child said (2, 9166): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Cache child died pid=9166 status=0x86
Clean child
Child cleaned
start child pid 13591
Child said (2, 13591): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 13591): <<flunk 8192 1984
>>
Child said (2, 13591): <<flunk 8192 1984
>>
Child said (2, 13591): <<flunk 8192 4093
>>
Child said (2, 13591): <<flunk 5135 2019
>>
Child said (2, 13591): <<flunk 5418 2272
>>
Child said (2, 13591): <<flunk 8192 4880
>>
Child said (2, 13591): <<flunk 5418 2272
>>
Child said (2, 13591): <<flunk 8192 2194
>>
Child said (2, 13591): <<flunk 8192 5872
>>
Child said (2, 13591): <<flunk 8192 5679
>>
Child said (2, 13591): <<flunk 8192 2592
>>
Child said (2, 13591): <<flunk 8192 2592
>>
Child said (2, 13591): <<flunk 8192 6021
>>
Child said (2, 13591): <<flunk 8192 3649
>>
Child said (2, 13591): <<flunk 8192 2194
>>
Child said (2, 13591): <<flunk 8192 2440
>>
Child said (2, 13591): <<flunk 8192 1984
>>
Child said (2, 13591): <<flunk 7652 992
>>
Child said (2, 13591): <<flunk 8192 2221
>>
Child said (2, 13591): <<flunk 8192 992
>>
Child said (2, 13591): <<flunk 5391 2272
>>
Child said (2, 13591): <<flunk 8192 5376
>>
Child said (2, 13591): <<flunk 8192 1984
>>
Child said (2, 13591): <<flunk 2425 992
>>
Child said (2, 13591): <<flunk 5138 1992
>>
Child said (2, 13591): <<flunk 5415 2272
>>
Child said (2, 13591): <<flunk 8192 7736
>>
Child said (2, 13591): <<flunk 8192 6288
>>
Child said (2, 13591): <<flunk 8192 7736
>>
Child said (2, 13591): <<flunk 8192 6784
>>
Child said (2, 13591): <<flunk 5391 2272
>>
Child said (2, 13591): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 13591): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=13591 status=0x86
Clean child
Child cleaned
start child pid 14902
Child said (2, 14902): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 14902): <<flunk 8192 7736
>>
Child said (2, 14902): <<flunk 8192 5336
>>
Child said (2, 14902): <<flunk 5388 2272
>>
Child said (2, 14902): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 14902): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=14902 status=0x86
Clean child
Child cleaned
start child pid 15181
Child said (2, 15181): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 15181): <<flunk 8192 4762
>>
Child said (2, 15181): <<flunk 8192 6288
>>
Child said (2, 15181): <<flunk 8192 3676
>>
Child said (2, 15181): <<flunk 8192 7868
>>
Child said (2, 15181): <<flunk 8192 1792
>>
Child said (2, 15181): <<flunk 8192 6288
>>
Child said (2, 15181): <<flunk 5138 1992
>>
Child said (2, 15181): <<flunk 5391 2272
>>
Child said (2, 15181): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 15181): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=15181 status=0x86
Clean child
Child cleaned
start child pid 15835
Child said (2, 15835): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 15835): <<flunk 8192 7736
>>
Child said (2, 15835): <<flunk 8192 4056
>>
Cache child died pid=15835 status=0x8b
Clean child
Child cleaned
start child pid 16146
Child said (2, 16146): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16146): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=16146 status=0x86
Clean child
Child cleaned
start child pid 16403
Child said (2, 16403): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16403): <<flunk 8192 6288
>>
Child said (2, 16403): <<flunk 8192 4880
>>
Child said (2, 16403): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 16403): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=16403 status=0x86
Clean child
Child cleaned
start child pid 16606
Child said (2, 16606): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16606): <<flunk 8192 5872
>>
Child said (2, 16606): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 16606): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=16606 status=0x86
Clean child
Child cleaned
start child pid 16843
Child said (2, 16843): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 16843): <<flunk 8192 1984
>>
Child said (2, 16843): <<flunk 8192 7736
>>
Child said (2, 16843): <<flunk 8192 1984
>>
Child said (2, 16843): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=16843 status=0x86
Clean child
Child cleaned
start child pid 17060
Child said (2, 17060): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 17060): <<flunk 8192 992
>>
Child said (2, 17060): <<flunk 8192 7736
>>
Child said (2, 17060): <<flunk 8192 1984
>>
Child said (2, 17060): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=17060 status=0x86
Clean child
Child cleaned
start child pid 17605
Child said (2, 17605): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 17605): <<flunk 8192 992
>>
Child said (2, 17605): <<flunk 8192 7736
>>
Child said (2, 17605): <<flunk 8192 6408
>>
Child said (2, 17605): <<flunk 5138 1992
>>
Child said (2, 17605): <<flunk 8192 1426
>>
Child said (2, 17605): <<flunk 5418 2272
>>
Child said (2, 17605): <<flunk 5138 1998
>>
Child said (2, 17605): <<flunk 8192 992
>>
Child said (2, 17605): <<flunk 8192 3216
>>
Child said (2, 17605): <<flunk 8192 992
>>
Child said (2, 17605): <<flunk 8192 2003
>>
Child said (2, 17605): <<flunk 8192 2003
>>
Child said (2, 17605): <<flunk 8192 6864
>>
Child said (2, 17605): <<flunk 8192 1732
>>
Child said (2, 17605): <<flunk 8192 2272
>>
Child said (2, 17605): <<flunk 8192 2272
>>
Child said (2, 17605): <<flunk 8192 2480
>>
Child said (2, 17605): <<flunk 2440 704
>>
Child said (2, 17605): <<flunk 8192 6784
>>
Child said (2, 17605): <<flunk 8192 1984
>>
Child said (2, 17605): <<flunk 8192 2272
>>
Child said (2, 17605): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 17605): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=17605 status=0x86
Clean child
Child cleaned
start child pid 18768
Child said (2, 18768): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 18768): <<flunk 8192 7280
>>
Child said (2, 18768): <<flunk 6963 3016
>>
Child said (2, 18768): <<flunk 8192 5872
>>
Child said (2, 18768): <<flunk 8192 3328
>>
Child said (2, 18768): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=18768 status=0x86
Clean child
Child cleaned
start child pid 19033
Child said (2, 19033): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19033): <<flunk 8192 5336
>>
Child said (2, 19033): <<flunk 8192 4056
>>
Child said (2, 19033): <<flunk 8192 4056
>>
Child said (2, 19033): <<flunk 8192 2272
>>
Child said (2, 19033): <<flunk 8192 2272
>>
Child said (2, 19033): <<flunk 8192 2272
>>
Child said (2, 19033): <<flunk 8192 3732
>>
Child said (2, 19033): <<flunk 8192 2512
>>
Child said (2, 19033): <<flunk 8192 2080
>>
Child said (2, 19033): <<flunk 8192 2080
>>
Child said (2, 19033): <<flunk 8192 3432
>>
Child said (2, 19033): <<flunk 5109 3432
>>
Child said (2, 19033): <<flunk 8192 2240
>>
Child said (2, 19033): <<flunk 8192 6336
>>
Child said (2, 19033): <<flunk 8192 6336
>>
Child said (2, 19033): <<flunk 7921 7360
>>
Child said (2, 19033): <<flunk 8192 2080
>>
Child said (2, 19033): <<flunk 8192 2080
>>
Child said (2, 19033): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 19033): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=19033 status=0x86
Clean child
Child cleaned
start child pid 19182
Child said (2, 19182): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19182): <<flunk 8192 4056
>>
Child said (2, 19182): <<flunk 8192 4056
>>
Child said (2, 19182): <<flunk 8192 2592
>>
Child said (2, 19182): <<flunk 8192 2592
>>
Child said (2, 19182): <<flunk 6969 992
>>
Child said (2, 19182): <<flunk 8192 1504
>>
Child said (2, 19182): <<flunk 6274 1593
>>
Child said (2, 19182): <<flunk 8192 2080
>>
Child said (2, 19182): <<flunk 8192 628
>>
Child said (2, 19182): <<flunk 8192 628
>>
Child said (2, 19182): <<flunk 8192 7756
>>
Child said (2, 19182): <<flunk 8192 3496
>>
Child said (2, 19182): <<flunk 8192 2696
>>
Child said (2, 19182): <<flunk 8192 2696
>>
Child said (2, 19182): <<flunk 8192 2080
>>
Child said (2, 19182): <<flunk 8192 2080
>>
Child said (2, 19182): <<flunk 8192 2272
>>
Child said (2, 19182): <<flunk 8192 2516
>>
Child said (2, 19182): <<flunk 8192 4880
>>
Child said (2, 19182): <<flunk 8192 1252
>>
Child said (2, 19182): <<flunk 8192 4404
>>
Child said (2, 19182): <<flunk 8192 2272
>>
Child said (2, 19182): <<flunk 8192 2272
>>
Child said (2, 19182): <<flunk 5029 5028
>>
Child said (2, 19182): <<flunk 8192 2545
>>
Child said (2, 19182): <<flunk 8192 2708
>>
Child said (2, 19182): <<flunk 8192 2708
>>
Child said (2, 19182): <<flunk 8192 5560
>>
Child said (2, 19182): <<flunk 8192 5560
>>
Child said (2, 19182): <<flunk 8192 1204
>>
Child said (2, 19182): <<flunk 8192 2708
>>
Child said (2, 19182): <<flunk 8192 1177
>>
Child said (2, 19182): <<flunk 8192 2280
>>
Child said (2, 19182): <<flunk 8192 2708
>>
Child said (2, 19182): <<flunk 8192 704
>>
Child said (2, 19182): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=19182 status=0x86
Clean child
Child cleaned
start child pid 19449
Child said (2, 19449): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19449): <<flunk 8192 3432
>>
Child said (2, 19449): <<flunk 8192 1732
>>
Child said (2, 19449): <<flunk 8192 3464
>>
Child said (2, 19449): <<flunk 8192 1732
>>
Child said (2, 19449): <<flunk 8192 2272
>>
Child said (2, 19449): <<flunk 8192 6245
>>
Child said (2, 19449): <<flunk 8192 976
>>
Child said (2, 19449): <<flunk 8192 8189
>>
Child said (2, 19449): <<flunk 8192 976
>>
Child said (2, 19449): <<flunk 8192 3432
>>
Child said (2, 19449): <<flunk 8192 3432
>>
Child said (2, 19449): <<flunk 8192 2582
>>
Child said (2, 19449): <<flunk 8192 2080
>>
Child said (2, 19449): <<flunk 8192 1792
>>
Child said (2, 19449): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 19449): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=19449 status=0x86
Clean child
Child cleaned
start child pid 19716
Child said (2, 19716): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 19716): <<flunk 8192 2080
>>
Child said (2, 19716): <<flunk 8192 2002
>>
Child said (2, 19716): <<flunk 8192 6288
>>
Child said (2, 19716): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Cache child died pid=19716 status=0x86
Clean child
Child cleaned
start child pid 20073
Child said (2, 20073): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 20073): <<flunk 8192 467
>>
Child said (2, 20073): <<flunk 8192 4056
>>
Child said (2, 20073): <<flunk 8192 4056
flunk 8192 4056
>>
Child said (2, 20073): <<flunk 8192 4056
>>
Child said (2, 20073): <<flunk 8192 4056
>>
Child said (2, 20073): <<flunk 8192 6445
>>
Child said (2, 20073): <<flunk 8192 244
>>
Child said (2, 20073): <<flunk 8192 7200
>>
Child said (2, 20073): <<flunk 8192 2464
>>
Child said (2, 20073): <<flunk 8192 2080
>>
Child said (2, 20073): <<flunk 8192 3776
>>
Child said (2, 20073): <<flunk 8192 3776
>>
Child said (2, 20073): <<flunk 8192 3776
>>
Child said (2, 20073): <<flunk 8192 3776
>>
Child said (2, 20073): <<flunk 8192 3776
>>
Child said (2, 20073): <<flunk 8192 2272
>>
Child said (2, 20073): <<flunk 8192 4056
>>
Child said (2, 20073): <<flunk 8192 5760
>>
Child said (2, 20073): <<flunk 8192 992
>>
Child said (2, 20073): <<flunk 8192 5960
>>
Child said (2, 20073): <<flunk 8192 5504
>>
Child said (2, 20073): <<flunk 8192 6652
>>
Child said (2, 20073): <<flunk 8192 3432
>>
Child said (2, 20073): <<flunk 8192 3432
>>
Child said (2, 20073): <<flunk 8192 549
>>
Child said (2, 20073): <<flunk 8192 576
>>
Child said (2, 20073): <<flunk 8192 576
>>
Child said (2, 20073): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Child said (2, 20073): <<  errno = 104 (Connection reset by peer)
>>
Child said (2, 20073): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=20073 status=0x86
Clean child
Child cleaned
start child pid 20555
Child said (2, 20555): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 20555): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=20555 status=0x86
Clean child
Child cleaned
start child pid 20814
Child said (2, 20814): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 20814): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=20814 status=0x86
Clean child
Child cleaned
start child pid 21073
Child said (2, 21073): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 21073): <<flunk 8192 6288
>>
Child said (2, 21073): <<flunk 8192 3084
>>
Child said (2, 21073): <<flunk 8192 3004
>>
Child said (2, 21073): <<flunk 8192 4868
>>
Child said (2, 21073): <<flunk 8192 5032
>>
Child said (2, 21073): <<flunk 8192 4056
>>
Child said (2, 21073): <<flunk 8192 4056
>>
Child said (2, 21073): <<flunk 8192 4056
>>
Child said (2, 21073): <<flunk 8192 4056
>>
Child said (2, 21073): <<flunk 8192 4056
>>
Child said (2, 21073): <<flunk 8192 2462
>>
Child said (2, 21073): <<flunk 8192 2480
>>
Child said (2, 21073): <<flunk 8192 576
>>
Child said (2, 21073): <<flunk 8192 549
>>
Child said (2, 21073): <<flunk 8192 549
>>
Child said (2, 21073): <<flunk 8192 549
>>
Child said (2, 21073): <<flunk 8192 576
>>
Child said (2, 21073): <<flunk 8192 1704
>>
Child said (2, 21073): <<flunk 8192 5556
>>
Child said (2, 21073): <<flunk 8192 2280
>>
Child said (2, 21073): <<flunk 8192 1984
>>
Child said (2, 21073): <<flunk 8192 1858
>>
Child said (2, 21073): <<flunk 8192 7942
>>
Child said (2, 21073): <<flunk 8192 7736
>>
Child said (2, 21073): <<Assert error in CNT_Session(), cache_center.c line 913:
  Condition(!isnan(w->used)) not true.
>>
Child said (2, 21073): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=21073 status=0x86
Clean child
Child cleaned
start child pid 21506
Child said (2, 21506): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 21506): <<flunk 8192 168
>>
Child said (2, 21506): <<flunk 7396 244
>>
Child said (2, 21506): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 21506): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=21506 status=0x86
Clean child
Child cleaned
start child pid 21726
Child said (2, 21726): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 21726): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 21726): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=21726 status=0x86
Clean child
Child cleaned
start child pid 21874
Child said (2, 21874): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 21874): <<flunk 8192 1991
>>
Child said (2, 21874): <<flunk 8192 1714
>>
Child said (2, 21874): <<flunk 8192 6288
>>
Child said (2, 21874): <<flunk 3167 628
>>
Child said (2, 21874): <<flunk 8192 2024
>>
Child said (2, 21874): <<flunk 8192 2024
>>
Child said (2, 21874): <<flunk 8192 2272
>>
Child said (2, 21874): <<flunk 8192 4056
>>
Child said (2, 21874): <<flunk 2949 992
>>
Child said (2, 21874): <<flunk 8192 2272
>>
Child said (2, 21874): <<flunk 8192 3432
>>
Child said (2, 21874): <<flunk 8192 3676
>>
Child said (2, 21874): <<flunk 5698 2272
>>
Child said (2, 21874): <<flunk 8192 3432
>>
Child said (2, 21874): <<flunk 8192 7736
>>
Child said (2, 21874): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 21874): <<  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=21874 status=0x86
Clean child
Child cleaned
start child pid 22419
Child said (2, 22419): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 22419): <<flunk 8192 3432
>>
Child said (2, 22419): <<flunk 3102 1984
>>
Child said (2, 22419): <<flunk 8192 7736
>>
Child said (2, 22419): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Child said (2, 22419): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=22419 status=0x86
Clean child
Child cleaned
start child pid 22852
Child said (2, 22852): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 22852): <<flunk 3118 2272
>>
Child said (2, 22852): <<flunk 1504 536
>>
Child said (2, 22852): <<flunk 1504 536
>>
Child said (2, 22852): <<flunk 8192 4384
>>
Child said (2, 22852): <<flunk 8192 3432
>>
Child said (2, 22852): <<flunk 8192 4056
>>
Child said (2, 22852): <<flunk 8192 4384
>>
Child said (2, 22852): <<flunk 8192 4056
>>
Child said (2, 22852): <<flunk 3088 2272
>>
Child said (2, 22852): <<flunk 8192 1432
>>
Child said (2, 22852): <<flunk 8192 4624
>>
Child said (2, 22852): <<flunk 8192 4056
>>
Child said (2, 22852): <<flunk 8192 5552
>>
Child said (2, 22852): <<flunk 8192 2272
>>
Child said (2, 22852): <<flunk 8192 4880
>>
Child said (2, 22852): <<flunk 8192 7280
>>
Child said (2, 22852): <<flunk 8192 992
>>
Child said (2, 22852): <<flunk 8192 4056
>>
Child said (2, 22852): <<flunk 8192 2080
>>
Child said (2, 22852): <<flunk 3118 2272
>>
Child said (2, 22852): <<flunk 8192 3888
>>
Child said (2, 22852): <<flunk 3100 2272
>>
Child said (2, 22852): <<flunk 8192 3888
>>
Child said (2, 22852): <<flunk 8192 1415
>>
Child said (2, 22852): <<flunk 8192 6864
>>
Child said (2, 22852): <<flunk 8192 3968
>>
Child said (2, 22852): <<flunk 4993 1032
>>
Child said (2, 22852): <<flunk 3100 2272
>>
Child said (2, 22852): <<flunk 3091 2272
>>
Child said (2, 22852): <<flunk 8192 3432
>>
Child said (2, 22852): <<flunk 3113 2272
>>
Child said (2, 22852): <<flunk 8192 2272
>>
Child said (2, 22852): <<flunk 8192 2272
>>
Child said (2, 22852): <<flunk 8192 1984
>>
Child said (2, 22852): <<flunk 8192 7401
>>
Child said (2, 22852): <<flunk 8192 2272
>>
Child said (2, 22852): <<flunk 8192 4880
>>
Child said (2, 22852): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 22852): <<  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=22852 status=0x86
Clean child
Child cleaned
start child pid 24722
Child said (2, 24722): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 24722): <<flunk 8192 2272
>>
Child said (2, 24722): <<flunk 3165 2272
>>
Child said (2, 24722): <<flunk 2903 2440
>>
Child said (2, 24722): <<flunk 8192 6784
>>
Child said (2, 24722): <<flunk 8192 2520
>>
Child said (2, 24722): <<flunk 8192 2024
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 8192 2080
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 3116 2272
>>
Child said (2, 24722): <<flunk 2903 992
>>
Child said (2, 24722): <<flunk 8192 2596
>>
Child said (2, 24722): <<flunk 8192 6288
>>
Child said (2, 24722): <<flunk 8192 992
>>
Child said (2, 24722): <<flunk 8192 3968
>>
Child said (2, 24722): <<flunk 3138 2272
>>
Child said (2, 24722): <<flunk 8192 6288
>>
Child said (2, 24722): <<flunk 8192 5706
>>
Child said (2, 24722): <<flunk 3123 2272
>>
Child said (2, 24722): <<flunk 8192 1984
>>
Child said (2, 24722): <<flunk 8192 80
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 8192 4920
>>
Child said (2, 24722): <<flunk 8192 7345
>>
Child said (2, 24722): <<flunk 8192 1914
>>
Child said (2, 24722): <<flunk 3089 2272
>>
Child said (2, 24722): <<flunk 8192 4424
>>
Child said (2, 24722): <<flunk 8192 7776
>>
Child said (2, 24722): <<flunk 8192 1984
>>
Child said (2, 24722): <<flunk 8192 1984
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 8192 3732
>>
Child said (2, 24722): <<flunk 8192 6084
>>
Child said (2, 24722): <<flunk 8192 3432
>>
Child said (2, 24722): <<flunk 8192 992
>>
Child said (2, 24722): <<flunk 3116 2176
>>
Child said (2, 24722): <<flunk 8192 5376
>>
Child said (2, 24722): <<flunk 8192 7736
>>
Child said (2, 24722): <<flunk 8192 1984
>>
Child said (2, 24722): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 24722): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=24722 status=0x86
Clean child
Child cleaned
start child pid 26168
Child said (2, 26168): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 26168): <<flunk 8192 2440
>>
Child said (2, 26168): <<flunk 8192 48
>>
Child said (2, 26168): <<flunk 8192 1528
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 6002
>>
Child said (2, 26168): <<flunk 8192 1984
>>
Child said (2, 26168): <<flunk 1852 576
>>
Child said (2, 26168): <<flunk 3085 2272
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 3115 2272
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 5667 4464
>>
Child said (2, 26168): <<flunk 3115 2272
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 8192 3472
>>
Child said (2, 26168): <<flunk 8192 5336
>>
Child said (2, 26168): <<flunk 8192 6864
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 4384
>>
Child said (2, 26168): <<flunk 8192 4920
>>
Child said (2, 26168): <<flunk 7382 5912
>>
Child said (2, 26168): <<flunk 8192 3928
>>
Child said (2, 26168): <<flunk 8192 4624
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 1496
>>
Child said (2, 26168): <<flunk 8192 80
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 3969
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 2352
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 2936
>>
Child said (2, 26168): <<flunk 8192 6629
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 80
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 7380
>>
Child said (2, 26168): <<flunk 8192 4978
>>
Child said (2, 26168): <<flunk 8192 7375
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 810
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 3129 2272
>>
Child said (2, 26168): <<flunk 7560 3652
>>
Child said (2, 26168): <<flunk 8192 2516
>>
Child said (2, 26168): <<flunk 8192 6652
>>
Child said (2, 26168): <<flunk 8192 1056
>>
Child said (2, 26168): <<flunk 8192 1792
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 1932
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 5608
>>
Child said (2, 26168): <<flunk 3992 3930
>>
Child said (2, 26168): <<flunk 8192 6992
>>
Child said (2, 26168): <<flunk 8192 2840
>>
Child said (2, 26168): <<flunk 8192 5872
>>
Child said (2, 26168): <<flunk 8192 1984
>>
Child said (2, 26168): <<flunk 8192 488
>>
Child said (2, 26168): <<flunk 8192 5436
>>
Child said (2, 26168): <<flunk 8192 1996
>>
Child said (2, 26168): <<flunk 8192 3464
>>
Child said (2, 26168): <<flunk 8192 3968
>>
Child said (2, 26168): <<flunk 3094 2272
>>
Child said (2, 26168): <<flunk 3095 1732
>>
Child said (2, 26168): <<flunk 3124 1732
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 4861 1032
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 7736
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 6784
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 1792
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 7978 7360
>>
Child said (2, 26168): <<flunk 3124 2482
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 7320
>>
Child said (2, 26168): <<flunk 5210 2592
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 2592
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 48
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 3101 2272
>>
Child said (2, 26168): <<flunk 8192 8079
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 40
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 3888
>>
Child said (2, 26168): <<flunk 8192 1732
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 5832
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 6455
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 1984
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 8192 6408
>>
Child said (2, 26168): <<flunk 8192 6408
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 7736
>>
Child said (2, 26168): <<flunk 8192 5376
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 4168
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 5418 2272
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 5388 2272
>>
Child said (2, 26168): <<flunk 8192 4880
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 7318
>>
Child said (2, 26168): <<flunk 8192 5872
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 5391 2272
>>
Child said (2, 26168): <<flunk 5418 2272
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 8192 6408
>>
Child said (2, 26168): <<flunk 8192 6408
>>
Child said (2, 26168): <<flunk 8192 6408
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 5376
>>
Child said (2, 26168): <<flunk 8192 2440
>>
Child said (2, 26168): <<flunk 8192 7736
>>
Child said (2, 26168): <<flunk 3129 2272
>>
Child said (2, 26168): <<flunk 5805 1528
>>
Child said (2, 26168): <<flunk 8192 4384
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 5388 2272
>>
Child said (2, 26168): <<flunk 5388 2272
>>
Child said (2, 26168): <<flunk 8192 2480
>>
Child said (2, 26168): <<flunk 8192 7776
>>
Child said (2, 26168): <<flunk 5388 2272
>>
Child said (2, 26168): <<flunk 8192 6824
>>
Child said (2, 26168): <<flunk 8192 4756
>>
Child said (2, 26168): <<flunk 8192 2592
>>
Child said (2, 26168): <<flunk 8192 1732
>>
Child said (2, 26168): <<flunk 8192 7868
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 5138 1992
>>
Child said (2, 26168): <<flunk 8192 1984
>>
Child said (2, 26168): <<flunk 8192 4384
>>
Child said (2, 26168): <<flunk 8192 992
>>
Child said (2, 26168): <<flunk 8192 4424
>>
Child said (2, 26168): <<flunk 8192 5504
>>
Child said (2, 26168): <<flunk 8192 6288
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 1984
>>
Child said (2, 26168): <<flunk 2836 2272
>>
Child said (2, 26168): <<flunk 3164 2800
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 5114
>>
Child said (2, 26168): <<flunk 8192 5087
>>
Child said (2, 26168): <<flunk 4606 3944
>>
Child said (2, 26168): <<flunk 8192 1840
>>
Child said (2, 26168): <<flunk 8192 2080
>>
Child said (2, 26168): <<flunk 8192 4056
>>
Child said (2, 26168): <<flunk 8192 3432
>>
Child said (2, 26168): <<flunk 8192 3922
>>
Child said (2, 26168): <<flunk 8192 5784
>>
Child said (2, 26168): <<flunk 8192 2600
>>
Child said (2, 26168): <<flunk 8192 1359
>>
Child said (2, 26168): <<flunk 8192 3330
>>
Child said (2, 26168): <<flunk 8192 5114
>>
Child said (2, 26168): <<flunk 8192 2272
>>
Child said (2, 26168): <<flunk 3088 2272
>>
Child said (2, 26168): <<flunk 5673 2732
>>
Child said (2, 26168): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 107 (Transport endpoint is not connected)
>>
Child not responding to ping
Cache child died pid=26168 status=0x86
Clean child
Child cleaned
start child pid 30850
Child said (2, 30850): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 30850): <<flunk 8192 7734
>>
Child said (2, 30850): <<flunk 8192 6784
>>
Child said (2, 30850): <<flunk 8192 4624
>>
Child said (2, 30850): <<flunk 8192 2732
>>
Child said (2, 30850): <<flunk 8192 6976
>>
Child said (2, 30850): <<flunk 8192 1704
>>
Child said (2, 30850): <<flunk 8192 6603
>>
Child said (2, 30850): <<flunk 8192 4756
>>
Child said (2, 30850): <<flunk 8192 3944
>>
Child said (2, 30850): <<flunk 8192 2024
>>
Child said (2, 30850): <<flunk 8192 2080
>>
Child said (2, 30850): <<flunk 8192 2532
>>
Child said (2, 30850): <<flunk 8192 5516
>>
Child said (2, 30850): <<flunk 8192 2080
>>
Child said (2, 30850): <<flunk 8192 1948
>>
Child said (2, 30850): <<flunk 6600 2272
>>
Child said (2, 30850): <<flunk 8192 2732
>>
Child said (2, 30850): <<flunk 8192 2210
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 8192 3534
>>
Child said (2, 30850): <<flunk 8192 1984
>>
Child said (2, 30850): <<flunk 8192 3164
>>
Child said (2, 30850): <<flunk 8192 1136
>>
Child said (2, 30850): <<flunk 8192 2516
>>
Child said (2, 30850): <<flunk 8192 7737
>>
Child said (2, 30850): <<flunk 8192 4056
>>
Child said (2, 30850): <<flunk 8192 4056
>>
Child said (2, 30850): <<flunk 8192 4056
>>
Child said (2, 30850): <<flunk 8192 4056
>>
Child said (2, 30850): <<flunk 8192 2532
>>
Child said (2, 30850): <<flunk 8192 3976
>>
Child said (2, 30850): <<flunk 8192 992
>>
Child said (2, 30850): <<flunk 8192 7776
>>
Child said (2, 30850): <<flunk 8192 1248
>>
Child said (2, 30850): <<flunk 8192 1248
>>
Child said (2, 30850): <<flunk 8192 2840
>>
Child said (2, 30850): <<flunk 8192 3732
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 3398 3384
>>
Child said (2, 30850): <<flunk 3261 3251
>>
Child said (2, 30850): <<flunk 6568 3251
>>
Child said (2, 30850): <<flunk 6725 3384
>>
Child said (2, 30850): <<flunk 3394 3384
>>
Child said (2, 30850): <<flunk 8192 2080
>>
Child said (2, 30850): <<flunk 8192 4840
>>
Child said (2, 30850): <<flunk 6573 2272
>>
Child said (2, 30850): <<flunk 7328 1056
>>
Child said (2, 30850): <<flunk 8192 2440
>>
Child said (2, 30850): <<flunk 8192 6328
>>
Child said (2, 30850): <<flunk 8192 1668
>>
Child said (2, 30850): <<flunk 8192 3991
>>
Child said (2, 30850): <<flunk 8192 7776
>>
Child said (2, 30850): <<flunk 8192 1792
>>
Child said (2, 30850): <<flunk 1842 1056
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 8192 812
>>
Child said (2, 30850): <<flunk 8192 6929
>>
Child said (2, 30850): <<flunk 8192 5784
>>
Child said (2, 30850): <<flunk 6568 3784
>>
Child said (2, 30850): <<flunk 8192 3928
>>
Child said (2, 30850): <<flunk 6728 3944
>>
Child said (2, 30850): <<flunk 8192 2336
>>
Child said (2, 30850): <<flunk 8192 4903
>>
Child said (2, 30850): <<flunk 8192 6288
>>
Child said (2, 30850): <<flunk 8192 2520
>>
Child said (2, 30850): <<flunk 8192 2532
>>
Child said (2, 30850): <<flunk 8192 2080
>>
Child said (2, 30850): <<flunk 8192 1732
>>
Child said (2, 30850): <<flunk 8192 4529
>>
Child said (2, 30850): <<flunk 8192 2080
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 8192 6436
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 1792
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 4056
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 8192 2532
>>
Child said (2, 30850): <<flunk 8192 2106
>>
Child said (2, 30850): <<flunk 8192 6436
>>
Child said (2, 30850): <<flunk 8192 3852
>>
Child said (2, 30850): <<flunk 8192 5866
>>
Child said (2, 30850): <<flunk 8192 5664
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 1792
>>
Child said (2, 30850): <<flunk 8192 3432
>>
Child said (2, 30850): <<flunk 8192 364
>>
Child said (2, 30850): <<flunk 8192 391
>>
Child said (2, 30850): <<flunk 8192 7379
>>
Child said (2, 30850): <<flunk 4357 1806
>>
Child said (2, 30850): <<flunk 8192 2532
>>
Child said (2, 30850): <<flunk 8192 3497
>>
Child said (2, 30850): <<flunk 8192 2272
>>
Child said (2, 30850): <<flunk 8192 6652
>>
Child said (2, 30850): <<flunk 1881 1792
>>
Child said (2, 30850): <<flunk 8192 1792
>>
Child said (2, 30850): <<flunk 8192 1984
>>
Child said (2, 30850): <<flunk 8192 6634
>>
Child said (2, 30850): <<flunk 8192 2516
>>
Child said (2, 30850): <<flunk 8192 7868
>>
Child said (2, 30850): <<flunk 8192 6652
>>
Child said (2, 30850): <<flunk 8192 6652
>>
Child said (2, 30850): <<flunk 8192 4648
>>
Child said (2, 30850): <<flunk 8192 5855
>>
Child said (2, 30850): <<flunk 8192 6063
>>
Child said (2, 30850): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=30850 status=0x86
Clean child
Child cleaned
start child pid 32350
Child said (2, 32350): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 32350): <<flunk 8192 2272
>>
Child said (2, 32350): <<flunk 8192 2272
>>
Child said (2, 32350): <<flunk 8192 3783
>>
Child said (2, 32350): <<flunk 8143 732
>>
Child said (2, 32350): <<flunk 8192 5760
>>
Child said (2, 32350): <<flunk 8192 5584
>>
Child said (2, 32350): <<flunk 8192 2080
>>
Child said (2, 32350): <<flunk 8192 508
>>
Child said (2, 32350): <<flunk 8192 508
>>
Child said (2, 32350): <<flunk 8192 535
>>
Child said (2, 32350): <<flunk 8192 535
>>
Child said (2, 32350): <<flunk 8192 2272
>>
Child said (2, 32350): <<flunk 8192 992
>>
Child said (2, 32350): <<flunk 8192 6976
>>
Child said (2, 32350): <<flunk 8192 6976
>>
Child said (2, 32350): <<flunk 8192 6976
>>
Child said (2, 32350): <<flunk 8192 6976
>>
Child said (2, 32350): <<flunk 8192 3630
>>
Child said (2, 32350): <<flunk 8192 5704
>>
Child said (2, 32350): <<flunk 8192 3968
>>
Child said (2, 32350): <<flunk 8192 2272
>>
Child said (2, 32350): <<flunk 8192 5557
>>
Child said (2, 32350): <<flunk 6318 2272
>>
Child said (2, 32350): <<flunk 8192 5737
>>
Child said (2, 32350): <<flunk 8192 2480
>>
Child said (2, 32350): <<flunk 8192 5192
>>
Child said (2, 32350): <<flunk 1948 992
>>
Child said (2, 32350): <<flunk 3398 992
>>
Child said (2, 32350): <<flunk 3368 992
>>
Child said (2, 32350): <<flunk 8192 7736
>>
Child said (2, 32350): <<flunk 8192 6652
>>
Child said (2, 32350): <<flunk 8192 7779
>>
Child said (2, 32350): <<flunk 1464 1312
>>
Child said (2, 32350): <<flunk 8192 3944
>>
Child said (2, 32350): <<flunk 8192 3944
>>
Child said (2, 32350): <<flunk 8192 3024
>>
Child said (2, 32350): <<flunk 8192 6010
>>
Child said (2, 32350): <<flunk 6701 3944
>>
Child said (2, 32350): <<flunk 6565 3784
>>
Child said (2, 32350): <<flunk 8192 366
>>
Child said (2, 32350): <<flunk 8192 4056
>>
Child said (2, 32350): <<flunk 8192 2182
>>
Child said (2, 32350): <<flunk 8192 6976
>>
Child said (2, 32350): <<flunk 3981 3016
>>
Child said (2, 32350): <<flunk 8192 2080
>>
Child said (2, 32350): <<flunk 6595 2272
>>
Child said (2, 32350): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 32350): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=32350 status=0x86
Clean child
Child cleaned
start child pid 552
Child said (2, 552): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 552): <<flunk 8192 6848
>>
Child said (2, 552): <<flunk 8192 3432
>>
Child said (2, 552): <<flunk 6585 3432
>>
Child said (2, 552): <<flunk 8192 4056
>>
Child said (2, 552): <<flunk 8192 6652
>>
Child said (2, 552): <<flunk 8192 6288
>>
Child said (2, 552): <<flunk 8192 1680
>>
Child said (2, 552): <<flunk 8192 1680
>>
Child said (2, 552): <<flunk 8192 3928
>>
Child said (2, 552): <<flunk 8192 4880
>>
Child said (2, 552): <<flunk 8192 6976
>>
Child said (2, 552): <<flunk 8192 276
>>
Child said (2, 552): <<flunk 8192 276
>>
Child said (2, 552): <<flunk 8192 2272
>>
Child said (2, 552): <<flunk 6701 4056
>>
Child said (2, 552): <<flunk 8192 1975
>>
Child said (2, 552): <<flunk 8192 6652
>>
Child said (2, 552): <<flunk 6695 4056
>>
Child said (2, 552): <<flunk 8192 7776
>>
Child said (2, 552): <<flunk 8192 7736
>>
Child said (2, 552): <<flunk 8192 2272
>>
Child said (2, 552): <<flunk 8192 7736
>>
Child said (2, 552): <<flunk 8192 2080
>>
Child said (2, 552): <<flunk 8192 2080
>>
Child said (2, 552): <<flunk 8192 4056
>>
Child said (2, 552): <<flunk 8192 2272
>>
Child said (2, 552): <<flunk 8192 2182
>>
Child said (2, 552): <<flunk 8192 2592
>>
Child said (2, 552): <<flunk 8192 2080
>>
Child said (2, 552): <<flunk 8192 992
>>
Child said (2, 552): <<flunk 8192 5993
>>
Child said (2, 552): <<flunk 8192 1984
>>
Child said (2, 552): <<flunk 6720 4056
>>
Child said (2, 552): <<flunk 8192 5504
>>
Child said (2, 552): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 552): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=552 status=0x86
Clean child
Child cleaned
start child pid 991
Child said (2, 991): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 991): <<flunk 8192 3532
>>
Child said (2, 991): <<flunk 8192 2272
>>
Child said (2, 991): <<flunk 8192 4544
>>
Child said (2, 991): <<flunk 8192 5680
>>
Child said (2, 991): <<flunk 8192 2688
>>
Child said (2, 991): <<flunk 8192 5336
>>
Child said (2, 991): <<flunk 8192 747
>>
Child said (2, 991): <<flunk 8192 4384
>>
Child said (2, 991): <<flunk 8192 2272
>>
Child said (2, 991): <<flunk 8192 2232
>>
Child said (2, 991): <<flunk 8192 5993
>>
Child said (2, 991): <<flunk 8192 2732
>>
Child said (2, 991): <<flunk 8192 4624
>>
Child said (2, 991): <<flunk 8192 1560
>>
Child said (2, 991): <<flunk 8192 7776
>>
Child said (2, 991): <<flunk 8192 1984
>>
Child said (2, 991): <<flunk 8192 2080
>>
Child said (2, 991): <<flunk 8192 2080
>>
Child said (2, 991): <<flunk 8192 2080
>>
Child said (2, 991): <<flunk 8192 6288
>>
Child said (2, 991): <<flunk 8192 3432
>>
Child said (2, 991): <<flunk 8192 6288
>>
Child said (2, 991): <<flunk 1019 536
>>
Child said (2, 991): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 991): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=991 status=0x86
Clean child
Child cleaned
start child pid 1728
Child said (2, 1728): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 1728): <<flunk 8192 6288
>>
Child said (2, 1728): <<flunk 8192 2516
>>
Child said (2, 1728): <<flunk 8192 3432
>>
Child said (2, 1728): <<flunk 8192 2272
>>
Child said (2, 1728): <<flunk 8192 2272
>>
Child said (2, 1728): <<flunk 8192 1312
>>
Child said (2, 1728): <<flunk 8192 7345
>>
Child said (2, 1728): <<flunk 8192 4384
>>
Child said (2, 1728): <<flunk 8192 7139
>>
Child said (2, 1728): <<flunk 8192 3432
>>
Child said (2, 1728): <<flunk 8192 5664
>>
Child said (2, 1728): <<flunk 8192 3432
>>
Child said (2, 1728): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 1728): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=1728 status=0x86
Clean child
Child cleaned
start child pid 2030
Child said (2, 2030): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 8192 4056
>>
Child said (2, 2030): <<flunk 5230 1982
>>
Child said (2, 2030): <<flunk 8192 5830
>>
Child said (2, 2030): <<flunk 8192 5961
>>
Child said (2, 2030): <<flunk 8192 2272
>>
Child said (2, 2030): <<flunk 8192 5832
>>
Child said (2, 2030): <<flunk 8192 6003
>>
Child said (2, 2030): <<flunk 4242 2480
>>
Child said (2, 2030): <<flunk 8192 6185
>>
Child said (2, 2030): <<flunk 8192 1982
>>
Child said (2, 2030): <<flunk 8192 5872
>>
Child said (2, 2030): <<flunk 8192 4008
>>
Child said (2, 2030): <<flunk 8192 3432
>>
Child said (2, 2030): <<flunk 8192 2080
>>
Child said (2, 2030): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 2030): <<  errno = 104 (Connection reset by peer)
>>
Cache child died pid=2030 status=0x86
Clean child
Child cleaned
start child pid 2228
Child said (2, 2228): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 2228): <<flunk 8192 411
>>
Child said (2, 2228): <<flunk 8192 6621
>>
Child said (2, 2228): <<flunk 8192 295
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 4459
>>
Child said (2, 2228): <<flunk 8192 4440
>>
Child said (2, 2228): <<flunk 8192 4459
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 1830
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 3928
>>
Child said (2, 2228): <<flunk 8192 4880
>>
Child said (2, 2228): <<flunk 8192 4056
>>
Child said (2, 2228): <<flunk 8192 4056
>>
Child said (2, 2228): <<flunk 8192 3902
>>
Child said (2, 2228): <<flunk 8192 3432
>>
Child said (2, 2228): <<flunk 8192 1982
>>
Child said (2, 2228): <<flunk 8192 1679
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 2532
>>
Child said (2, 2228): <<flunk 8192 5112
>>
Child said (2, 2228): <<flunk 8192 2532
>>
Child said (2, 2228): <<flunk 8192 1380
>>
Child said (2, 2228): <<flunk 8192 5032
>>
Child said (2, 2228): <<flunk 8192 4511
>>
Child said (2, 2228): <<flunk 8192 4511
>>
Child said (2, 2228): <<flunk 8192 286
>>
Child said (2, 2228): <<flunk 8192 2051
>>
Child said (2, 2228): <<flunk 8192 6488
>>
Child said (2, 2228): <<flunk 8192 7776
>>
Child said (2, 2228): <<flunk 8192 4056
>>
Child said (2, 2228): <<flunk 8192 3164
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 1792
>>
Child said (2, 2228): <<flunk 8192 1792
>>
Child said (2, 2228): <<flunk 4606 4056
>>
Child said (2, 2228): <<flunk 8192 4056
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 6606 2272
>>
Child said (2, 2228): <<flunk 8192 3216
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 2282
>>
Child said (2, 2228): <<flunk 4984 2708
>>
Child said (2, 2228): <<flunk 1996 1732
>>
Child said (2, 2228): <<flunk 8192 1168
>>
Child said (2, 2228): <<flunk 8192 2532
>>
Child said (2, 2228): <<flunk 5910 4206
>>
Child said (2, 2228): <<flunk 8192 3432
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 6232
>>
Child said (2, 2228): <<flunk 8192 2336
>>
Child said (2, 2228): <<flunk 8192 4880
>>
Child said (2, 2228): <<flunk 8192 6168
>>
Child said (2, 2228): <<flunk 8192 6185
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 6166
>>
Child said (2, 2228): <<flunk 8192 2354
>>
Child said (2, 2228): <<flunk 8192 3011
>>
Child said (2, 2228): <<flunk 8152 5416
>>
Child said (2, 2228): <<flunk 8192 2698
>>
Child said (2, 2228): <<flunk 8192 3424
>>
Child said (2, 2228): <<flunk 8192 295
>>
Child said (2, 2228): <<flunk 8192 276
>>
Child said (2, 2228): <<flunk 8192 7776
>>
Child said (2, 2228): <<flunk 8192 2512
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 5764 2272
>>
Child said (2, 2228): <<flunk 8192 295
>>
Child said (2, 2228): <<flunk 8192 4656
>>
Child said (2, 2228): <<flunk 8192 4656
>>
Child said (2, 2228): <<flunk 8192 5510
>>
Child said (2, 2228): <<flunk 8192 4656
>>
Child said (2, 2228): <<flunk 8192 3164
>>
Child said (2, 2228): <<flunk 8192 2041
>>
Child said (2, 2228): <<flunk 8192 295
>>
Child said (2, 2228): <<flunk 8192 1997
>>
Child said (2, 2228): <<flunk 8192 3432
>>
Child said (2, 2228): <<flunk 8192 3944
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 7736
>>
Child said (2, 2228): <<flunk 8192 6004
>>
Child said (2, 2228): <<flunk 8192 2976
>>
Child said (2, 2228): <<flunk 8192 3776
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 5230 2592
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 2080
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 2272
>>
Child said (2, 2228): <<flunk 8192 4656
>>
Child said (2, 2228): <<flunk 8192 2022
>>
Child said (2, 2228): <<flunk 8192 4675
>>
Child said (2, 2228): <<flunk 8192 276
>>
Child said (2, 2228): <<flunk 8192 888
>>
Child said (2, 2228): <<flunk 8192 4656
>>
Child said (2, 2228): <<flunk 8192 5224
>>
Child said (2, 2228): <<flunk 8192 276
>>
Child said (2, 2228): <<flunk 8192 276
>>
Child said (2, 2228): <<flunk 8192 276
>>
Child said (2, 2228): <<flunk 8192 3432
>>
Child said (2, 2228): <<flunk 8192 992
>>
Child said (2, 2228): <<flunk 8192 2592
>>
Child said (2, 2228): <<Assert error in STV_alloc(), stevedore.c line 70:
  Condition((st) != NULL) not true.
>>
Child said (2, 2228): <<  errno = 11 (Resource temporarily unavailable)
>>
Cache child died pid=2228 status=0x86
Clean child
Child cleaned
start child pid 3155
Child said (2, 3155): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3155): <<flunk 8192 2272
>>
Child said (2, 3155): <<flunk 8192 2528
>>
Child said (2, 3155): <<flunk 8192 8
>>
Child said (2, 3155): <<flunk 8192 2516
>>
Child said (2, 3155): <<flunk 8192 2080
>>
Child said (2, 3155): <<flunk 8192 3508
>>
Child said (2, 3155): <<flunk 8192 2080
>>
Child said (2, 3155): <<flunk 8192 1536
>>
Child said (2, 3155): <<flunk 8192 2080
>>
Child said (2, 3155): <<flunk 8192 2080
>>
Child said (2, 3155): <<flunk 8192 4459
>>
Child said (2, 3155): <<flunk 8192 1488
>>
Child said (2, 3155): <<flunk 8192 2592
>>
Child said (2, 3155): <<flunk 8192 2592
>>
Child said (2, 3155): <<flunk 8192 596
>>
Child said (2, 3155): <<flunk 8192 615
>>
Child said (2, 3155): <<flunk 8192 596
>>
Child said (2, 3155): <<flunk 8192 596
>>
Child said (2, 3155): <<flunk 8192 615
>>
Child said (2, 3155): <<flunk 8192 2592
>>
Child said (2, 3155): <<flunk 8192 2592
>>
Child said (2, 3155): <<flunk 8192 3408
>>
Child said (2, 3155): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Child said (2, 3155): <<  errno = 107 (Transport endpoint is not connected)
>>
Cache child died pid=3155 status=0x86
Clean child
Child cleaned
start child pid 3459
Child said (2, 3459): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3459): <<Assert error in SES_Delete(), cache_session.c line 339:
  Condition((sp->vcl) == 0) not true.
>>
Cache child died pid=3459 status=0x86
Clean child
Child cleaned
start child pid 3717
Child said (2, 3717): <<Child starts
sizeof(struct ws) = 24
sizeof(struct http) = 312
sizeof(struct http_conn) = 28
sizeof(struct acct) = 64
sizeof(struct worker) = 656
sizeof(struct workreq) = 12
sizeof(struct bereq) = 348
sizeof(struct storage) = 40
sizeof(struct object) = 500
sizeof(struct objhead) = 56
sizeof(struct sess) = 320
sizeof(struct vbe_conn) = 24
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 3717): <<flunk 4513 4150
>>
Child said (2, 3717): <<flunk 8192 5961
>>
Child said (2, 3717): <<flunk 8192 1883
>>
Child said (2, 3717): <<flunk 8192 1840
>>
Child said (2, 3717): <<flunk 8192 1840
>>
Child said (2, 3717): <<flunk 8192 1840
>>
Child said (2, 3717): <<flunk 8192 1840
>>
Child said (2, 3717): <<flunk 1996 1840
>>
Child said (2, 3717): <<flunk 1977 1840
>>
Child said (2, 3717): <<flunk 1996 1840
>>
Child said (2, 3717): <<flunk 1996 1840
>>
Child said (2, 3717): <<flunk 1977 1840
>>
Child said (2, 3717): <<flunk 1977 1840
>>
Child said (2, 3717): <<flunk 8192 1840
>>
Child said (2, 3717): <<flunk 8192 6437
>>
Child said (2, 3717): <<flunk 8192 2272
>>
Child said (2, 3717): <<flunk 8192 2272
>>
Child said (2, 3717): <<flunk 8192 7718
>>
Child said (2, 3717): <<flunk 8192 6003
>>


From duja at torlen.net  Tue Feb 12 19:00:34 2008
From: duja at torlen.net (Erik Torlen)
Date: Tue, 12 Feb 2008 20:00:34 +0100
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>	<47A91407.5000703@openplans.org>	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
Message-ID: <47B1ECD2.60705@torlen.net>

Hi,

I have seen the same behaviour on my Apache2 server with php5 installed. 
Many users got blank pages
when navigating around the website. I couldn't figure out what the 
problem was so I simply removed varnish
and the problem disappeared.

Another problem I had was that php's X-FORWARDED-FOR was empty at random 
times. I looked in the
apache2 log and saw some empty fields their too. Couldn't find a 
solution for it :(

/ Erik

Marco Molinari skrev:
> I can now reproduce it and I found a lot of info.
>
> I wrote a simple script that keeps on reloading itself, adding some
> chars each time; I disabled compression both in Apache and in PHP and
> I connect my browser through a 2.6 Squid proxy; and now I can't see
> PHP pages larger than 8000 bytes. I also found an interesting
> connection with cookies.
>
> Here are the log lines for Varnish requesting two pages to Apache:
>
> Apache:
> 127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
> /test_varnish2.php?n=10&t=1202822659 HTTP/1.0" 200 8000 "-"
> "{MY-USER-AGENT}"
> 127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
> /test_varnish2.php?n=11&t=1202822659 HTTP/1.0" 200 8001 "-"
> "{MY-USER-AGENT}"
>
> Varnish:
> 10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
> http://dev.{MY-SITE}:2280/test_varnish2.php?n=10&t=1202822659
> HTTP/1.0" 200 8000 "-" "{MY-USER-AGENT}"
> 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
> http://dev.{MY-SITE}:2280/test_varnish2.php?n=11&t=1202822659
> HTTP/1.0" 200 0 "-" "{MY-USER-AGENT}"
>
>
> As you can see Varnish logs a 0 size for the 8001 bytes request.
>
>
> Here is the extended log (as per varnishlog) for those requests (sorry
> for the length):
>
>    15 ReqStart     c 10.0.2.2 43859 67671826
>    15 RxRequest    c GET
>    15 RxURL        c /test_varnish2.php?n=10&t=1202822659
>    15 RxProtocol   c HTTP/1.0
>    15 RxHeader     c Host: dev.{MY-SITE}:2280
>    15 RxHeader     c User-Agent: {MY-USER-AGENT}
>    15 RxHeader     c Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    15 RxHeader     c Accept-Language: en-us,en;q=0.5
>    15 RxHeader     c Accept-Encoding: gzip,deflate
>    15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    15 RxHeader     c Cookie:
> __utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
> __utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=xxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>    15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    15 RxHeader     c X-Forwarded-For: 127.0.0.1
>    15 RxHeader     c Cache-Control: max-age=259200
>    15 RxHeader     c Connection: keep-alive
>    15 VCL_call     c recv
>    15 VCL_return   c pass
>    15 VCL_call     c pass
>    15 VCL_return   c pass
>    18 BackendOpen  b default 127.0.0.1 32988 127.0.0.1 8080
>    18 BackendXID   b 67671826
>    15 Backend      c 18 default
>    18 TxRequest    b GET
>    18 TxURL        b /test_varnish2.php?n=10&t=1202822659
>    18 TxProtocol   b HTTP/1.0
>    18 TxHeader     b Host: dev.{MY-SITE}:2280
>    18 TxHeader     b User-Agent: {MY-USER-AGENT}
>    18 TxHeader     b Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    18 TxHeader     b Accept-Language: en-us,en;q=0.5
>    18 TxHeader     b Accept-Encoding: gzip,deflate
>    18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    18 TxHeader     b Cookie:
> __utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
> __utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>    18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    18 TxHeader     b X-Forwarded-For: 127.0.0.1
>    18 TxHeader     b X-Varnish: 67671826
>    18 TxHeader     b X-Forwarded-for: 10.0.2.2
>    18 RxProtocol   b HTTP/1.1
>    18 RxStatus     b 200
>    18 RxResponse   b OK
>    18 RxHeader     b Date: Tue, 12 Feb 2008 13:24:26 GMT
>    18 RxHeader     b Server: Apache/2.0.52 (CentOS)
>    18 RxHeader     b X-Powered-By: PHP/4.3.9
>    18 RxHeader     b Content-Length: 8000
>    18 RxHeader     b Connection: close
>    18 RxHeader     b Content-Type: text/html; charset=UTF-8
>    15 ObjProtocol  c HTTP/1.1
>    15 ObjStatus    c 200
>    15 ObjResponse  c OK
>    15 ObjHeader    c Date: Tue, 12 Feb 2008 13:24:26 GMT
>    15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
>    15 ObjHeader    c X-Powered-By: PHP/4.3.9
>    15 ObjHeader    c Content-Type: text/html; charset=UTF-8
>    18 BackendClose b default
>    15 TTL          c 67671826 RFC 120 1202822666 1202822666 0 0 0
>    15 VCL_call     c fetch
>    15 VCL_return   c insert
>    15 Length       c 8000
>    15 VCL_call     c deliver
>    15 VCL_return   c deliver
>    15 TxProtocol   c HTTP/1.1
>    15 TxStatus     c 200
>    15 TxResponse   c OK
>    15 TxHeader     c Server: Apache/2.0.52 (CentOS)
>    15 TxHeader     c X-Powered-By: PHP/4.3.9
>    15 TxHeader     c Content-Type: text/html; charset=UTF-8
>    15 TxHeader     c Content-Length: 8000
>    15 TxHeader     c Date: Tue, 12 Feb 2008 13:24:26 GMT
>    15 TxHeader     c X-Varnish: 67671826
>    15 TxHeader     c Age: 0
>    15 TxHeader     c Via: 1.1 varnish
>    15 TxHeader     c Connection: keep-alive
>    15 ReqEnd       c 67671826 1202822666.438220024
> 1202822666.440738916 3.759930134 0.002374887 0.000144005
>     0 StatAddr       10.0.2.2 0 4217 31 171 0 0 171 41937 1114752
>     0 CLI            Rd ping
>     0 CLI            Wr 0 200 PONG 1202822669
>
>     second request:
>
>    15 ReqStart     c 10.0.2.2 43859 67671827
>    15 RxRequest    c GET
>    15 RxURL        c /test_varnish2.php?n=11&t=1202822659
>    15 RxProtocol   c HTTP/1.0
>    15 RxHeader     c Host: dev.{MY-SITE}:2280
>    15 RxHeader     c User-Agent: {MY-USER-AGENT}
>    15 RxHeader     c Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    15 RxHeader     c Accept-Language: en-us,en;q=0.5
>    15 RxHeader     c Accept-Encoding: gzip,deflate
>    15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    15 RxHeader     c Cookie:
> __utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
> __utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>    15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    15 RxHeader     c X-Forwarded-For: 127.0.0.1
>    15 RxHeader     c Cache-Control: max-age=259200
>    15 RxHeader     c Connection: keep-alive
>    15 VCL_call     c recv
>    15 VCL_return   c pass
>    15 VCL_call     c pass
>    15 VCL_return   c pass
>    18 BackendOpen  b default 127.0.0.1 32989 127.0.0.1 8080
>    18 BackendXID   b 67671827
>    15 Backend      c 18 default
>    18 TxRequest    b GET
>    18 TxURL        b /test_varnish2.php?n=11&t=1202822659
>    18 TxProtocol   b HTTP/1.0
>    18 TxHeader     b Host: dev.{MY-SITE}:2280
>    18 TxHeader     b User-Agent: {MY-USER-AGENT}
>    18 TxHeader     b Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    18 TxHeader     b Accept-Language: en-us,en;q=0.5
>    18 TxHeader     b Accept-Encoding: gzip,deflate
>    18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    18 TxHeader     b Cookie:
> __utma=xxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.xxxxxxxxxx.23;
> __utmz=xxxxxxxx.xxxxxxxxxx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=xxxxxxxxxx.xxxxxxxxxx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>    18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    18 TxHeader     b X-Forwarded-For: 127.0.0.1
>    18 TxHeader     b X-Varnish: 67671827
>    18 TxHeader     b X-Forwarded-for: 10.0.2.2
>    18 RxProtocol   b HTTP/1.1
>    18 RxStatus     b 200
>    18 RxResponse   b OK
>    18 RxHeader     b Date: Tue, 12 Feb 2008 13:24:29 GMT
>    18 RxHeader     b Server: Apache/2.0.52 (CentOS)
>    18 RxHeader     b X-Powered-By: PHP/4.3.9
>    18 RxHeader     b Connection: close
>    18 RxHeader     b Content-Type: text/html; charset=UTF-8
>    15 ObjProtocol  c HTTP/1.1
>    15 ObjStatus    c 200
>    15 ObjResponse  c OK
>    15 ObjHeader    c Date: Tue, 12 Feb 2008 13:24:29 GMT
>    15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
>    15 ObjHeader    c X-Powered-By: PHP/4.3.9
>    15 ObjHeader    c Content-Type: text/html; charset=UTF-8
>    18 BackendClose b default
>    15 TTL          c 67671827 RFC 120 1202822669 1202822669 0 0 0
>    15 VCL_call     c fetch
>    15 VCL_return   c insert
>    15 Length       c 0
>    15 VCL_call     c deliver
>    15 VCL_return   c deliver
>    15 TxProtocol   c HTTP/1.1
>    15 TxStatus     c 200
>    15 TxResponse   c OK
>    15 TxHeader     c Server: Apache/2.0.52 (CentOS)
>    15 TxHeader     c X-Powered-By: PHP/4.3.9
>    15 TxHeader     c Content-Type: text/html; charset=UTF-8
>    15 TxHeader     c Date: Tue, 12 Feb 2008 13:24:29 GMT
>    15 TxHeader     c X-Varnish: 67671827
>    15 TxHeader     c Age: 0
>    15 TxHeader     c Via: 1.1 varnish
>    15 TxHeader     c Connection: keep-alive
>    15 ReqEnd       c 67671827 1202822669.762167931
> 1202822669.765445948 3.321429014 0.003173113 0.000104904
>     0 StatAddr       10.0.2.2 0 4221 31 172 0 0 172 42161 1114752
>     0 CLI            Rd ping
>     0 CLI            Wr 0 200 PONG 1202822672
>    15 SessionClose c timeout
>    15 StatSess     c 10.0.2.2 43859 11 1 4 0 0 4 962 23995
>
> As you can see in the 8001 bytes request there seems to be no
> Content-Length header in the Apache response, but I checked with
> LiveHttpHeaders (without Squid) and the header is there.
>
> You can also notice that cookies in the extended logs are cut (I
> replaced the numbers with "xxx"); so I tried to disable the cookies in
> the browser, and everything works!
>
>    15 ReqStart     c 10.0.2.2 57522 67671865
>    15 RxRequest    c GET
>    15 RxURL        c /test_varnish2.php?n=11&t=1202823345
>    15 RxProtocol   c HTTP/1.0
>    15 RxHeader     c Host: dev.{MY-SITE}:2280
>    15 RxHeader     c User-Agent: {MY-USER-AGENT}
>    15 RxHeader     c Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    15 RxHeader     c Accept-Language: en-us,en;q=0.5
>    15 RxHeader     c Accept-Encoding: gzip,deflate
>    15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    15 RxHeader     c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    15 RxHeader     c X-Forwarded-For: 127.0.0.1
>    15 RxHeader     c Cache-Control: max-age=259200
>    15 RxHeader     c Connection: keep-alive
>    15 VCL_call     c recv
>    15 VCL_return   c lookup
>    15 VCL_call     c hash
>    15 VCL_return   c hash
>    15 VCL_call     c miss
>    15 VCL_return   c fetch
>    18 BackendOpen  b default 127.0.0.1 33028 127.0.0.1 8080
>    18 BackendXID   b 67671865
>    15 Backend      c 18 default
>    18 TxRequest    b GET
>    18 TxURL        b /test_varnish2.php?n=11&t=1202823345
>    18 TxProtocol   b HTTP/1.1
>    18 TxHeader     b Host: dev.{MY-SITE}:2280
>    18 TxHeader     b User-Agent: {MY-USER-AGENT}
>    18 TxHeader     b Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>    18 TxHeader     b Accept-Language: en-us,en;q=0.5
>    18 TxHeader     b Accept-Encoding: gzip,deflate
>    18 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    18 TxHeader     b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>    18 TxHeader     b X-Forwarded-For: 127.0.0.1
>    18 TxHeader     b X-Varnish: 67671865
>    18 TxHeader     b X-Forwarded-for: 10.0.2.2
>    18 RxProtocol   b HTTP/1.1
>    18 RxStatus     b 200
>    18 RxResponse   b OK
>    18 RxHeader     b Date: Tue, 12 Feb 2008 13:35:57 GMT
>    18 RxHeader     b Server: Apache/2.0.52 (CentOS)
>    18 RxHeader     b X-Powered-By: PHP/4.3.9
>    18 RxHeader     b Connection: close
>    18 RxHeader     b Transfer-Encoding: chunked
>    18 RxHeader     b Content-Type: text/html; charset=UTF-8
>    15 ObjProtocol  c HTTP/1.1
>    15 ObjStatus    c 200
>    15 ObjResponse  c OK
>    15 ObjHeader    c Date: Tue, 12 Feb 2008 13:35:57 GMT
>    15 ObjHeader    c Server: Apache/2.0.52 (CentOS)
>    15 ObjHeader    c X-Powered-By: PHP/4.3.9
>    15 ObjHeader    c Content-Type: text/html; charset=UTF-8
>    18 BackendClose b default
>    15 TTL          c 67671865 RFC 120 1202823357 1202823357 0 0 0
>    15 VCL_call     c fetch
>    15 VCL_return   c insert
>    15 Length       c 8001
>    15 VCL_call     c deliver
>    15 VCL_return   c deliver
>    15 TxProtocol   c HTTP/1.1
>    15 TxStatus     c 200
>    15 TxResponse   c OK
>    15 TxHeader     c Server: Apache/2.0.52 (CentOS)
>    15 TxHeader     c X-Powered-By: PHP/4.3.9
>    15 TxHeader     c Content-Type: text/html; charset=UTF-8
>    15 TxHeader     c Content-Length: 8001
>    15 TxHeader     c Date: Tue, 12 Feb 2008 13:35:57 GMT
>    15 TxHeader     c X-Varnish: 67671865
>    15 TxHeader     c Age: 0
>    15 TxHeader     c Via: 1.1 varnish
>    15 TxHeader     c Connection: keep-alive
>    15 ReqEnd       c 67671865 1202823357.593729973
> 1202823357.596472979 3.786515951 0.002630949 0.000112057
>     0 StatAddr       10.0.2.2 0 4908 34 210 0 0 210 52216 1395936
>
>
> This could explain why the problem seems so erratic, as a user can see
> a page or not depending on the page length and their cookies.
>
> My configuration:
> - web server: Centos 4 + Apache 2.0.52 + PHP 4.3.9 + Varnish 1.1.2
> (everything installed through rpms)
> - proxy server: Ubuntu 7.10 + Squid 2.6
> - client: Ubuntu 7.10 + Firefox (actually it's the same pc that runs
> the proxy server)
>
>
>
> Uncommented parts in my vcl:
> backend default {
>         set backend.host = "127.0.0.1";
>         set backend.port = "8080";
> }
>
> sub vcl_recv {
>         if (req.http.Pragma == "no-cache") {
>                 pipe;
>         }
>
>         if (req.request == "GET" && req.url ~
> "\.(gif|jpg|swf|css|js|swf|flv|png|jpeg)$") {
>                 lookup;
>         }
>
>         if (req.request != "GET" && req.request != "HEAD") {
>                 pipe;
>         }
>
>         if (req.http.Expect) {
>                 pipe;
>         }
>
>         if (req.http.Authenticate || req.http.Cookie) {
>                 pass;
>         }
>
>         lookup;
> }
>
>
> Is this enough to post a bug report?
>
> Thanks
> Marco
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>   



From des at linpro.no  Wed Feb 13 15:33:01 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 13 Feb 2008 16:33:01 +0100
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
	(Marco Molinari's message of "Tue, 12 Feb 2008 15:01:37 +0100")
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
Message-ID: <ujrprv0eus2.fsf@login.linpro.no>

"Marco Molinari" <marco.molinari at gmail.com> writes:
> I wrote a simple script that keeps on reloading itself, adding some
> chars each time; I disabled compression both in Apache and in PHP and
> I connect my browser through a 2.6 Squid proxy; and now I can't see
> PHP pages larger than 8000 bytes. I also found an interesting
> connection with cookies.

You are doing weird things such as inserting passed requests into the
cache, yet none of the requests you showed were cache hits.

Re the second request from your log, where the client got an empty
page: that was actually what the backend sent.

There is no way to debug this further without seeing your vcl script.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Wed Feb 13 15:33:34 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 13 Feb 2008 16:33:34 +0100
Subject: hash with Accept-Encoding
In-Reply-To: <56F36529-29BF-417F-B314-6C72127751EA@digitalmarbles.com>
	(Ricardo Newbery's message of "Sat, 2 Feb 2008 22:10:12 -0800")
References: <56F36529-29BF-417F-B314-6C72127751EA@digitalmarbles.com>
Message-ID: <ujrlk5oeur5.fsf@login.linpro.no>

Ricardo Newbery <ric at digitalmarbles.com> writes:
> I came across this line in an example vcl which confused me...
>
> sub vcl_hash {
>      set req.hash += req.http.Accept-Encoding;
> }

This is probably from an old email from before phk implemented Vary.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Wed Feb 13 15:35:44 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 13 Feb 2008 16:35:44 +0100
Subject: error page not delivered
In-Reply-To: <47A8A01A.3030900@chicagosuntimes.com> (Ramon A. Hermon's message
	of "Tue, 05 Feb 2008 11:42:50 -0600")
References: <47A8A01A.3030900@chicagosuntimes.com>
Message-ID: <ujrhcgceunj.fsf@login.linpro.no>

Ramon A Hermon <rhermon at chicagosuntimes.com> writes:
> I am unable to get varnish to deliver the customized error page when
> requesting a non-existent url.

We can't figure out what's happening from the Apache logs, you have to
show us the Varnish logs.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Wed Feb 13 15:41:26 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 13 Feb 2008 16:41:26 +0100
Subject: Miscellaneous questions
In-Reply-To: <1167.1202770705@critter.freebsd.dk> (Poul-Henning Kamp's message
	of "Mon, 11 Feb 2008 22:58:25 +0000")
References: <1167.1202770705@critter.freebsd.dk>
Message-ID: <ujrd4r0eue1.fsf@login.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> "Michael S. Fischer" <michael at dynamine.net> writes:
> > (1) Feature request: Can a knob be added to turn down the verbosity of
> > Varnish logging?  Right now on a quad-core Xeon we can service about
> > 14k conn/s, which is good, but I wonder whether we could eke out even
> > more performance by quelling information that we don't need to log.
> The shared memory log is practically free, the trick is to only
> pick the stuff out of it that you need to store on disk.

I believe varnishlog -w /var/log/varnish.log is enabled by default if
you install from packages on !FreeBSD.  We may want to change this.

> > (2) HTTP/1.1 keep-alive connection reuse:  Does Varnish have the
> > ability to reuse origin server connections (assuming they are HTTP/1.1
> > Keep-Alive connections)?  Or, is there a strict 1:1 mapping between
> > client-proxy connections and proxy-origin server connections?
> They should already be reused by default.

Maybe something is preventing backend session reuse in his
installation; that can easily be determined from logs.

I think the default timeout on backends connection may be a little
short, though.

> > (3) Feature request: Request hashing.  It would be really cool if
> > Varnish were able to select the origin server (in reality another
> > Varnish proxy) by hashing the Request URI.  Having this ability would
> > improve the cache hit ratio overall where a pool of caching proxies is
> > used.
> We have sort of given up on the peer-to-peer cache fetches using
> dedicated protocols, but if you are able to tell that another
> varnish is a better place to pick up something, nothing prevents
> you from making that a backend of this varnish and doing
> a pass on the request.

No, I think what he means is selecting the backend based on client-ip
modulo number-of-backends so each client always gets the same backend
(which makes session tracking much easier)

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Wed Feb 13 15:45:27 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 13 Feb 2008 16:45:27 +0100
Subject: Not caching immediately?
In-Reply-To: <2c7df3ed0801311514h1faa5f1dq573ce0ef5a193421@mail.gmail.com>
	(Aaron Pfeifer's message of "Thu, 31 Jan 2008 18:14:24 -0500")
References: <2c7df3ed0801311348t759eb02eyf7cb5cfaaf567d3f@mail.gmail.com>
	<2c7df3ed0801311514h1faa5f1dq573ce0ef5a193421@mail.gmail.com>
Message-ID: <ujr8x1oeu7c.fsf@login.linpro.no>

"Aaron Pfeifer" <aaron.pfeifer at gmail.com> writes:
> In case anyone runs into the same problem, with the help from the folks on
> #varnish, the problem is that piping a POST will cause the cache to be
> bypassed if the session remains open.  The solution is to either:
>
> (1) Upgrade to trunk (I was using 1.1.2)
> (2) Add "set req.http.connection = "close";" immediately before the pipe for
> a POST

No, trunk will handle POST correctly in "pass" mode which makes this
unnecessary.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From marco.molinari at gmail.com  Wed Feb 13 15:50:10 2008
From: marco.molinari at gmail.com (Marco Molinari)
Date: Wed, 13 Feb 2008 16:50:10 +0100
Subject: A few users see a blank page
In-Reply-To: <ujrprv0eus2.fsf@login.linpro.no>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
	<ujrprv0eus2.fsf@login.linpro.no>
Message-ID: <e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>

On Feb 13, 2008 4:33 PM, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
>
> You are doing weird things such as inserting passed requests into the
> cache, yet none of the requests you showed were cache hits.
>
> Re the second request from your log, where the client got an empty
> page: that was actually what the backend sent.

Hi,
actually Apache logged it sent 8001 bytes:
127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
/test_varnish2.php?n=11&t=1202822659 HTTP/1.0" 200 8001 "-"


> There is no way to debug this further without seeing your vcl script.



Here the vcl I posted, which was the one I was using:

backend default {
       set backend.host = "127.0.0.1";
       set backend.port = "8080";
}

sub vcl_recv {
       if (req.http.Pragma == "no-cache") {
               pipe;
       }

       if (req.request == "GET" && req.url ~
"\.(gif|jpg|swf|css|js|swf|flv|png|jpeg)$") {
               lookup;
       }

       if (req.request != "GET" && req.request != "HEAD") {
               pipe;
       }

       if (req.http.Expect) {
               pipe;
       }

       if (req.http.Authenticate || req.http.Cookie) {
               pass;
       }

       lookup;
}


Today I changed the last "pass" into "pipe" (in the req.http.Cookie
part) and both I and my complaining users get no blank pages anymore
(Arne, I remember you wrote you tried both pipe and pass, but did you
try this?)

To sum this up, I get a blank page if all of these happen:
- I use a Squid 2.5 or 2.6 proxy
- and the content is generated by php
- and the content is more than 8000 bytes
- and the cookie header is quite long (about 500 chars)
- and if (req.http.Cookie) {pass} in vcl

thanks
Marco


From anders.vannman at vk.se  Wed Feb 13 16:36:44 2008
From: anders.vannman at vk.se (Anders =?ISO-8859-1?Q?V=E4nnman?=)
Date: Wed, 13 Feb 2008 17:36:44 +0100
Subject: Using varnish
Message-ID: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>

Hi,

We are in the process of evaluating Varnish as an alternative for Squid
for our sites. We have got an internal varnish up and running and it seems
just great. Of course I have many questions, is there anyone on a swedish
newspaper using varnish?

// Anders V?nnman




From duja at torlen.net  Wed Feb 13 17:58:41 2008
From: duja at torlen.net (Erik Torlen)
Date: Wed, 13 Feb 2008 18:58:41 +0100
Subject: Using varnish
In-Reply-To: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
References: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
Message-ID: <47B32FD1.503@torlen.net>

Do you just want to know a swedish newspaper that's using varnish?

If so, Aftonbladet and SvD is both using varnish.

/ Erik

Anders V?nnman skrev:
> Hi,
>
> We are in the process of evaluating Varnish as an alternative for Squid
> for our sites. We have got an internal varnish up and running and it seems
> just great. Of course I have many questions, is there anyone on a swedish
> newspaper using varnish?
>
> // Anders V?nnman
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>   



From fredrik.nygren at gotamedia.se  Wed Feb 13 18:54:36 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Wed, 13 Feb 2008 19:54:36 +0100
Subject: Using varnish
In-Reply-To: <47B32FD1.503@torlen.net>
References: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
	<47B32FD1.503@torlen.net>
Message-ID: <5A28A2AB-9137-448D-8A10-875D4B2B4561@gotamedia.se>

I'm a member of the development team at Gota Media which runs four  
swedish newspapers (Barometern.se, BLT.se, BT.se and SMP.se). Right  
now we are evaluating Varnish and it looks good.

Let's keep in touch!

Regards
Fredrik Nygren
Gota Media

On 13 feb 2008, at 18.58, Erik Torlen wrote:

Do you just want to know a swedish newspaper that's using varnish?

If so, Aftonbladet and SvD is both using varnish.

/ Erik

Anders V?nnman skrev:
> Hi,
>
> We are in the process of evaluating Varnish as an alternative for  
> Squid
> for our sites. We have got an internal varnish up and running and it  
> seems
> just great. Of course I have many questions, is there anyone on a  
> swedish
> newspaper using varnish?
>
> // Anders V?nnman
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>

_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


H?lsar
</Fredrik>



From christophe.husson at univ-reims.fr  Thu Feb 14 08:43:42 2008
From: christophe.husson at univ-reims.fr (Christophe Husson)
Date: Thu, 14 Feb 2008 09:43:42 +0100
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>	<47A91407.5000703@openplans.org>	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>	<47AF2C50.8000800@openplans.org>	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>	<ujrprv0eus2.fsf@login.linpro.no>
	<e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
Message-ID: <47B3FF3E.1020201@univ-reims.fr>

Hi,

I've allready send a bug report for this problem one month ago : 
http://varnish.projects.linpro.no/ticket/197


Marco Molinari a ?crit :
> On Feb 13, 2008 4:33 PM, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
>   
>> You are doing weird things such as inserting passed requests into the
>> cache, yet none of the requests you showed were cache hits.
>>
>> Re the second request from your log, where the client got an empty
>> page: that was actually what the backend sent.
>>     
>
> Hi,
> actually Apache logged it sent 8001 bytes:
> 127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
> /test_varnish2.php?n=11&t=1202822659 HTTP/1.0" 200 8001 "-"
>
>
>   
>> There is no way to debug this further without seeing your vcl script.
>>     
>
>
>
> Here the vcl I posted, which was the one I was using:
>
> backend default {
>        set backend.host = "127.0.0.1";
>        set backend.port = "8080";
> }
>
> sub vcl_recv {
>        if (req.http.Pragma == "no-cache") {
>                pipe;
>        }
>
>        if (req.request == "GET" && req.url ~
> "\.(gif|jpg|swf|css|js|swf|flv|png|jpeg)$") {
>                lookup;
>        }
>
>        if (req.request != "GET" && req.request != "HEAD") {
>                pipe;
>        }
>
>        if (req.http.Expect) {
>                pipe;
>        }
>
>        if (req.http.Authenticate || req.http.Cookie) {
>                pass;
>        }
>
>        lookup;
> }
>
>
> Today I changed the last "pass" into "pipe" (in the req.http.Cookie
> part) and both I and my complaining users get no blank pages anymore
> (Arne, I remember you wrote you tried both pipe and pass, but did you
> try this?)
>
> To sum this up, I get a blank page if all of these happen:
> - I use a Squid 2.5 or 2.6 proxy
> - and the content is generated by php
> - and the content is more than 8000 bytes
> - and the cookie header is quite long (about 500 chars)
> - and if (req.http.Cookie) {pass} in vcl
>
> thanks
> Marco
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>
>   



From phk at phk.freebsd.dk  Thu Feb 14 09:29:47 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 14 Feb 2008 09:29:47 +0000
Subject: A few users see a blank page 
In-Reply-To: Your message of "Wed, 13 Feb 2008 16:50:10 +0100."
	<e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com> 
Message-ID: <22861.1202981387@critter.freebsd.dk>

In message <e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d at mail.gmail.com>, "Marc
o Molinari" writes:

>To sum this up, I get a blank page if all of these happen:

>- and the content is more than 8000 bytes

Which exact version of varnish do you use ?

-- 
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 phk at phk.freebsd.dk  Thu Feb 14 09:31:02 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 14 Feb 2008 09:31:02 +0000
Subject: Miscellaneous questions 
In-Reply-To: Your message of "Wed, 13 Feb 2008 16:41:26 +0100."
	<ujrd4r0eue1.fsf@login.linpro.no> 
Message-ID: <22873.1202981462@critter.freebsd.dk>

In message <ujrd4r0eue1.fsf at login.linpro.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgra
v?= writes:

>I believe varnishlog -w /var/log/varnish.log is enabled by default if
>you install from packages on !FreeBSD.  We may want to change this.

I concur.


-- 
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 duja at torlen.net  Thu Feb 14 10:14:32 2008
From: duja at torlen.net (Erik)
Date: Thu, 14 Feb 2008 11:14:32 +0100
Subject: A few users see a blank page
Message-ID: <uqvqbdvw4mu32zf.140220081114@torlen.net>

Marco Molinari Wrote in http://projects.linpro.no/pipermail/varnish-misc/2008-February/001361.html

My configuration:
- web server: Centos 4 + Apache 2.0.52 + PHP 4.3.9 + Varnish 1.1.2
(everything installed through rpms)
- proxy server: Ubuntu 7.10 + Squid 2.6
- client: Ubuntu 7.10 + Firefox (actually it's the same pc that runs
the proxy server)

Original Message -----------------------
In message <e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d at mail.gmail.com>, "Marc
o Molinari" writes:

>To sum this up, I get a blank page if all of these happen:

>- and the content is more than 8000 bytes

Which exact version of varnish do you use ?

-- 
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.
_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc



From phk at phk.freebsd.dk  Thu Feb 14 10:16:25 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 14 Feb 2008 10:16:25 +0000
Subject: A few users see a blank page 
In-Reply-To: Your message of "Thu, 14 Feb 2008 11:14:32 +0100."
	<uqvqbdvw4mu32zf.140220081114@torlen.net> 
Message-ID: <23739.1202984185@critter.freebsd.dk>

In message <uqvqbdvw4mu32zf.140220081114 at torlen.net>, Erik writes:

>- web server: Centos 4 + Apache 2.0.52 + PHP 4.3.9 + Varnish=
> 1.1.2

Ok, I think this bug has been fixed, as also indicated by ticket 188

-- 
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 marco.molinari at gmail.com  Thu Feb 14 10:27:28 2008
From: marco.molinari at gmail.com (Marco Molinari)
Date: Thu, 14 Feb 2008 11:27:28 +0100
Subject: A few users see a blank page
In-Reply-To: <23739.1202984185@critter.freebsd.dk>
References: <uqvqbdvw4mu32zf.140220081114@torlen.net>
	<23739.1202984185@critter.freebsd.dk>
Message-ID: <e950eb1e0802140227h3db120f5o42f058d0f549da02@mail.gmail.com>

On Thu, Feb 14, 2008 at 11:16 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <uqvqbdvw4mu32zf.140220081114 at torlen.net>, Erik writes:
>
>  >- web server: Centos 4 + Apache 2.0.52 + PHP 4.3.9 + Varnish=
>  > 1.1.2
>
>  Ok, I think this bug has been fixed, as also indicated by ticket 188

Hi,
I can confirm it's fixed in trunk. I'm sorry I didn't test it earlier.

Thanks
Marco


From des at linpro.no  Thu Feb 14 11:02:23 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 14 Feb 2008 12:02:23 +0100
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
	(Marco Molinari's message of "Wed, 13 Feb 2008 16:50:10 +0100")
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
	<ujrprv0eus2.fsf@login.linpro.no>
	<e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
Message-ID: <ujrmyq34x8g.fsf@login.linpro.no>

"Marco Molinari" <marco.molinari at gmail.com> writes:
> backend default {
>        set backend.host = "127.0.0.1";
>        set backend.port = "8080";
> }

You didn't say which version you're using, but from this backend
definition, it's certainly not trunk.  It would be very helpful to
know whether you see the same behaviour with trunk.

>        if (req.http.Pragma == "no-cache") {
>                pipe;
>        }

Are you sure you want to do this?

If the point of this is to allow the client to Shift-Reload, you
should purge the URL to force a reload from the backend, instead of
piping the request.

If you are certain that this is what you want, you should use pass
instead of pipe.

If you are absolutely certain that you want to use pipe, you should
add "Connection: close" to the request so that subsequent requests
will go through Varnish.

>        if (req.request == "GET" && req.url ~ "\.(gif|jpg|swf|css|js|swf|flv|png|jpeg)$") {
>                lookup;
>        }

You should strip cookies before lookup.

>        if (req.request != "GET" && req.request != "HEAD") {
>                pipe;
>        }

Varnish can handle POST in pass mode.

In any case, this should be at the top; otherwise, requests you want
piped may be caught earlier and sent to pass or lookup.

>        if (req.http.Expect) {
>                pipe;
>        }

You really want pass here, not pipe.

> Today I changed the last "pass" into "pipe" (in the req.http.Cookie
> part) and both I and my complaining users get no blank pages anymore
> (Arne, I remember you wrote you tried both pipe and pass, but did you
> try this?)
>
> To sum this up, I get a blank page if all of these happen:
> - I use a Squid 2.5 or 2.6 proxy
> - and the content is generated by php
> - and the content is more than 8000 bytes
> - and the cookie header is quite long (about 500 chars)
> - and if (req.http.Cookie) {pass} in vcl

I'm sorry, but the logs you posted show that the backend did not send
any content for the second request.

If you think otherwise, you'll have to provide a tcpdump.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Thu Feb 14 11:18:55 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 14 Feb 2008 12:18:55 +0100
Subject: Configure varnish to pipe a subdomain
References: <84o62yo3haxzcu4.220120081040@torlen.net>
Message-ID: <ujrwsp7rdk0.fsf@login.linpro.no>

Erik <duja at torlen.net> writes:
> Neither am I a regex expert, but I dont think that the regex is the
> problem. You are using http.url instead of using http.host.  And if
> im not totally wrong, you dont need the ~ to check the host, you can
> use ==.
>
> Change this:
> if (req.http.url ~ "admin.example.com$") {
>     pipe;
> }
> To this:
> if (req.http.host == "admin.example.com") {
>     pipe;
> }
>
> And this:
> if (req.http.Cookie && req.http.url ~ "admin.example.com$") {
>     pipe;
> }
>
> To this:
> if (req.http.Cookie && req.http.host == "admin.example.com") {
>     pipe;
> }

A couple of issues:

 - a regexp is better if you get it right, because a regexp match
   (unlike a string comparison) is case-insensitive by default.

 - pass is better than pipe, unless pipe is required for other
   reasons, in which case "Connection: close" should be added to the
   request headers.

 - the second if will never evalutate to true, since the first one
   trumps it.

The correct code would be:

if (req.http.url ~ "^admin.example.com$") {
        pass;
}

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From marco.molinari at gmail.com  Thu Feb 14 11:31:19 2008
From: marco.molinari at gmail.com (Marco Molinari)
Date: Thu, 14 Feb 2008 12:31:19 +0100
Subject: A few users see a blank page
In-Reply-To: <ujrmyq34x8g.fsf@login.linpro.no>
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
	<ujrprv0eus2.fsf@login.linpro.no>
	<e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
	<ujrmyq34x8g.fsf@login.linpro.no>
Message-ID: <e950eb1e0802140331x71e0534jdcfb2dfe14e03c4d@mail.gmail.com>

On Thu, Feb 14, 2008 at 12:02 PM, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
>  You didn't say which version you're using, but from this backend
>  definition, it's certainly not trunk.  It would be very helpful to
>  know whether you see the same behaviour with trunk.

Hi,
I tried trunk and I don't get any blank page with it. I'm sorry I
didn't try it earlier.



>
>  >        if (req.http.Pragma == "no-cache") {
>  >                pipe;
>  >        }
>
>  Are you sure you want to do this?
>
>  If the point of this is to allow the client to Shift-Reload, you
>  should purge the URL to force a reload from the backend, instead of
>  piping the request.

That's the point, I just needed a quick way to purge an URL.
Later I'll definetely purge it from the backend.

Thanks for your reply, I'm still learning a lot about Varnish,
especially the difference between pass and pipe. Actually the "pipe"
for POST and req.http.Expect were taken from the default vcl.
If I understand correctly "pipe" means that further data between
client and server is passed until the connection is closed, while
"pass" means that the current request will be passed, but further
requests in the same connection will be normally processed by the vcl
file (and could be looked-up, for example).
Is this correct? Would you please make some examples where "pass" and
"pipe" are preferred?

Thanks,
Marco


From des at linpro.no  Thu Feb 14 13:38:49 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 14 Feb 2008 14:38:49 +0100
Subject: A few users see a blank page
In-Reply-To: <e950eb1e0802140331x71e0534jdcfb2dfe14e03c4d@mail.gmail.com>
	(Marco Molinari's message of "Thu, 14 Feb 2008 12:31:19 +0100")
References: <e950eb1e0802041105r235a012am800b97525c6d9255@mail.gmail.com>
	<47A91407.5000703@openplans.org>
	<e950eb1e0802070730y3edde1afw5786fab8eeff3c8f@mail.gmail.com>
	<47AF2C50.8000800@openplans.org>
	<e950eb1e0802120601p2b690330h467a37503a0edd0c@mail.gmail.com>
	<ujrprv0eus2.fsf@login.linpro.no>
	<e950eb1e0802130750n1f0db3cbu1e9f8bc5bdbe9f0d@mail.gmail.com>
	<ujrmyq34x8g.fsf@login.linpro.no>
	<e950eb1e0802140331x71e0534jdcfb2dfe14e03c4d@mail.gmail.com>
Message-ID: <ujrk5l7r72u.fsf@login.linpro.no>

"Marco Molinari" <marco.molinari at gmail.com> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > If the point of this is to allow the client to Shift-Reload, you
> > should purge the URL to force a reload from the backend, instead of
> > piping the request.
> That's the point, I just needed a quick way to purge an URL.

This won't do what you want; the client that used Pragma: no-cache
will see a new version, but other clients won't.

Additionally, I would recommend that you use an ACL to restrict
purging to specific clients.

> Thanks for your reply, I'm still learning a lot about Varnish,
> especially the difference between pass and pipe. Actually the "pipe"
> for POST and req.http.Expect were taken from the default vcl.

The *old* default VCL :) I haven't had time to update the
documentation.

> If I understand correctly "pipe" means that further data between
> client and server is passed until the connection is closed, while
> "pass" means that the current request will be passed, but further
> requests in the same connection will be normally processed by the vcl
> file (and could be looked-up, for example).

Absolutely correct.

> Is this correct? Would you please make some examples where "pass" and
> "pipe" are preferred?

"pass" is preferred whenever possible; "pipe" should only be used for
requests that Varnish can't handle at all because they don't follow
the ususal HTTP structure (CONNECT is the only example I can think of
at the moment)

In the past, pass could not handle POST requests at all; later, it
could handle them but poorly (insufficient error recovery).  The
current code in trunk handles POST requests correctly in pass mode.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From rhermon at chicagosuntimes.com  Thu Feb 14 18:32:32 2008
From: rhermon at chicagosuntimes.com (Ramon A Hermon)
Date: Thu, 14 Feb 2008 12:32:32 -0600
Subject: error page not delivered
Message-ID: <200802141232.39278.rhermon@chicagosuntimes.com>

> I am unable to get varnish to deliver the customized error page when
> requesting a non-existent url.

I should correct the above statement to "I get a blank page when requesting a 
non-existent directory or html file in the url".

Also, I did not provide the varnish log entries before ,so it follows;
$ varnishd -V
varnishd (varnish-1.1.2)
Copyright (c) 2006-2007 Linpro AS / Verdens Gang AS

$ uname -a
Linux vh006.p 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 
x86_64 x86_64 GNU/Linux

Case #1 (Fails!)
30 SessionOpen  c X.X.X.X 57544
30 ReqStart     c X.X.X.X 57544 1808069741
30 RxRequest    c GET
30 RxURL        c /notthere
30 RxProtocol   c HTTP/1.1
30 RxHeader     c Host: mysite.com
30 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; 
rv:1.8.1.11) Gecko/20080206 Firefox/2.0.0.11
30 RxHeader     c Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
30 RxHeader     c Accept-Language: en-us,en;q=0.5
30 RxHeader     c Accept-Encoding: gzip,deflate
30 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
30 RxHeader     c Keep-Alive: 300
30 RxHeader     c Connection: keep-alive
30 RxHeader     c Cookie: OAX=DCIHAke0f0IADHvs; s_cc=true; s_sq=%5B%5BB%5D%5D
30 VCL_call     c recv lookup
30 VCL_call     c hash hash
30 VCL_call     c miss fetch
30 Backend      c 29 default
30 ObjProtocol  c HTTP/1.1
30 ObjStatus    c 302
30 ObjResponse  c Moved Temporarily
30 ObjHeader    c Date: Thu, 14 Feb 2008 17:51:03 GMT
30 ObjHeader    c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
30 ObjHeader    c X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: 
CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
30 ObjHeader    c Location: http://mysite.com/notthere/index.html
30 ObjHeader    c Content-Type: text/plain
30 ObjHeader    c Set-Cookie: Coyote-2-c0a81e3d=c0a8823f:0; path=/
30 TTL          c 1808069741 RFC 120 1203011475 1203011463 0 0 0
30 VCL_call     c fetch insert
30 Length       c 0
30 VCL_call     c deliver deliver
30 TxProtocol   c HTTP/1.1
30 TxStatus     c 302
30 TxResponse   c Moved Temporarily
30 TxHeader     c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
30 TxHeader     c X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: 
CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
30 TxHeader     c Location: http://mysite.com/notthere/index.html
30 TxHeader     c Content-Type: text/plain
30 TxHeader     c Content-Length: 0
30 TxHeader     c Date: Thu, 14 Feb 2008 17:51:15 GMT
30 TxHeader     c X-Varnish: 1808069741
30 TxHeader     c Age: 0
30 TxHeader     c Via: 1.1 varnish
30 TxHeader     c Connection: keep-alive
30 ReqEnd       c 1808069741 1203011475.595798969 1203011475.600512028 
0.000309944 0.004663944 0.000049114

30 ReqStart     c X.X.X.X 57544 1808069742
30 RxRequest    c GET
30 RxURL        c /notthere/index.html
30 RxProtocol   c HTTP/1.1
30 RxHeader     c Host: mysite.com
30 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; 
rv:1.8.1.11) Gecko/20080206 Firefox/2.0.0.11
30 RxHeader     c Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
30 RxHeader     c Accept-Language: en-us,en;q=0.5
30 RxHeader     c Accept-Encoding: gzip,deflate
30 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
30 RxHeader     c Keep-Alive: 300
30 RxHeader     c Connection: keep-alive
30 RxHeader     c Cookie: OAX=DCIHAke0f0IADHvs; s_cc=true; s_sq=%5B%5BB%5D%5D
30 VCL_call     c recv lookup
30 VCL_call     c hash hash
30 VCL_call     c miss fetch
30 Backend      c 29 default
30 ObjProtocol  c HTTP/1.0
30 ObjStatus    c 404
30 ObjResponse  c /WEB-INF/templatesnotthere/index
30 ObjHeader    c Date: Thu, 14 Feb 2008 17:51:03 GMT
30 ObjHeader    c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
30 ObjHeader    c Set-Cookie: 
JSESSIONID=A23A24A92C07FF3836FA98C596F82503.jboss01; Path=/
30 ObjHeader    c Cache-Control: max-age=600
30 ObjHeader    c Expires: Thu, 14 Feb 2008 18:01:03 GMT
30 ObjHeader    c Content-Type: text/html
30 TTL          c 1808069742 RFC 586 1203011476 1203011463 1203012063 600 0
30 VCL_call     c fetch insert
30 Length       c 0
30 VCL_call     c deliver deliver
30 TxProtocol   c HTTP/1.0
30 TxStatus     c 404
30 TxResponse   c /WEB-INF/templatesnotthere/index
30 TxHeader     c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
30 TxHeader     c Cache-Control: max-age=600
30 TxHeader     c Expires: Thu, 14 Feb 2008 18:01:03 GMT
30 TxHeader     c Content-Type: text/html
30 TxHeader     c Date: Thu, 14 Feb 2008 17:51:16 GMT
30 TxHeader     c X-Varnish: 1808069742
30 TxHeader     c Age: 0
30 TxHeader     c Via: 1.1 varnish
30 TxHeader     c Connection: keep-alive
30 ReqEnd       c 1808069742 1203011475.610707998 1203011476.752576113 
0.010195971 1.141789913 0.000078201

Case #2 (Works!)
21 SessionOpen  c X.X.X.X 57601
21 ReqStart     c X.X.X.X 57601 1808069816
21 RxRequest    c GET
21 RxURL        c /notthere/works.htm
21 RxProtocol   c HTTP/1.1
21 RxHeader     c Host: mysite.com
21 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; 
rv:1.8.1.11) Gecko/20080206 Firefox/2.0.0.11
21 RxHeader     c Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
21 RxHeader     c Accept-Language: en-us,en;q=0.5
21 RxHeader     c Accept-Encoding: gzip,deflate
21 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
21 RxHeader     c Keep-Alive: 300
21 RxHeader     c Connection: keep-alive
21 RxHeader     c Cookie: OAX=DCIHAke0f0IADHvs; s_cc=true; s_sq=%5B%5BB%5D%5D
21 VCL_call     c recv lookup
21 VCL_call     c hash hash
21 VCL_call     c miss fetch
21 Backend      c 25 default
21 ObjProtocol  c HTTP/1.1
21 ObjStatus    c 404
21 ObjResponse  c Not Found
21 ObjHeader    c Date: Thu, 14 Feb 2008 17:51:18 GMT
21 ObjHeader    c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
21 ObjHeader    c Set-Cookie: 
JSESSIONID=00AC75B2FFAE9A1406FCE01D8C91DA67.jboss06; Path=/
21 ObjHeader    c Cache-Control: max-age=600
21 ObjHeader    c Expires: Thu, 14 Feb 2008 18:01:18 GMT
21 ObjHeader    c Content-Type: text/html;charset=ISO-8859-1
21 ObjHeader    c Set-Cookie: Coyote-2-c0a81e3d=c0a8823f:0; path=/
21 TTL          c 1808069816 RFC 576 1203011501 1203011478 1203012078 600 0
21 VCL_call     c fetch insert
21 Length       c 450
21 VCL_call     c deliver deliver
21 TxProtocol   c HTTP/1.1
21 TxStatus     c 404
21 TxResponse   c Not Found
21 TxHeader     c Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b 
mod_jk/1.2.25
21 TxHeader     c Cache-Control: max-age=600
21 TxHeader     c Expires: Thu, 14 Feb 2008 18:01:18 GMT
21 TxHeader     c Content-Type: text/html;charset=ISO-8859-1
21 TxHeader     c Content-Length: 450
21 TxHeader     c Date: Thu, 14 Feb 2008 17:51:41 GMT
21 TxHeader     c X-Varnish: 1808069816
21 TxHeader     c Age: 0
21 TxHeader     c Via: 1.1 varnish
21 TxHeader     c Connection: keep-alive
21 ReqEnd       c 1808069816 1203011501.892318964 1203011501.897459984 
0.000262022 0.005100012 0.000041008

Regards,
Ramon A Hermon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080214/57ad45a0/attachment.bin>

From des at linpro.no  Sun Feb 17 23:04:55 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 18 Feb 2008 00:04:55 +0100
Subject: error page not delivered
In-Reply-To: <200802141232.39278.rhermon@chicagosuntimes.com> (Ramon
	A. Hermon's message of "Thu, 14 Feb 2008 12:32:32 -0600")
References: <200802141232.39278.rhermon@chicagosuntimes.com>
Message-ID: <ujrmypzdw14.fsf@login.linpro.no>

Ramon A Hermon <rhermon at chicagosuntimes.com> writes:
> > I am unable to get varnish to deliver the customized error page when
> > requesting a non-existent url.
> I should correct the above statement to "I get a blank page when
> requesting a non-existent directory or html file in the url".

Apparently, you have two caches: one that works correctly and one that
doesn't.

Do they both run the same version and configuration?

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Sun Feb 17 23:16:42 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 18 Feb 2008 00:16:42 +0100
Subject: Help debugging cacheability / ttl information?
In-Reply-To: <17076163.9291201785442139.JavaMail.root@ms1.startsiden.no>
	(Denis =?utf-8?Q?Br=C3=A6khus's?= message of "Thu, 31 Jan 2008 14:17:22
	+0100 (CET)")
References: <17076163.9291201785442139.JavaMail.root@ms1.startsiden.no>
Message-ID: <ujrfxvrdvhh.fsf@login.linpro.no>

Denis Br?khus <denis at startsiden.no> writes:
> What I really am looking for is some help with how to best debug the
> setup with regards to TTLs and cacheability. I'd like to be able to
> inspect a specific cached objects TTL to see if my "set obj.ttl"
> overrides actually work or not. What is the best way to do that?

You should get a varnishlog entry for the TTL computation when an
object is retrieved from the backend, but there won't be a log entry
for VCL changing the TTL...

> On the client I use firebug, so all headers and responess are
> readily available on that end. The reason I don't think everything
> is as it should is that the Age header is very low most of the time.

Instead of Firebug, have you considered using the following:

while :; do
    wget -O/dev/null -S http://www.example.com/ 2>&1 | \
        grep -i '^age:' ;
    sleep 5 ;
done

> For the record we are still at varnish 1.0.4 [...]

1.0.4 is almost a year old...  why not 1.1.2?  It has *much* better
support for examining and modifying HTTP headers.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Sun Feb 17 23:20:26 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 18 Feb 2008 00:20:26 +0100
Subject: Getting the most out of varnish with large files / slow
	connections
In-Reply-To: <200801230851.36142.tb-lists@delc.dk> (Thilo Bangert's message of
	"Wed, 23 Jan 2008 08:51:36 +0100")
References: <1423ECB1-61AB-46AA-B575-1C3B3CC9F5B1@funnyordie.com>
	<200801230851.36142.tb-lists@delc.dk>
Message-ID: <ujrbq6fdvb9.fsf@login.linpro.no>

Thilo Bangert <tb-lists at delc.dk> writes:
> to me, 70k doesnt sound like a large file. OTOH if that is in fact
> the number of objects in your working set, i would consider it
> large.

I know of a Varnish installation (running trunk) with 3 Mobj / 100 GB
in cache, so 70 kobj doesn't seem much to me :)

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From rhermon at chicagosuntimes.com  Mon Feb 18 07:18:51 2008
From: rhermon at chicagosuntimes.com (Ramon A Hermon)
Date: Mon, 18 Feb 2008 01:18:51 -0600
Subject: error page not delivered
In-Reply-To: <ujrmypzdw14.fsf@login.linpro.no>
References: <200802141232.39278.rhermon@chicagosuntimes.com>
	<ujrmypzdw14.fsf@login.linpro.no>
Message-ID: <47B9315B.6090107@chicagosuntimes.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dag-Erling Sm?rgrav wrote:
| Ramon A Hermon <rhermon at chicagosuntimes.com> writes:
|>> I am unable to get varnish to deliver the customized error page when
|>> requesting a non-existent url.
|> I should correct the above statement to "I get a blank page when
|> requesting a non-existent directory or html file in the url".
|
| Apparently, you have two caches: one that works correctly and one that
| doesn't.
|
| Do they both run the same version and configuration?
Only one version is installed with 2 init scripts.

I am not sure how you can tell that I have 2 caches running, if by cache
you mean varnish instances then yes. However I get the same result if I
shut one down.


I run 2 instances in the same physical server one located in
/var/varnish1 and the other in /var/varnish2. I also have 2 other
servers in "hot spare mode" hiding behind the hardware loadbalancer
using the same configuration, but no request should hit those unless my
primary goes down.

$ ps -ef |grep varn
root     29695     1  0 Feb17 ?        00:00:00 /usr/local/sbin/varnishd
- -a :6083 -T localhost:6084 -f /etc/varnish2/default.vcl -n /var/varnish2
- -s file,/var/varnish2/varnish_storage.bin,1G -P /var/run/varnish2.pid
nobody   29696 29695  0 Feb17 ?        00:00:00 /usr/local/sbin/varnishd
- -a :6083 -T localhost:6084 -f /etc/varnish2/default.vcl -n /var/varnish2
- -s file,/var/varnish2/varnish_storage.bin,1G -P /var/run/varnish2.pid
root     32246     1  0 00:20 ?        00:00:00 /usr/local/sbin/varnishd
- -a :6081 -T localhost:6082 -f /etc/varnish1/default.vcl -n /var/varnish1
- -s file,/var/varnish1/varnish_storage.bin,3G -P /var/run/varnish1.pid
nobody   32247 32246  0 00:20 ?        00:00:02 /usr/local/sbin/varnishd
- -a :6081 -T localhost:6082 -f /etc/varnish1/default.vcl -n /var/varnish1
- -s file,/var/varnish1/varnish_storage.bin,3G -P /var/run/varnish1.pid


$ diff /etc/init.d/varnish1 /etc/init.d/varnish2
15,17c15,17
< PROCNAME=varnish1
< PIDFILE=/var/run/varnish1.pid
< LOCKFILE=/var/lock/subsys/varnish1
- ---
| PROCNAME=varnish2
| PIDFILE=/var/run/varnish2.pid
| LOCKFILE=/var/lock/subsys/varnish2
20c20
< . /etc/sysconfig/varnish1
- ---
| . /etc/sysconfig/varnish2
25c25
< mkdir -p /var/run/varnish1 2>/dev/null
- ---
| mkdir -p /var/run/varnish2 2>/dev/null
33c33
<       echo -n "Starting varnish1 HTTP accelerator: "
- ---
|       echo -n "Starting varnish2 HTTP accelerator: "
39c39
<           echo -n "Please put configuration options in
/etc/sysconfig/varnish1"
- ---
|           echo -n "Please put configuration options in
/etc/sysconfig/varnish2"
57c57
<       echo -n "Stopping varnish1 HTTP accelerator: "
- ---
|       echo -n "Stopping varnish2 HTTP accelerator: "

$ diff /etc/sysconfig/varnish1 /etc/sysconfig/varnish2
36,40c36,40
< DAEMON_OPTS="-a :6081 \
<              -T localhost:6082 \
<              -f /etc/varnish1/default.vcl \
<              -n /var/varnish1 \
<              -s file,/var/varnish1/varnish_storage.bin,3G"
- ---
| DAEMON_OPTS="-a :6083 \
|              -T localhost:6084 \
|              -f /etc/varnish2/default.vcl \
|              -n /var/varnish2 \
|              -s file,/var/varnish2/varnish_storage.bin,1G"

$ diff /etc/varnish1/default.vcl /etc/varnish2/default.vcl
9c9
<         set backend.host = "192.168.30.61";
- ---
|         set backend.host = "192.168.30.56";

$ grep -v ^\# /etc/varnish1/default.vcl|grep .
backend default {
~        set backend.host = "192.168.30.61";
~        set backend.port = "80";
}
sub vcl_recv {
~             if (req.request == "GET" && req.http.cookie) {
~                 lookup;
~             }
~         }
~         sub vcl_fetch {
~             if (obj.http.Set-Cookie) {
~                remove obj.http.Set-Cookie;
~             }
~         }


Regards,
Ramon A Hermon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHuTFb2nBs00uoHhwRAgHXAJ4gGNr1iTnB/h2scz+3JpSp+TVhRACgm+bQ
sV/y9yAK1QG0MmWhpIby+ko=
=Mb+R
-----END PGP SIGNATURE-----



From denisb at gmail.com  Mon Feb 18 08:26:28 2008
From: denisb at gmail.com (=?ISO-8859-1?Q?Denis_Br=E6khus?=)
Date: Mon, 18 Feb 2008 09:26:28 +0100
Subject: Help debugging cacheability / ttl information?
Message-ID: <9f26497c0802180026y134cbf10r9118e08618675bc4@mail.gmail.com>

----- "Dag-Erling Sm?rgrav" <des at linpro.no> wrote:
> > setup with regards to TTLs and cacheability. I'd like to be able to
> > inspect a specific cached objects TTL to see if my "set obj.ttl"
> > overrides actually work or not. What is the best way to do that?
> You should get a varnishlog entry for the TTL computation when an
> object is retrieved from the backend, but there won't be a log entry
> for VCL changing the TTL...

Ok, thanks. I guess what I am missing is a VCL debugger of some sort
;) But joke aside, the logentries are definitely helpful, there are
only so many of them it is sometimes a bit overwhelming when you do
not know exactly what you are looking for.

> > On the client I use firebug, so all headers and responess are
> > readily available on that end. The reason I don't think everything
> > is as it should is that the Age header is very low most of the
> time.
> Instead of Firebug, have you considered using the following:
> while :; do
>     wget -O/dev/null -S http://www.example.com/ 2>&1 | \
>         grep -i '^age:' ;
>     sleep 5 ;
> done

Yes, I used curl in a similar fashion, and again the age header seemed
to be a bit low. But it seems the minimum TTL parameter for varnishd
"fixed" this situation for us.

> > For the record we are still at varnish 1.0.4 [...]
> 1.0.4 is almost a year old...  why not 1.1.2?  It has *much* better
> support for examining and modifying HTTP headers.

Well, 1.1.2 is being considered now, but up until 1.1.2 my impression
has been 1.0.4 was the best build with regards to stability. We have
had varnish nodes running for 6-8 months now without interruption or
any problems whatsoever.

List traffic sort of indicated there were always some snags with the
1.1.x builds, but 1.1.2 seems to be working fine for people I gather?!

Regards
-- 
Denis


From ssm at linpro.no  Mon Feb 18 08:52:43 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Mon, 18 Feb 2008 09:52:43 +0100
Subject: Help debugging cacheability / ttl information?
In-Reply-To: <9f26497c0802180026y134cbf10r9118e08618675bc4@mail.gmail.com>
	(Denis =?utf-8?Q?Br=C3=A6khus's?= message of "Mon, 18 Feb 2008 09:26:28
	+0100")
References: <9f26497c0802180026y134cbf10r9118e08618675bc4@mail.gmail.com>
Message-ID: <7xir0m63z8.fsf@iostat.linpro.no>

"Denis Br?khus" <denisb at gmail.com> writes:

> Well, 1.1.2 is being considered now, but up until 1.1.2 my
> impression has been 1.0.4 was the best build with regards to
> stability. We have had varnish nodes running for 6-8 months now
> without interruption or any problems whatsoever.

Until 1.1.2, 1.0.4 was the "stable" stable release.  We're now running
1.1.2 in production at Linpro on many server clusters.

> List traffic sort of indicated there were always some snags with the
> 1.1.x builds, but 1.1.2 seems to be working fine for people I
> gather?!

That is my impression, yes.  

However, you may need:

 set req.http.connection = "close";

in front of "pipe", instead of the defaults.  Especially if you do any
kind of URL rewriting.

-- 
Stig Sandbeck Mathisen, Linpro


From ssm at linpro.no  Mon Feb 18 09:17:33 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Mon, 18 Feb 2008 10:17:33 +0100
Subject: vcl-mode for emacs
Message-ID: <7x7ih2y66q.fsf@iostat.linpro.no>


I've created a "vcl-mode" for emacs.  It does indenting and syntax
highlighting.  

If anyone else out there is still using emacs, I'd be very happy if
you could try it out, and see if anyting is surprising, strange or
missing.  It should work with both emacs and xemacs, but I have not
tested the latter.

It's available at:

http://varnish.projects.linpro.no/browser/trunk/varnish-tools/emacs/vcl-mode.el


Installation
------------

* Put the file "vcl-mode.el" somewhere in your load-path

  ("C-h v load-path RET" shows the contents of the load-path variable)

* Add the following line to your emacs init file, often "~/.emacs"

  (require 'vcl-mode)

* Evaluate the "require" line with "C-x C-e" at the end of that line,
  or start a new emacs.

* Open a file ending in ".vcl".  You should have syntaax highlighting
  and indentation with tab.

Configuration
-------------

The mode can be customized with "M-x customize-group RET vcl RET"

* "Vcl Indent Level" indicates the number of spaces used to indent to
  the next level.  Default 8

* "Vcl Indent Tabs Mode" indicates wether spaces can be replaced by
  TAB characters when indenting.  Default is "nil", which means no
  tabs.

-- 
Stig Sandbeck Mathisen, Linpro


From des at linpro.no  Mon Feb 18 10:52:23 2008
From: des at linpro.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 18 Feb 2008 11:52:23 +0100
Subject: Help debugging cacheability / ttl information?
In-Reply-To: <13529334.191611203322970487.JavaMail.root@ms1.startsiden.no>
	(Denis =?utf-8?Q?Br=C3=A6khus's?= message of "Mon, 18 Feb 2008 09:22:50
	+0100 (CET)")
References: <13529334.191611203322970487.JavaMail.root@ms1.startsiden.no>
Message-ID: <ujrtzk6h6zc.fsf@login.linpro.no>

Denis Br?khus <denis at startsiden.no> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > You should get a varnishlog entry for the TTL computation when an
> > object is retrieved from the backend, but there won't be a log entry
> > for VCL changing the TTL...
> Ok, thanks. I guess what I am missing is a VCL debugger of some sort ;)

There is a VCL trace facility, but I'm not sure it will tell you what
obj.ttl is set to.

> But joke aside, the logentries are definitely helpful, there are
> only so many of them it is sometimes a bit overwhelming when you do
> not know exactly what you are looking for.

Yes, most of them are listed in the man page, but they are not
described.

> > Instead of Firebug, have you considered using the following:
> > while :; do
> >     wget -O/dev/null -S http://www.example.com/ 2>&1 | \
> >         grep -i '^age:' ;
> >     sleep 5 ;
> > done
> Yes, I used curl in a similar fashion, and again the age header
> seemed to be a bit low. But it seems the minimum TTL parameter for
> varnishd "fixed" this situation for us.

I can't remember if 1.0.4 can do this, but I think that in 1.1.2 you
can add a header to the object so you can see the ttl:

set obj.http.X-TTL = obj.ttl

> List traffic sort of indicated there were always some snags with the
> 1.1.x builds, but 1.1.2 seems to be working fine for people I
> gather?!

There should be fewer snags with 1.1 than with 1.0, and especially
with 1.1.2 which had months to mature before release.  There are still
known bugs in it with known solutions, but merging those solutions
would require merging large amounts of other code, and we would
probably end up with 1.1.3 being *less* stable than 1.1.2.  I believe
that most of these bugs are documented in the change log.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From cfarinella at appropriatesolutions.com  Mon Feb 18 22:20:32 2008
From: cfarinella at appropriatesolutions.com (Charlie Farinella)
Date: Mon, 18 Feb 2008 17:20:32 -0500
Subject: http purge help
Message-ID: <200802181720.32892.cfarinella@appropriatesolutions.com>

I am new to Varnish, am trying to implement HTTP purging, and
getting 'not found' responses.  If anyone has a moment to look over
our configuration and make some suggestions or point out errors,
we would be grateful, we are at our wits end.

We have Varnish running behind lighttpd on port 6081 proxying
a Plone installation, so we have lighttpd at port 80, Varnish
at port 6081, and Zope/Plone at port 8080.  All are working as
expected.

uname -n = nec.appropriatesolutions.com

We have our vcl.conf configured like this:
###
acl purge {
                "localhost";
                "127.0.0.1";
}

sub vcl_fetch {
        # force minimum ttl of 300 seconds
        if (obj.ttl < 300s) {
                set obj.ttl = 300s;
        }
}

sub vcl_hit {
        if (req.request == "PURGE") {
                set obj.ttl = 0s;
                error 200 "Purged";
        }
}

sub vcl_miss {
        if (req.request == "PURGE") {
                error 404 "What you have requested is not in cache";
        }
}
###

We are attempting to send the purge request with a Python script, like 
so:
###
#!/usr/local/bin/python
from httplib import HTTP, HTTPConnection, HTTPResponse

h = HTTPConnection('127.0.0.1:6081')
h.request('PURGE', '/', '', {'Host': 'www.nec.edu'})
resp = h.getresponse()
print resp.read()

status = resp.status
reason = resp.reason
headers = resp.getheaders()

print 'status: ', status
print 'reason: ', reason
print

print headers
print
###

Our varnish log is showing:
###
127.0.0.1 - - [18/Feb/2008:16:14:12 -0500] "PURGE http://www.nec.edu/ 
HTTP/1.1" 404 451 "-" "-"

and the output of the script is:
###
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>404 Not Found</title>
  </head>
  <body>
    <h1>Error 404 Not Found</h1>
    <p>What you have requested is not in cache</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 891821294</p>
    <address><a 
href="http://www.varnish-cache.org/">Varnish</a></address>
  </body>
</html>

status:  404
reason:  Not Found

[('content-length', '451'), ('x-varnish', '891821294'), ('age', 'nan'), 
('server', 'Varnish'), ('retry-after', '0')
('connection', 'keep-alive'), ('via', '1.1 varnish'), 
('date', 'Mon, 18 Feb 2008 22:08:49 GMT'), ('content-type', 'text/html; 
charset=utf-8')]

-- 
------------------------------------------------------------------------
Charles Farinella 
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668



From ssm at linpro.no  Tue Feb 19 05:55:40 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Tue, 19 Feb 2008 06:55:40 +0100
Subject: http purge help
In-Reply-To: <200802181720.32892.cfarinella@appropriatesolutions.com> (Charlie
	Farinella's message of "Mon, 18 Feb 2008 17:20:32 -0500")
References: <200802181720.32892.cfarinella@appropriatesolutions.com>
Message-ID: <7xprutpk0z.fsf@iostat.linpro.no>

Charlie Farinella <cfarinella at appropriatesolutions.com> writes:

> We have our vcl.conf configured like this:

You need something in your vcl_recv as well, to match against the
purge acl, and force it to "lookup" on an acl match.  It would go
nicely inside the "pipe if not GET or HEAD request" from the default
vcl like this:

sub vcl_recv {
  # [...]

  if (req.request != "GET" && req.request != "HEAD") {
    if (req.request == "PURGE") {
      if (!client.ip ~ purge) {
        error 405 "Not allowed.";
      }
      lookup;
    }
    set req.http.connection = "close";
    pipe;
  }

  # [...]
}

-- 
Stig Sandbeck Mathisen, Linpro


From andre at idium.no  Tue Feb 19 08:44:52 2008
From: andre at idium.no (=?ISO-8859-1?Q?Andr=E9_=D8ien_Langvand?=)
Date: Tue, 19 Feb 2008 09:44:52 +0100
Subject: VCL purge
Message-ID: <47BA9704.6060507@idium.no>

Hi,

A few days ago, DES wrote the following in reply to another mail:

> > If the point of this is to allow the client to Shift-Reload, you
> > should purge the URL to force a reload from the backend, instead of
> > piping the request.

And the question is, how can I do this? I'm having problems figuring out
what the purge_hash() needs to look like. I guess being allowed to use
purge_hash(req.hash) would be the easiest, but that doesn't work. I've
tried to use several combinations of req.url and req.http.host, but
can't find a working one. purge_hash() is needed because of virtual hosts.


-- 
Andr? ?ien Langvand <andre at idium.no> - PGP: 0x7B1E3468
Systemadministrator - Idium AS - http://www.idium.no


From anders.vannman at vk.se  Tue Feb 19 12:10:24 2008
From: anders.vannman at vk.se (Anders =?ISO-8859-1?Q?V=E4nnman?=)
Date: Tue, 19 Feb 2008 13:10:24 +0100
Subject: obj.tll as string
In-Reply-To: <mailman.956.1203331949.9220.varnish-misc@projects.linpro.no>
References: <mailman.956.1203331949.9220.varnish-misc@projects.linpro.no>
Message-ID: <fc.00802d3c0156464a3b9aca003ed15812.1564660@vk.se>

I tried this code in vcl_fetch in my vcl.conf, but it doesnt work. We are
running varnish-1.1.2

I get error

String representation of 'obj.ttl' not implemented yet



varnish-misc at projects.linpro.no writes:
>I can't remember if 1.0.4 can do this, but I think that in 1.1.2 you
>can add a header to the object so you can see the ttl:
>
>set obj.http.X-TTL = obj.ttl





From cfarinella at appropriatesolutions.com  Tue Feb 19 16:20:12 2008
From: cfarinella at appropriatesolutions.com (Charlie Farinella)
Date: Tue, 19 Feb 2008 11:20:12 -0500
Subject: http purge help
In-Reply-To: <7xprutpk0z.fsf@iostat.linpro.no>
References: <200802181720.32892.cfarinella@appropriatesolutions.com>
	<7xprutpk0z.fsf@iostat.linpro.no>
Message-ID: <200802191120.12383.cfarinella@appropriatesolutions.com>

On Tuesday 19 February 2008, Stig Sandbeck Mathisen wrote:

> You need something in your vcl_recv as well, to match against the
> purge acl, and force it to "lookup" on an acl match.  It would go
> nicely inside the "pipe if not GET or HEAD request" from the default
> vcl like this:
> 
> sub vcl_recv {
>   # [...]
> 
>   if (req.request != "GET" && req.request != "HEAD") {
>     if (req.request == "PURGE") {
>       if (!client.ip ~ purge) {
>         error 405 "Not allowed.";
>       }
>       lookup;
>     }
>     set req.http.connection = "close";
>     pipe;
>   }
> 
>   # [...]
> }

My error, we have this section in our vcl file, I forgot to include it.

Perhaps we just misunderstand what should be happening.  What exactly 
will the command 'PURGE /' remove from the cache?  We are trying to 
empty it.

We need to have web developers have the ability to clear the Varnish 
cache.  Currently we are doing it for them by telneting to the Varnish 
management interface and running 'url.purge *'.  We'd like to protect 
them (and us) from that if possible.

I got several responses, thanks to all, but no joy so far.

-- 
------------------------------------------------------------------------
Charles Farinella 
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668



From cfarinella at appropriatesolutions.com  Wed Feb 20 20:46:22 2008
From: cfarinella at appropriatesolutions.com (Charlie Farinella)
Date: Wed, 20 Feb 2008 15:46:22 -0500
Subject: still trying to purge
Message-ID: <200802201546.22900.cfarinella@appropriatesolutions.com>

Hi all,

For the moment I have given up trying to do the http purge thing and am 
trying to find a workaround.  I have the following shell script:

==
#!/bin/sh
host=127.0.0.1
port=6082
cmd="url.purge"
param=".*"

echo open ${host} ${port}
sleep 1
echo ${cmd} ${param}
sleep 3
echo exit
==

The result of this script is:
==
./clearcache.sh | telnet
telnet> Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
105 20      
Too many parameters
Connection closed by foreign host.
==

If I put any other command in the script, it works fine.  If I 
use 'url.purge' as the command, but '^/$' as the parameter, that works 
fine.  Only the '*' or '.*' throws the 'too many parameters' error.  
What is the correct command and format to purge the entire cache?

If anyone has a solution for me I would be very appreciative.  If I 
cannot find an automated way for the web development people to clear 
this cache at will, I'm going to have to try to set up Apache or Squid 
to do the caching and I'd just rather not do that.  :-)

-- 
------------------------------------------------------------------------
Charles Farinella 
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668



From ltning at anduin.net  Wed Feb 20 21:36:33 2008
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Wed, 20 Feb 2008 22:36:33 +0100
Subject: still trying to purge
In-Reply-To: <200802201546.22900.cfarinella@appropriatesolutions.com>
References: <200802201546.22900.cfarinella@appropriatesolutions.com>
Message-ID: <B5F0A7DB-7340-43E9-9C14-AB4C553B6F49@anduin.net>

On Feb 20, 2008, at 9:46 PM, Charlie Farinella wrote:

> Hi all,
>
> For the moment I have given up trying to do the http purge thing and  
> am
> trying to find a workaround.  I have the following shell script:
>
> ==
> #!/bin/sh
> host=127.0.0.1
> port=6082
> cmd="url.purge"
> param=".*"

Try escaping the * there. It's probably using every file in CWD as  
parameters as you don't quote them further down.

/Eirik

>
>
> echo open ${host} ${port}
> sleep 1
> echo ${cmd} ${param}
> sleep 3
> echo exit
> ==
>
> The result of this script is:
> ==
> ./clearcache.sh | telnet
> telnet> Trying 127.0.0.1...
> Connected to localhost.localdomain (127.0.0.1).
> Escape character is '^]'.
> 105 20
> Too many parameters
> Connection closed by foreign host.
> ==
>
> If I put any other command in the script, it works fine.  If I
> use 'url.purge' as the command, but '^/$' as the parameter, that works
> fine.  Only the '*' or '.*' throws the 'too many parameters' error.
> What is the correct command and format to purge the entire cache?
>
> If anyone has a solution for me I would be very appreciative.  If I
> cannot find an automated way for the web development people to clear
> this cache at will, I'm going to have to try to set up Apache or Squid
> to do the caching and I'd just rather not do that.  :-)
>
> -- 
> ------------------------------------------------------------------------
> Charles Farinella
> Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
> cfarinella at AppropriateSolutions.com
> voice: 603.924.6079   fax: 603.924.8668
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080220/2920fe74/attachment.html>

From cfarinella at appropriatesolutions.com  Wed Feb 20 21:59:43 2008
From: cfarinella at appropriatesolutions.com (Charlie Farinella)
Date: Wed, 20 Feb 2008 16:59:43 -0500
Subject: still trying to purge
In-Reply-To: <200802201546.22900.cfarinella@appropriatesolutions.com>
References: <200802201546.22900.cfarinella@appropriatesolutions.com>
Message-ID: <200802201659.43396.cfarinella@appropriatesolutions.com>

On Wednesday 20 February 2008, Charlie Farinella wrote:

In case anyone has the same problem, this will work:

# scriptname
#!/bin/sh
host=127.0.0.1
port=6082
cmd="url.purge"
 
echo open ${host} ${port}
sleep 1
echo ${cmd} \*
sleep 3
echo exit

$: ./scriptname | telnet

> Hi all,
> 
> For the moment I have given up trying to do the http purge thing and 
am 
> trying to find a workaround.  I have the following shell script:
> 
> ==
> #!/bin/sh
> host=127.0.0.1
> port=6082
> cmd="url.purge"
> param=".*"
> 
> echo open ${host} ${port}
> sleep 1
> echo ${cmd} ${param}
> sleep 3
> echo exit
> ==
> 
> The result of this script is:
> ==
> ./clearcache.sh | telnet
> telnet> Trying 127.0.0.1...
> Connected to localhost.localdomain (127.0.0.1).
> Escape character is '^]'.
> 105 20      
> Too many parameters
> Connection closed by foreign host.
> ==
> 
> If I put any other command in the script, it works fine.  If I 
> use 'url.purge' as the command, but '^/$' as the parameter, that works 
> fine.  Only the '*' or '.*' throws the 'too many parameters' error.  
> What is the correct command and format to purge the entire cache?
> 
> If anyone has a solution for me I would be very appreciative.  If I 
> cannot find an automated way for the web development people to clear 
> this cache at will, I'm going to have to try to set up Apache or Squid 
> to do the caching and I'd just rather not do that.  :-)
> 
> -- 
> ------------------------------------------------------------------------
> Charles Farinella 
> Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
> cfarinella at AppropriateSolutions.com
> voice: 603.924.6079   fax: 603.924.8668
> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
> 
> 



-- 
------------------------------------------------------------------------
Charles Farinella 
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668



From cfarinella at appropriatesolutions.com  Wed Feb 20 22:17:29 2008
From: cfarinella at appropriatesolutions.com (Charlie Farinella)
Date: Wed, 20 Feb 2008 17:17:29 -0500
Subject: still trying to purge
In-Reply-To: <200802201659.43396.cfarinella@appropriatesolutions.com>
References: <200802201546.22900.cfarinella@appropriatesolutions.com>
	<200802201659.43396.cfarinella@appropriatesolutions.com>
Message-ID: <200802201717.29375.cfarinella@appropriatesolutions.com>

As long as I'm being a pain in the neck and asking a lot of questions, I 
have another:

Sometimes ( not always ), purging the cache crashes Varnish.  I have it 
monitored by monit which restarts it, but it would be better if I could 
prevent that.  Is this a known issue?  Misconfiguration?  

Version 1.1.2 installed via rpm on a RedHat Enterprise 5.1 server.

--charlie

On Wednesday 20 February 2008, Charlie Farinella wrote:
> On Wednesday 20 February 2008, Charlie Farinella wrote:
> 
> In case anyone has the same problem, this will work:
> 
> # scriptname
> #!/bin/sh
> host=127.0.0.1
> port=6082
> cmd="url.purge"
>  
> echo open ${host} ${port}
> sleep 1
> echo ${cmd} \*
> sleep 3
> echo exit
> 
> $: ./scriptname | telnet
> 
> > Hi all,
> > 
> > For the moment I have given up trying to do the http purge thing and 
> am 
> > trying to find a workaround.  I have the following shell script:
> > 
> > ==
> > #!/bin/sh
> > host=127.0.0.1
> > port=6082
> > cmd="url.purge"
> > param=".*"
> > 
> > echo open ${host} ${port}
> > sleep 1
> > echo ${cmd} ${param}
> > sleep 3
> > echo exit
> > ==
> > 
> > The result of this script is:
> > ==
> > ./clearcache.sh | telnet
> > telnet> Trying 127.0.0.1...
> > Connected to localhost.localdomain (127.0.0.1).
> > Escape character is '^]'.
> > 105 20      
> > Too many parameters
> > Connection closed by foreign host.
> > ==
> > 
> > If I put any other command in the script, it works fine.  If I 
> > use 'url.purge' as the command, but '^/$' as the parameter, that 
works 
> > fine.  Only the '*' or '.*' throws the 'too many parameters' error.  
> > What is the correct command and format to purge the entire cache?
> > 
> > If anyone has a solution for me I would be very appreciative.  If I 
> > cannot find an automated way for the web development people to clear 
> > this cache at will, I'm going to have to try to set up Apache or 
Squid 
> > to do the caching and I'd just rather not do that.  :-)
> > 
> > -- 
> 
> ------------------------------------------------------------------------
> > Charles Farinella 
> > Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
> > cfarinella at AppropriateSolutions.com
> > voice: 603.924.6079   fax: 603.924.8668
> > 
> > _______________________________________________
> > varnish-misc mailing list
> > varnish-misc at projects.linpro.no
> > http://projects.linpro.no/mailman/listinfo/varnish-misc
> > 
> > 
> 
> 
> 
> -- 
> ------------------------------------------------------------------------
> Charles Farinella 
> Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
> cfarinella at AppropriateSolutions.com
> voice: 603.924.6079   fax: 603.924.8668
> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
> 
> 



-- 
------------------------------------------------------------------------
Charles Farinella 
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668



From andrew at imeem.com  Thu Feb 21 00:04:09 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Wed, 20 Feb 2008 16:04:09 -0800
Subject: Child dying with "Too many open files"
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>

Hello,

 

I'm getting this error when running varnishd:

 

>> 

Child said (2, 15369): <<Assert error in wrk_thread(), cache_pool.c line
217:

  Condition((pipe(w->pipe)) == 0) not true.

  errno = 24 (Too many open files)

>> 

Cache child died pid=15369 status=0x6

 

uname -a:

Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST 2007
x86_64 x86_64 x86_64 GNU/Linux

 

command used to start varnish:

/usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
<internalIP>:6082 -t 120 -w 10,700,30 -s
file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
/var/run/varnish.pid

 

I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need to up
that value?

 

Thanks,

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080220/74ecc2af/attachment.html>

From andrew at imeem.com  Thu Feb 21 00:20:31 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Wed, 20 Feb 2008 16:20:31 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33CE@dexbe014-8.exch014.msoutlookonline.net>

That was stupid...I forgot to say that I'm using the varnish 1.1.2-5
rpm's from sf.net, running on centos 5.

 

From: varnish-misc-bounces at projects.linpro.no
[mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Andrew
Knapp
Sent: Wednesday, February 20, 2008 4:04 PM
To: varnish-misc at projects.linpro.no
Subject: Child dying with "Too many open files"

 

Hello,

 

I'm getting this error when running varnishd:

 

>> 

Child said (2, 15369): <<Assert error in wrk_thread(), cache_pool.c line
217:

  Condition((pipe(w->pipe)) == 0) not true.

  errno = 24 (Too many open files)

>> 

Cache child died pid=15369 status=0x6

 

uname -a:

Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST 2007
x86_64 x86_64 x86_64 GNU/Linux

 

command used to start varnish:

/usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
<internalIP>:6082 -t 120 -w 10,700,30 -s
file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
/var/run/varnish.pid

 

I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need to up
that value?

 

Thanks,

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080220/b786cb13/attachment.html>

From michael at dynamine.net  Thu Feb 21 01:47:38 2008
From: michael at dynamine.net (Michael S. Fischer)
Date: Wed, 20 Feb 2008 17:47:38 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>

Does 'sysctl fs.file-max' say?  It should be >= the ulimit.

--Michael

On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp <andrew at imeem.com> wrote:
>
>
>
>
> Hello,
>
>
>
> I'm getting this error when running varnishd:
>
>
>
> >>
>
> Child said (2, 15369): <<Assert error in wrk_thread(), cache_pool.c line
> 217:
>
>   Condition((pipe(w->pipe)) == 0) not true.
>
>   errno = 24 (Too many open files)
>
> >>
>
> Cache child died pid=15369 status=0x6
>
>
>
> uname ?a:
>
> Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
>
>
> command used to start varnish:
>
> /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
> <internalIP>:6082 -t 120 -w 10,700,30 -s
> file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
> /var/run/varnish.pid
>
>
>
> I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need to up
> that value?
>
>
>
> Thanks,
>
> Andy
> _______________________________________________
>  varnish-misc mailing list
>  varnish-misc at projects.linpro.no
>  http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>


From andrew at imeem.com  Thu Feb 21 01:52:22 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Wed, 20 Feb 2008 17:52:22 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>

Here's the output:

$ sysctl fs.file-max
fs.file-max = 767606

> -----Original Message-----
> From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On Behalf
> Of Michael S. Fischer
> Sent: Wednesday, February 20, 2008 5:48 PM
> To: Andrew Knapp
> Cc: varnish-misc at projects.linpro.no
> Subject: Re: Child dying with "Too many open files"
> 
> Does 'sysctl fs.file-max' say?  It should be >= the ulimit.
> 
> --Michael
> 
> On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp <andrew at imeem.com>
wrote:
> >
> >
> >
> >
> > Hello,
> >
> >
> >
> > I'm getting this error when running varnishd:
> >
> >
> >
> > >>
> >
> > Child said (2, 15369): <<Assert error in wrk_thread(), cache_pool.c
> line
> > 217:
> >
> >   Condition((pipe(w->pipe)) == 0) not true.
> >
> >   errno = 24 (Too many open files)
> >
> > >>
> >
> > Cache child died pid=15369 status=0x6
> >
> >
> >
> > uname -a:
> >
> > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST
> 2007
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> >
> > command used to start varnish:
> >
> > /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
> > <internalIP>:6082 -t 120 -w 10,700,30 -s
> > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
> > /var/run/varnish.pid
> >
> >
> >
> > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need
to
> up
> > that value?
> >
> >
> >
> > Thanks,
> >
> > Andy
> > _______________________________________________
> >  varnish-misc mailing list
> >  varnish-misc at projects.linpro.no
> >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> >
> >


From fredrik.nygren at gotamedia.se  Thu Feb 21 10:39:30 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Thu, 21 Feb 2008 11:39:30 +0100
Subject: Forward client IP address
Message-ID: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se>

Hi,
I'm running Varnish 1.1.2 with Apache at the backend. When I follow  
Apaches access logs all incoming clients have the same IP-number, the  
IP-number of my Varnish server of course. How do I forward the IP- 
number of an incoming request from Varnish to Apaches access logs? Is  
it possible?

Regards
</Fredrik>



From tb-lists at delc.dk  Thu Feb 21 10:55:30 2008
From: tb-lists at delc.dk (Thilo Bangert)
Date: Thu, 21 Feb 2008 11:55:30 +0100
Subject: Forward client IP address
In-Reply-To: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se>
References: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se>
Message-ID: <200802211155.30196.tb-lists@delc.dk>

On Thursday 21 February 2008 11:39:30 Fredrik Nygren wrote:
> Hi,
> I'm running Varnish 1.1.2 with Apache at the backend. When I follow
> Apaches access logs all incoming clients have the same IP-number, the
> IP-number of my Varnish server of course. How do I forward the IP-
> number of an incoming request from Varnish to Apaches access logs? Is
> it possible?

the originating IP address will be forwarded by varnish to you backend in the 
X-Forward-for header.
search the archives and the net for X-Forward-for and you find (among others)
mod_extract_forwarded

>
> Regards
> </Fredrik>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc




From ssm at linpro.no  Thu Feb 21 12:37:36 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Thu, 21 Feb 2008 13:37:36 +0100
Subject: Forward client IP address
In-Reply-To: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se> (Fredrik
	Nygren's message of "Thu, 21 Feb 2008 11:39:30 +0100")
References: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se>
Message-ID: <7xzltu32pb.fsf@iostat.linpro.no>

Fredrik Nygren <fredrik.nygren at gotamedia.se> writes:

> I'm running Varnish 1.1.2 with Apache at the backend. When I follow
> Apaches access logs all incoming clients have the same IP-number,
> the IP-number of my Varnish server of course. How do I forward the
> IP- number of an incoming request from Varnish to Apaches access
> logs? Is it possible?

I've added a recipe for this to the FAQ, see

http://varnish.projects.linpro.no/wiki/FAQ#HowcanIlogtheclientIPaddressonthebackend

(nice long url)
-- 
Stig Sandbeck Mathisen, Linpro


From fredrik.nygren at gotamedia.se  Thu Feb 21 12:41:41 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Thu, 21 Feb 2008 13:41:41 +0100
Subject: Forward client IP address
In-Reply-To: <7xzltu32pb.fsf@iostat.linpro.no>
References: <D64B89F2-FDD1-420B-8391-E7E849C177E7@gotamedia.se>
	<7xzltu32pb.fsf@iostat.linpro.no>
Message-ID: <8DB701A6-DFD6-4DC8-8959-C0519B3D77A2@gotamedia.se>

I'm impressed. Really quick answer. Thank you!

Regards
</Fredrik>

On 21 feb 2008, at 13.37, Stig Sandbeck Mathisen wrote:

Fredrik Nygren <fredrik.nygren at gotamedia.se> writes:

> I'm running Varnish 1.1.2 with Apache at the backend. When I follow
> Apaches access logs all incoming clients have the same IP-number,
> the IP-number of my Varnish server of course. How do I forward the
> IP- number of an incoming request from Varnish to Apaches access
> logs? Is it possible?

I've added a recipe for this to the FAQ, see

http://varnish.projects.linpro.no/wiki/FAQ#HowcanIlogtheclientIPaddressonthebackend

(nice long url)
-- 
Stig Sandbeck Mathisen, Linpro
_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc



From ay at vg.no  Thu Feb 21 19:28:21 2008
From: ay at vg.no (Audun Ytterdal)
Date: Thu, 21 Feb 2008 20:28:21 +0100
Subject: Debugging of Child dies under heavy load and empty cache
Message-ID: <47BDD0D5.3000806@vg.no>

Symtoms: When restarting all frontend varnishes at once they keep 
crashing (child dies,parent lives) with a frequncy of once every second 
to maybe once every 50 seconds. After mabye 10-15 minuttes they stop 
crashing.

Running trunk revision 2519 2524.

Running with -d -d revealed following


Child said (2, 32302): <<Child starts>>
Child said (2, 32302): <<managed to mmap 32212254720 bytes of 32212254720>>
Child said (2, 32302): <<Ready>>
Child said (2, 32302): <<Assert error in SES_Delete(), cache_session.c 
line 340:>>
Child said (2, 32302): <<  Condition((sp->vcl) == 0) not true.>>
Cache child died pid=32302 status=0x6
Clean child
Child cleaned

By changing


AZ(sp->vcl);

to

spassert(sp->vcl == 0)

I got a ton of these

start child pid 30356
Child said (2, 30356): <<Child starts>>
Child said (2, 30356): <<managed to mmap 32212254720 bytes of 32212254720>>
Child said (2, 30356): <<Ready>>
Child said (2, 30356): <<panic in SES_Delete() at cache_session.c:340>>
Child said (2, 30356): <<assertion failed: sp->vcl>>
Child said (2, 30356): <<sp = 0x327cf5ec08 {>>
Child said (2, 30356): <<  fd = -1, id = 1134, xid = 0,>>
Child said (2, 30356): <<  client = 81.166.235.84:13142,>>
Child said (2, 30356): <<  step = STP_DONE,>>
Child said (2, 30356): <<},>>
Cache child died pid=30356 status=0x6
Clean child
Child cleaned

*****************************************************************
Denne fotnoten bekrefter at denne e-postmeldingen ble
skannet av MailSweeper og funnet fri for virus.
*****************************************************************
This footnote confirms that this email message has been 
swept by MailSweeper for the presence of computer viruses.
*****************************************************************



From ay at vg.no  Thu Feb 21 20:07:23 2008
From: ay at vg.no (Audun Ytterdal)
Date: Thu, 21 Feb 2008 21:07:23 +0100
Subject: Debugging of Child dies under heavy load and empty cache
In-Reply-To: <47BDD0D5.3000806@vg.no>
References: <47BDD0D5.3000806@vg.no>
Message-ID: <47BDD9FB.1070307@vg.no>


> spassert(sp->vcl == 0)

Well, not really, forgot to == 0..

> I got a ton of these
> 
> start child pid 30356
> Child said (2, 30356): <<Child starts>>
> Child said (2, 30356): <<managed to mmap 32212254720 bytes of 32212254720>>
> Child said (2, 30356): <<Ready>>
> Child said (2, 30356): <<panic in SES_Delete() at cache_session.c:340>>
> Child said (2, 30356): <<assertion failed: sp->vcl>>
> Child said (2, 30356): <<sp = 0x327cf5ec08 {>>
> Child said (2, 30356): <<  fd = -1, id = 1134, xid = 0,>>
> Child said (2, 30356): <<  client = 81.166.235.84:13142,>>
> Child said (2, 30356): <<  step = STP_DONE,>>
> Child said (2, 30356): <<},>>
> Cache child died pid=30356 status=0x6
> Clean child
> Child cleaned

So these are the correct ones.

Here is what really happends

start child pid 29643
Child said (2, 29643): <<Child starts>>
Child said (2, 29643): <<managed to mmap 32212254720 bytes of 32212254720>>
Child said (2, 29643): <<Ready>>
Child said (2, 29643): <<panic in SES_Delete() at cache_session.c:340>>
Child said (2, 29643): <<assertion failed: sp->vcl == 0>>
Child said (2, 29643): <<sp = 0x3304307808 {>>
Child said (2, 29643): <<  fd = -1, id = 1926, xid = 790060728,>>
Child said (2, 29643): <<  client = 84.202.232.251:10359,>>
Child said (2, 29643): <<  step = STP_LOOKUP,>>
Child said (2, 29643): <<},>>
Manager got SIGINT
Clean child
Child stopping
unlink ./vcl.OaGbHZXp.o

*****************************************************************
Denne fotnoten bekrefter at denne e-postmeldingen ble
skannet av MailSweeper og funnet fri for virus.
*****************************************************************
This footnote confirms that this email message has been 
swept by MailSweeper for the presence of computer viruses.
*****************************************************************



From ssm at linpro.no  Fri Feb 22 07:28:38 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Fri, 22 Feb 2008 08:28:38 +0100
Subject: http purge help
In-Reply-To: <200802191120.12383.cfarinella@appropriatesolutions.com> (Charlie
	Farinella's message of "Tue, 19 Feb 2008 11:20:12 -0500")
References: <200802181720.32892.cfarinella@appropriatesolutions.com>
	<7xprutpk0z.fsf@iostat.linpro.no>
	<200802191120.12383.cfarinella@appropriatesolutions.com>
Message-ID: <7xve4h30wp.fsf@iostat.linpro.no>

Charlie Farinella <cfarinella at appropriatesolutions.com> writes:

> Perhaps we just misunderstand what should be happening.  What
> exactly will the command 'PURGE /' remove from the cache?  We are
> trying to empty it.

It will purge the document hashed with the host name in the Host:
header.  If you send a PURGE, you need to send one request per host
name for every hostname that can be used to access that page.  If you
have several hostnames, you will need to purge for instance:

* http://www.example.com/KjempeStortPinnsvin

  PURGE / HTTP/1.1
  Host: www.example.com
  

* http://home.example.com/KjempeStortPinnsvin

  PURGE / HTTP/1.1
  Host: home.example.com

* http://example.com/KjempeStortPinnsvin

  PURGE / HTTP/1.1
  Host: home.example.com

If you add more items to your hash used to store and lookup items in
Varnish, this can soon get out of hand. :D

Running "varnishlog" will give you lots and lots of details.  See
http://varnish.projects.linpro.no/wiki/FAQ#HowcanIdebugtherequestsofasingleclient
for how to limit the output to just your client.

> We need to have web developers have the ability to clear the Varnish
> cache.  Currently we are doing it for them by telneting to the
> Varnish management interface and running 'url.purge *'.  We'd like
> to protect them (and us) from that if possible.

That's a good thought. :D

-- 
Stig Sandbeck Mathisen, Linpro


From ssm at linpro.no  Fri Feb 22 07:38:08 2008
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Fri, 22 Feb 2008 08:38:08 +0100
Subject: http purge help
In-Reply-To: <7xve4h30wp.fsf@iostat.linpro.no> (Stig Sandbeck Mathisen's
	message of "Fri, 22 Feb 2008 08:28:38 +0100")
References: <200802181720.32892.cfarinella@appropriatesolutions.com>
	<7xprutpk0z.fsf@iostat.linpro.no>
	<200802191120.12383.cfarinella@appropriatesolutions.com>
	<7xve4h30wp.fsf@iostat.linpro.no>
Message-ID: <7xk5kx30gv.fsf@iostat.linpro.no>

Stig Sandbeck Mathisen <ssm at linpro.no> writes:

> * http://www.example.com/KjempeStortPinnsvin
>
>   PURGE / HTTP/1.1
>   Host: www.example.com

I'm not at my best after just one cup of coffee, sory.  This should be:

PURGE /KjempeStortPinnsvin HTTP/1.1

...of course.  Same with the two others.

-- 
Stig Sandbeck Mathisen, Linpro


From chulmin2 at hotmail.com  Sat Feb 23 13:19:16 2008
From: chulmin2 at hotmail.com (MontyRee)
Date: Sat, 23 Feb 2008 13:19:16 +0000
Subject: caches something when cancel the downloading?
Message-ID: <BLU116-W1207F36765F786F364E5BC851E0@phx.gbl>


Hello list. When downloading the large file for example, 100Mbyte through varnishd (1.1.2), if someone cancel the downloading at 10Mbyte, Question: varnishd caches 100Mbyte or 10Mbyte or not cache? Thanks for your help. Regards.
_________________________________________________________________
?? ??? ??, Windows Live Space!  
http://www.spaces.live.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20080223/86a7572a/attachment.html>

From perbu at linpro.no  Mon Feb 25 11:13:40 2008
From: perbu at linpro.no (Per Andreas Buer)
Date: Mon, 25 Feb 2008 12:13:40 +0100
Subject: caches something when cancel the downloading?
In-Reply-To: <BLU116-W1207F36765F786F364E5BC851E0@phx.gbl>
References: <BLU116-W1207F36765F786F364E5BC851E0@phx.gbl>
Message-ID: <47C2A2E4.3000709@linpro.no>

MontyRee skrev:
>     Hello list.
>      
>     When downloading the large file for example, 100Mbyte through
>     varnishd (1.1.2),
>     if someone cancel the downloading at 10Mbyte,
> 
>     Question: varnishd caches 100Mbyte or 10Mbyte or not cache?

Last time I checked Varnish would fetch the _whole_ object from backend
before serving it. So the whole 100MByte would be cached.



Per.


From duja at torlen.net  Wed Feb 27 08:48:04 2008
From: duja at torlen.net (Erik)
Date: Wed, 27 Feb 2008 09:48:04 +0100
Subject: Varnishlogging
Message-ID: <x52bbb4h152un4u.270220080948@torlen.net>

Is it possible to log many different tags and match just one of them against a regex?

For example. I want to include TxUrl, TxResponse, ReqStart, ReqEnd and match TxResponse against regex "Service Unavailable".

/ Erik



From phk at phk.freebsd.dk  Wed Feb 27 08:49:25 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 27 Feb 2008 08:49:25 +0000
Subject: Varnishlogging 
In-Reply-To: Your message of "Wed, 27 Feb 2008 09:48:04 +0100."
	<x52bbb4h152un4u.270220080948@torlen.net> 
Message-ID: <16495.1204102165@critter.freebsd.dk>

In message <x52bbb4h152un4u.270220080948 at torlen.net>, Erik writes:
>Is it possible to log many different tags and match just one of them against a regex?
>
>For example. I want to include TxUrl, TxResponse, ReqStart, ReqEnd and match TxResponse against regex "Service Unavailable".

Not currently, but we'd love to see a patch :-)

Actually, what I would really love to see, is a varnishlog with a
specification language of the sort tcpdump(8) takes, so that specific
queries can be formulated without me having to predict anything people
could be interested in seeing.

-- 
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 duja at torlen.net  Wed Feb 27 09:16:08 2008
From: duja at torlen.net (Erik)
Date: Wed, 27 Feb 2008 10:16:08 +0100
Subject: Varnishlogging
Message-ID: <rvaxsvmy3fmh60n.270220081016@torlen.net>

Ah ok, I see :( Unfortunately i'm not a c++ guru so I can just cross my fingers and hope that some handy guy writes a patch.

A specifikation language like tcpdump's would be nice. I will cross my fingers for that to :P

/ Erik

Original Message -----------------------

Not currently, but we'd love to see a patch :-)

Actually, what I would really love to see, is a varnishlog with a
specification language of the sort tcpdump(8) takes, so that specific
queries can be formulated without me having to predict anything people
could be interested in seeing.

-- 
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 duja at torlen.net  Wed Feb 27 15:55:54 2008
From: duja at torlen.net (Erik)
Date: Wed, 27 Feb 2008 16:55:54 +0100
Subject: Deliver ReqEnd in http header
Message-ID: <40zeulwe24yossl.270220081655@torlen.net>

I suspect that this cant be done right now but Ill ask anyway.

In varnishlog you have the reqend field with some interesting times. My question is if I could include these times in one or more http headerfields when varnish delivers the response (vcl_deliver).

Varnishlog often gets very big and in my opinion it would be easier to use, for ex. LiveHttp Header in firefox or something similiar, to see the step that took time.

ReqEnd Example:
2039158367 1158180241.888800123 1158180241.888854881 0.005646787 0.000015924 0.000038834
 XID        Request timestamp    Complete timestamp   Idle time   proc.time   xmit time

/ Erik



From phk at phk.freebsd.dk  Wed Feb 27 16:01:42 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 27 Feb 2008 16:01:42 +0000
Subject: Deliver ReqEnd in http header 
In-Reply-To: Your message of "Wed, 27 Feb 2008 16:55:54 +0100."
	<40zeulwe24yossl.270220081655@torlen.net> 
Message-ID: <1572.1204128102@critter.freebsd.dk>

In message <40zeulwe24yossl.270220081655 at torlen.net>, Erik writes:
>I suspect that this cant be done right now but Ill ask anyway.
>
>In varnishlog you have the reqend field with some interesting times. My question is if I could include these times in one or more http headerfields when varnish delivers the response (vcl_deliver).
>
>Varnishlog often gets very big and in my opinion it would be easier to use, for ex. LiveHttp Header in firefox or something similiar, to see the step that took time.
>
>ReqEnd Example:
>2039158367 1158180241.888800123 1158180241.888854881 0.005646787 0.000015924 0.000038834
> XID        Request timestamp    Complete timestamp   Idle time   proc.time   xmit time

Well, obviously you cannot have timestamps that are taken after we
compose the headers for transmission, but otherwise it wouldn't be
impossible.

-- 
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 duja at torlen.net  Wed Feb 27 17:28:29 2008
From: duja at torlen.net (Erik Torlen)
Date: Wed, 27 Feb 2008 18:28:29 +0100
Subject: Deliver ReqEnd in http header
In-Reply-To: <1572.1204128102@critter.freebsd.dk>
References: <1572.1204128102@critter.freebsd.dk>
Message-ID: <47C59DBD.1060101@torlen.net>

But we could take those timestamps that we would be able to compose 
before the transmission of headers :)

This would be cool to have. Is it alot of code to implent? Can I as a 
"almost-a-newbie" go into the code? :P

/ Erik

Poul-Henning Kamp skrev:
> In message <40zeulwe24yossl.270220081655 at torlen.net>, Erik writes:
>   
>> I suspect that this cant be done right now but Ill ask anyway.
>>
>> In varnishlog you have the reqend field with some interesting times. My question is if I could include these times in one or more http headerfields when varnish delivers the response (vcl_deliver).
>>
>> Varnishlog often gets very big and in my opinion it would be easier to use, for ex. LiveHttp Header in firefox or something similiar, to see the step that took time.
>>
>> ReqEnd Example:
>> 2039158367 1158180241.888800123 1158180241.888854881 0.005646787 0.000015924 0.000038834
>> XID        Request timestamp    Complete timestamp   Idle time   proc.time   xmit time
>>     
>
> Well, obviously you cannot have timestamps that are taken after we
> compose the headers for transmission, but otherwise it wouldn't be
> impossible.
>
>   



From phk at phk.freebsd.dk  Wed Feb 27 22:58:24 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 27 Feb 2008 22:58:24 +0000
Subject: Deliver ReqEnd in http header 
In-Reply-To: Your message of "Wed, 27 Feb 2008 18:28:29 +0100."
	<47C59DBD.1060101@torlen.net> 
Message-ID: <4274.1204153104@critter.freebsd.dk>

In message <47C59DBD.1060101 at torlen.net>, Erik Torlen writes:
>But we could take those timestamps that we would be able to compose 
>before the transmission of headers :)
>
>This would be cool to have. Is it alot of code to implent? Can I as a 
>"almost-a-newbie" go into the code? :P

It's not too terrible, but not entirely simple either.

You need to add an VCL object (see the lib/libvcl/*.tcl files, then
add the necessary stuff in the .c files)

Then you need to at the VCL RunTime ("VRT") functions in cache_vrt.c.

-- 
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 duja at torlen.net  Thu Feb 28 10:03:38 2008
From: duja at torlen.net (Erik)
Date: Thu, 28 Feb 2008 11:03:38 +0100
Subject: Deliver ReqEnd in http header
Message-ID: <e5ehkhqnt77ulio.280220081103@torlen.net>

Okey... I started to add some things that looked ok to me. But I have a feeling that I cannot use "string". Here is what I did:

On line 551 in vcc_fixed_token.c:
+ vsb_cat(sb, "string VRT_r_reqend(const struct sess *);\n");

On line 208-211 in vcc_gen_obj.tcl:
+ { reqend	RO STRING
+ 	{deliver}
+ 	"const struct sess *"
+ }

On line 224-230 in vcc_obj.c:
+ { "reqend", STRING, 15,
+    "VRT_r_now(sp)",
+    NULL,
+    V_RO,
+    0,
+    VCL_MET_DELIVER
+},

On line 532-539 in cache_vrt.c:
+ /* REQEND */
+ string
+ VRT_r_reqend(const struct sess *sp)
+ {
+	(void)sp;
+	return ("Test");
+ }

Seems a little bit easy to be allright :P

Any tip? ("stop wasting your time in a code you cant understand" ;)

/ Erik

Original Message -----------------------

It's not too terrible, but not entirely simple either.

You need to add an VCL object (see the lib/libvcl/*.tcl files, then
add the necessary stuff in the .c files)

Then you need to at the VCL RunTime ("VRT") functions in cache_vrt.c.

-- 
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 anders.vannman at vk.se  Thu Feb 28 11:00:06 2008
From: anders.vannman at vk.se (Anders =?ISO-8859-1?Q?V=E4nnman?=)
Date: Thu, 28 Feb 2008 12:00:06 +0100
Subject: varnish-misc Digest, Vol 23, Issue 23
Message-ID: <fc.00802d3c01580f6f3b9aca003a636186.1580f70@vk.se>

Jag har semester. Maila till support at vk.se eller ring  090-70 84 70 om det
g?ller n?got support?rende.



From andrew at imeem.com  Thu Feb 28 19:48:25 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Thu, 28 Feb 2008 11:48:25 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net><86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>

Didn't really get a answer to this, so I'm trying again.

I've done some testing with the NFILES variable, and I keep getting the
same error as before ("Too many open files"). I've also verified that
the limit is actually being applied by putting a ulimit -a in the
/etc/init.d/varnish script.

Anyone have any ideas? I'm running the 1.1.2-5 rpms from sf.net on
Centos 5.1.

Thanks,
Andy

> -----Original Message-----
> From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-
> bounces at projects.linpro.no] On Behalf Of Andrew Knapp
> Sent: Wednesday, February 20, 2008 5:52 PM
> To: Michael S. Fischer
> Cc: varnish-misc at projects.linpro.no
> Subject: RE: Child dying with "Too many open files"
> 
> Here's the output:
> 
> $ sysctl fs.file-max
> fs.file-max = 767606
> 
> > -----Original Message-----
> > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On
> Behalf
> > Of Michael S. Fischer
> > Sent: Wednesday, February 20, 2008 5:48 PM
> > To: Andrew Knapp
> > Cc: varnish-misc at projects.linpro.no
> > Subject: Re: Child dying with "Too many open files"
> >
> > Does 'sysctl fs.file-max' say?  It should be >= the ulimit.
> >
> > --Michael
> >
> > On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp <andrew at imeem.com>
> wrote:
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > I'm getting this error when running varnishd:
> > >
> > >
> > >
> > > >>
> > >
> > > Child said (2, 15369): <<Assert error in wrk_thread(),
cache_pool.c
> > line
> > > 217:
> > >
> > >   Condition((pipe(w->pipe)) == 0) not true.
> > >
> > >   errno = 24 (Too many open files)
> > >
> > > >>
> > >
> > > Cache child died pid=15369 status=0x6
> > >
> > >
> > >
> > > uname -a:
> > >
> > > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST
> > 2007
> > > x86_64 x86_64 x86_64 GNU/Linux
> > >
> > >
> > >
> > > command used to start varnish:
> > >
> > > /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
> > > <internalIP>:6082 -t 120 -w 10,700,30 -s
> > > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
> > > /var/run/varnish.pid
> > >
> > >
> > >
> > > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need
> to
> > up
> > > that value?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Andy
> > > _______________________________________________
> > >  varnish-misc mailing list
> > >  varnish-misc at projects.linpro.no
> > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> > >
> > >
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc


From michael at dynamine.net  Thu Feb 28 21:56:30 2008
From: michael at dynamine.net (Michael S. Fischer)
Date: Thu, 28 Feb 2008 13:56:30 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
	<0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <86db848d0802281356l7cf41a5g9dc24327bb065ba8@mail.gmail.com>

Is varnishd being started as root?  (even if it drops privileges
later) Only root can have > 1024 file descriptors open, to my
knowledge.

--Michael

On Thu, Feb 28, 2008 at 11:48 AM, Andrew Knapp <andrew at imeem.com> wrote:
> Didn't really get a answer to this, so I'm trying again.
>
>  I've done some testing with the NFILES variable, and I keep getting the
>  same error as before ("Too many open files"). I've also verified that
>  the limit is actually being applied by putting a ulimit -a in the
>  /etc/init.d/varnish script.
>
>  Anyone have any ideas? I'm running the 1.1.2-5 rpms from sf.net on
>  Centos 5.1.
>
>  Thanks,
>  Andy
>
>
>  > -----Original Message-----
>  > From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-
>  > bounces at projects.linpro.no] On Behalf Of Andrew Knapp
>
> > Sent: Wednesday, February 20, 2008 5:52 PM
>  > To: Michael S. Fischer
>  > Cc: varnish-misc at projects.linpro.no
>
>
> > Subject: RE: Child dying with "Too many open files"
>  >
>  > Here's the output:
>  >
>  > $ sysctl fs.file-max
>  > fs.file-max = 767606
>  >
>  > > -----Original Message-----
>  > > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On
>  > Behalf
>  > > Of Michael S. Fischer
>  > > Sent: Wednesday, February 20, 2008 5:48 PM
>  > > To: Andrew Knapp
>  > > Cc: varnish-misc at projects.linpro.no
>  > > Subject: Re: Child dying with "Too many open files"
>  > >
>  > > Does 'sysctl fs.file-max' say?  It should be >= the ulimit.
>  > >
>  > > --Michael
>  > >
>  > > On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp <andrew at imeem.com>
>  > wrote:
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > Hello,
>  > > >
>  > > >
>  > > >
>  > > > I'm getting this error when running varnishd:
>  > > >
>  > > >
>  > > >
>  > > > >>
>  > > >
>  > > > Child said (2, 15369): <<Assert error in wrk_thread(),
>  cache_pool.c
>  > > line
>  > > > 217:
>  > > >
>  > > >   Condition((pipe(w->pipe)) == 0) not true.
>  > > >
>  > > >   errno = 24 (Too many open files)
>  > > >
>  > > > >>
>  > > >
>  > > > Cache child died pid=15369 status=0x6
>  > > >
>  > > >
>  > > >
>  > > > uname -a:
>  > > >
>  > > > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST
>  > > 2007
>  > > > x86_64 x86_64 x86_64 GNU/Linux
>  > > >
>  > > >
>  > > >
>  > > > command used to start varnish:
>  > > >
>  > > > /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
>  > > > <internalIP>:6082 -t 120 -w 10,700,30 -s
>  > > > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g varnish -P
>  > > > /var/run/varnish.pid
>  > > >
>  > > >
>  > > >
>  > > > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just need
>  > to
>  > > up
>  > > > that value?
>  > > >
>  > > >
>  > > >
>  > > > Thanks,
>  > > >
>  > > > Andy
>  > > > _______________________________________________
>  > > >  varnish-misc mailing list
>  > > >  varnish-misc at projects.linpro.no
>  > > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
>  > > >
>  > > >
>  > _______________________________________________
>  > varnish-misc mailing list
>  > varnish-misc at projects.linpro.no
>  > http://projects.linpro.no/mailman/listinfo/varnish-misc
>  _______________________________________________
>  varnish-misc mailing list
>  varnish-misc at projects.linpro.no
>  http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>


From andrew at imeem.com  Thu Feb 28 22:58:12 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Thu, 28 Feb 2008 14:58:12 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <86db848d0802281356l7cf41a5g9dc24327bb065ba8@mail.gmail.com>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
	<0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802281356l7cf41a5g9dc24327bb065ba8@mail.gmail.com>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA020EA84C@dexbe014-8.exch014.msoutlookonline.net>

Yup, it is. Here's some output:

$ ps auxwww | grep varnish
root     12036  0.0  0.0  27704   648 ?        Ss   14:54   0:00
/usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T <internalip>:6082
-t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
varnish -g varnish -P /var/run/varnish.pid
varnish  12037  1.2  0.4 13119108 39936 ?      Sl   14:54   0:00
/usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T <internalip>:6082
-t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
varnish -g varnish -P /var/run/varnish.pid

-Andy

> -----Original Message-----
> From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On Behalf
> Of Michael S. Fischer
> Sent: Thursday, February 28, 2008 1:57 PM
> To: Andrew Knapp
> Cc: varnish-misc at projects.linpro.no
> Subject: Re: Child dying with "Too many open files"
> 
> Is varnishd being started as root?  (even if it drops privileges
> later) Only root can have > 1024 file descriptors open, to my
> knowledge.
> 
> --Michael
> 
> On Thu, Feb 28, 2008 at 11:48 AM, Andrew Knapp <andrew at imeem.com>
> wrote:
> > Didn't really get a answer to this, so I'm trying again.
> >
> >  I've done some testing with the NFILES variable, and I keep getting
> the
> >  same error as before ("Too many open files"). I've also verified
> that
> >  the limit is actually being applied by putting a ulimit -a in the
> >  /etc/init.d/varnish script.
> >
> >  Anyone have any ideas? I'm running the 1.1.2-5 rpms from sf.net on
> >  Centos 5.1.
> >
> >  Thanks,
> >  Andy
> >
> >
> >  > -----Original Message-----
> >  > From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-
> misc-
> >  > bounces at projects.linpro.no] On Behalf Of Andrew Knapp
> >
> > > Sent: Wednesday, February 20, 2008 5:52 PM
> >  > To: Michael S. Fischer
> >  > Cc: varnish-misc at projects.linpro.no
> >
> >
> > > Subject: RE: Child dying with "Too many open files"
> >  >
> >  > Here's the output:
> >  >
> >  > $ sysctl fs.file-max
> >  > fs.file-max = 767606
> >  >
> >  > > -----Original Message-----
> >  > > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On
> >  > Behalf
> >  > > Of Michael S. Fischer
> >  > > Sent: Wednesday, February 20, 2008 5:48 PM
> >  > > To: Andrew Knapp
> >  > > Cc: varnish-misc at projects.linpro.no
> >  > > Subject: Re: Child dying with "Too many open files"
> >  > >
> >  > > Does 'sysctl fs.file-max' say?  It should be >= the ulimit.
> >  > >
> >  > > --Michael
> >  > >
> >  > > On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp
<andrew at imeem.com>
> >  > wrote:
> >  > > >
> >  > > >
> >  > > >
> >  > > >
> >  > > > Hello,
> >  > > >
> >  > > >
> >  > > >
> >  > > > I'm getting this error when running varnishd:
> >  > > >
> >  > > >
> >  > > >
> >  > > > >>
> >  > > >
> >  > > > Child said (2, 15369): <<Assert error in wrk_thread(),
> >  cache_pool.c
> >  > > line
> >  > > > 217:
> >  > > >
> >  > > >   Condition((pipe(w->pipe)) == 0) not true.
> >  > > >
> >  > > >   errno = 24 (Too many open files)
> >  > > >
> >  > > > >>
> >  > > >
> >  > > > Cache child died pid=15369 status=0x6
> >  > > >
> >  > > >
> >  > > >
> >  > > > uname -a:
> >  > > >
> >  > > > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55
> EST
> >  > > 2007
> >  > > > x86_64 x86_64 x86_64 GNU/Linux
> >  > > >
> >  > > >
> >  > > >
> >  > > > command used to start varnish:
> >  > > >
> >  > > > /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
> >  > > > <internalIP>:6082 -t 120 -w 10,700,30 -s
> >  > > > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g
> varnish -P
> >  > > > /var/run/varnish.pid
> >  > > >
> >  > > >
> >  > > >
> >  > > > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just
> need
> >  > to
> >  > > up
> >  > > > that value?
> >  > > >
> >  > > >
> >  > > >
> >  > > > Thanks,
> >  > > >
> >  > > > Andy
> >  > > > _______________________________________________
> >  > > >  varnish-misc mailing list
> >  > > >  varnish-misc at projects.linpro.no
> >  > > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> >  > > >
> >  > > >
> >  > _______________________________________________
> >  > varnish-misc mailing list
> >  > varnish-misc at projects.linpro.no
> >  > http://projects.linpro.no/mailman/listinfo/varnish-misc
> >  _______________________________________________
> >  varnish-misc mailing list
> >  varnish-misc at projects.linpro.no
> >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> >
> >


From michael at dynamine.net  Thu Feb 28 23:51:02 2008
From: michael at dynamine.net (Michael S. Fischer)
Date: Thu, 28 Feb 2008 15:51:02 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <0A3A6EA86530E64EA3BEA603EC4401CA020EA84C@dexbe014-8.exch014.msoutlookonline.net>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
	<0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802281356l7cf41a5g9dc24327bb065ba8@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA020EA84C@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <86db848d0802281551j3dfa0221v5e9867bd340b40e3@mail.gmail.com>

I can't help but wonder if you'd set it too high.  What happens when
you set NFILES and fs.file-max both to 131072?  I've tested that as a
known good value.

--Michael

On Thu, Feb 28, 2008 at 2:58 PM, Andrew Knapp <andrew at imeem.com> wrote:
> Yup, it is. Here's some output:
>
>  $ ps auxwww | grep varnish
>  root     12036  0.0  0.0  27704   648 ?        Ss   14:54   0:00
>  /usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T <internalip>:6082
>
> -t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
>  varnish -g varnish -P /var/run/varnish.pid
>  varnish  12037  1.2  0.4 13119108 39936 ?      Sl   14:54   0:00
>  /usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T <internalip>:6082
>
> -t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
>  varnish -g varnish -P /var/run/varnish.pid
>
>  -Andy
>
>
>  > -----Original Message-----
>  > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On Behalf
>  > Of Michael S. Fischer
>
>
> > Sent: Thursday, February 28, 2008 1:57 PM
>  > To: Andrew Knapp
>  > Cc: varnish-misc at projects.linpro.no
>  > Subject: Re: Child dying with "Too many open files"
>  >
>  > Is varnishd being started as root?  (even if it drops privileges
>  > later) Only root can have > 1024 file descriptors open, to my
>  > knowledge.
>  >
>  > --Michael
>  >
>  > On Thu, Feb 28, 2008 at 11:48 AM, Andrew Knapp <andrew at imeem.com>
>  > wrote:
>  > > Didn't really get a answer to this, so I'm trying again.
>  > >
>  > >  I've done some testing with the NFILES variable, and I keep getting
>  > the
>  > >  same error as before ("Too many open files"). I've also verified
>  > that
>  > >  the limit is actually being applied by putting a ulimit -a in the
>  > >  /etc/init.d/varnish script.
>  > >
>  > >  Anyone have any ideas? I'm running the 1.1.2-5 rpms from sf.net on
>  > >  Centos 5.1.
>  > >
>  > >  Thanks,
>  > >  Andy
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-
>  > misc-
>  > >  > bounces at projects.linpro.no] On Behalf Of Andrew Knapp
>  > >
>  > > > Sent: Wednesday, February 20, 2008 5:52 PM
>  > >  > To: Michael S. Fischer
>  > >  > Cc: varnish-misc at projects.linpro.no
>  > >
>  > >
>  > > > Subject: RE: Child dying with "Too many open files"
>  > >  >
>  > >  > Here's the output:
>  > >  >
>  > >  > $ sysctl fs.file-max
>  > >  > fs.file-max = 767606
>  > >  >
>  > >  > > -----Original Message-----
>  > >  > > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On
>  > >  > Behalf
>  > >  > > Of Michael S. Fischer
>  > >  > > Sent: Wednesday, February 20, 2008 5:48 PM
>  > >  > > To: Andrew Knapp
>  > >  > > Cc: varnish-misc at projects.linpro.no
>  > >  > > Subject: Re: Child dying with "Too many open files"
>  > >  > >
>  > >  > > Does 'sysctl fs.file-max' say?  It should be >= the ulimit.
>  > >  > >
>  > >  > > --Michael
>  > >  > >
>  > >  > > On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp
>  <andrew at imeem.com>
>  > >  > wrote:
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > Hello,
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > I'm getting this error when running varnishd:
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > >>
>  > >  > > >
>  > >  > > > Child said (2, 15369): <<Assert error in wrk_thread(),
>  > >  cache_pool.c
>  > >  > > line
>  > >  > > > 217:
>  > >  > > >
>  > >  > > >   Condition((pipe(w->pipe)) == 0) not true.
>  > >  > > >
>  > >  > > >   errno = 24 (Too many open files)
>  > >  > > >
>  > >  > > > >>
>  > >  > > >
>  > >  > > > Cache child died pid=15369 status=0x6
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > uname -a:
>  > >  > > >
>  > >  > > > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55
>  > EST
>  > >  > > 2007
>  > >  > > > x86_64 x86_64 x86_64 GNU/Linux
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > command used to start varnish:
>  > >  > > >
>  > >  > > > /usr/sbin/varnishd -d -d -a :80 -f /etc/varnish/photo.vcl -T
>  > >  > > > <internalIP>:6082 -t 120 -w 10,700,30 -s
>  > >  > > > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g
>  > varnish -P
>  > >  > > > /var/run/varnish.pid
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I just
>  > need
>  > >  > to
>  > >  > > up
>  > >  > > > that value?
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > Thanks,
>  > >  > > >
>  > >  > > > Andy
>  > >  > > > _______________________________________________
>  > >  > > >  varnish-misc mailing list
>  > >  > > >  varnish-misc at projects.linpro.no
>  > >  > > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
>  > >  > > >
>  > >  > > >
>  > >  > _______________________________________________
>  > >  > varnish-misc mailing list
>  > >  > varnish-misc at projects.linpro.no
>  > >  > http://projects.linpro.no/mailman/listinfo/varnish-misc
>  > >  _______________________________________________
>  > >  varnish-misc mailing list
>  > >  varnish-misc at projects.linpro.no
>  > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
>  > >
>  > >
>
>


From mark at funnyordie.com  Fri Feb 29 05:52:24 2008
From: mark at funnyordie.com (Mark Smallcombe)
Date: Thu, 28 Feb 2008 21:52:24 -0800
Subject: Tuning varnish for high load
Message-ID: <658de5590802282152x6002e77fn93345953acbba4cb@mail.gmail.com>

We are running varnish (default config) in production and are tuning
it to handle high load.

We have 4 load balanced varnish servers (64 bit RedHat 5.1, 4G of RAM,
everything on a gigabit network). We find that under high load varnish
is unable to serve pages or the keepalive pages to our load balancer
(so it takes the servers offline).

Running the following load test on a 65K, uncompressed static page
from a single load testing server stops the 4 varnish servers from
serving static web pages:

httperf --verbose --hog --timeout=25 --server=www.ourdomain.com
--port=80 --uri /pagetotest.html --rate=1000 --send-buffer=2000
--recv-buffer=2000 --num-conns=500000 --num-calls=1

What tuning recommendations do you have for varnish to help it handle high load?

Mark


From fredrik.nygren at gotamedia.se  Fri Feb 29 09:23:21 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Fri, 29 Feb 2008 10:23:21 +0100
Subject: Blank pages with HTTP/1.0
Message-ID: <6C00C181-BCF6-4DE9-A525-658DD180CE39@gotamedia.se>

Hi,
I have a couple of servers with Varnish 1.1.2-5 installed. Some  
visitors has reported a blank page when they are visiting us. What I  
can se from our logs the problem seems to be related to the visitors  
HTTP protocol version. Requests with HTTP/1.0 gets a blank page but  
HTTP/1.1 not. Our Apache logs shows this:

[28/Feb/2008:10:32:14 +0100] "GET /index.jsp HTTP/1.1" 200 145883 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"
[28/Feb/2008:10:39:53 +0100] "GET /index.jsp HTTP/1.1" 200 145863 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"
[28/Feb/2008:10:44:18 +0100] "GET /index.jsp HTTP/1.1" 200 145886 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:44:32 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:44:43 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:44:44 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:44:45 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:44:47 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:10:45:04 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:11:21:09 +0100] "GET /index.jsp HTTP/1.1" 200 146633 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
[28/Feb/2008:12:31:46 +0100] "GET /index.jsp HTTP/1.1" 200 146205 "-"  
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"

Responses with 17491 bytes in return are blank page views.
 From our varnishlog I read the following:

134 SessionOpen  c 134.25.0.133 14373
   134 ReqStart     c 134.25.0.133 14373 2174456149
   134 RxRequest    c GET
   134 RxURL        c /
   134 RxProtocol   c HTTP/1.0
   134 RxHeader     c Accept: image/gif, image/x-xbitmap, image/jpeg,  
image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,  
application/vnd.ms-powerpoint, application/msword, */*
   134 RxHeader     c Accept-Language: sv
   134 RxHeader     c UA-CPU: x86
   134 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;  
Windows NT 5.1; .NET CLR 1.1.4322)
   134 RxHeader     c Host: www.smp.se
   134 RxHeader     c Cookie:  
__utma=147067189.81457932.1204189951.1204189951.1204189951.1;  
__utmb=147067189; __utmz=147067189.1204189951.1.1.utmccn=(direct)| 
utmcsr=(direct)|utmcmd=(none); InsightXE022004=216172787026292393
   134 RxHeader     c X-NovINet: v1.2
   134 RxHeader     c Via: 1.0 portos.sr.se:8080 (squid/2.6.STABLE18)
   134 RxHeader     c Cache-Control: max-age=259200
   134 VCL_call     c recv lookup
   134 VCL_call     c hash hash
   134 HitPass      c 2174455371
   134 VCL_call     c pass pass
   134 Backend      c 123 smp
   134 ObjProtocol  c HTTP/1.1
   134 ObjStatus    c 200
   134 ObjResponse  c OK
   134 ObjHeader    c Date: Thu, 28 Feb 2008 09:22:29 GMT
   134 ObjHeader    c Server: Apache-Coyote/1.1
   134 ObjHeader    c Content-Type: text/html;charset=ISO-8859-1
   134 ObjHeader    c Content-Language: sv-SE
   134 ObjHeader    c Set-Cookie:  
JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
   134 TTL          c 2174456149 RFC 120 1204190549 1204190549 0 0 0
   134 VCL_call     c fetch pass
   134 Length       c 0
   134 VCL_call     c deliver deliver
   134 TxProtocol   c HTTP/1.1
   134 TxStatus     c 200
   134 TxResponse   c OK
   134 TxHeader     c Server: Apache-Coyote/1.1
   134 TxHeader     c Content-Type: text/html;charset=ISO-8859-1
   134 TxHeader     c Content-Language: sv-SE
   134 TxHeader     c Set-Cookie:  
JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
   134 TxHeader     c Date: Thu, 28 Feb 2008 09:22:29 GMT
   134 TxHeader     c X-Varnish: 2174456149
   134 TxHeader     c Age: 0
   134 TxHeader     c Via: 1.1 varnish
   134 TxHeader     c Connection: close
   134 ReqEnd       c 2174456149 1204190549.767153978  
1204190549.773138046 0.000030041 0.005959034 0.000025034

I have searched the mailinglist and found this thread which seems to  
look like our problem but I'm not sure it's the same problem:
http://projects.linpro.no/pipermail/varnish-misc/2008-February/001349.html

Is there a known problem with the HTTP/1.0 protocol and Varnish?

Regards
<fredrik />



From andre at idium.no  Fri Feb 29 11:20:05 2008
From: andre at idium.no (=?ISO-8859-1?Q?Andr=E9_=D8ien_Langvand?=)
Date: Fri, 29 Feb 2008 12:20:05 +0100
Subject: VCL purge
In-Reply-To: <47BA9704.6060507@idium.no>
References: <47BA9704.6060507@idium.no>
Message-ID: <47C7EA65.3030602@idium.no>

Anyone?

What I want is when a client sends e.g Pragma: no-cache, I want warnish
to fetch from backend and insert, not only do a pass.

--
Andr? ?ien Langvand <andre at idium.no> - PGP: 0x7B1E3468
Systemadministrator - Idium AS - http://www.idium.no


Andr? ?ien Langvand wrote:
> Hi,
> 
> A few days ago, DES wrote the following in reply to another mail:
> 
>>> If the point of this is to allow the client to Shift-Reload, you
>>> should purge the URL to force a reload from the backend, instead of
>>> piping the request.
> 
> And the question is, how can I do this? I'm having problems figuring out
> what the purge_hash() needs to look like. I guess being allowed to use
> purge_hash(req.hash) would be the easiest, but that doesn't work. I've
> tried to use several combinations of req.url and req.http.host, but
> can't find a working one. purge_hash() is needed because of virtual hosts.
> 
> 


From anders.vannman at vk.se  Fri Feb 29 11:25:47 2008
From: anders.vannman at vk.se (Anders =?ISO-8859-1?Q?V=E4nnman?=)
Date: Fri, 29 Feb 2008 12:25:47 +0100
Subject: varnish-misc Digest, Vol 23, Issue 25
In-Reply-To: <mailman.3.1204282804.27034.varnish-misc@projects.linpro.no>
References: <mailman.3.1204282804.27034.varnish-misc@projects.linpro.no>
Message-ID: <fc.00802d3c015844a73b9aca00bd159033.15844b2@vk.se>

I guess its the same problem that ive had, and there is a patch regarding
it;

http://varnish.projects.linpro.no/ticket/197


>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 29 Feb 2008 10:23:21 +0100
>From: Fredrik Nygren <fredrik.nygren at gotamedia.se>
>Subject: Blank pages with HTTP/1.0
>To: varnish-misc at projects.linpro.no
>Cc: Stina Lange <stina.lange at teliasonera.com>, Fredrik Sj?dell
>	<fredrik.sjodell at gmail.com>,	Petri Luomala <p3 at bt.se>, Peter Granstr?m
>	<peter.granstrom at teliasonera.com>
>Message-ID: <6C00C181-BCF6-4DE9-A525-658DD180CE39 at gotamedia.se>
>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>Hi,
>I have a couple of servers with Varnish 1.1.2-5 installed. Some  
>visitors has reported a blank page when they are visiting us. What I  
>can se from our logs the problem seems to be related to the visitors  
>HTTP protocol version. Requests with HTTP/1.0 gets a blank page but  
>HTTP/1.1 not. Our Apache logs shows this:
>
>[28/Feb/2008:10:32:14 +0100] "GET /index.jsp HTTP/1.1" 200 145883 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"
>[28/Feb/2008:10:39:53 +0100] "GET /index.jsp HTTP/1.1" 200 145863 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"
>[28/Feb/2008:10:44:18 +0100] "GET /index.jsp HTTP/1.1" 200 145886 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:44:32 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:44:43 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:44:44 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:44:45 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:44:47 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:10:45:04 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:11:21:09 +0100] "GET /index.jsp HTTP/1.1" 200 146633 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>[28/Feb/2008:12:31:46 +0100] "GET /index.jsp HTTP/1.1" 200 146205 "-"  
>"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>
>Responses with 17491 bytes in return are blank page views.
> From our varnishlog I read the following:
>
>134 SessionOpen  c 134.25.0.133 14373
>   134 ReqStart     c 134.25.0.133 14373 2174456149
>   134 RxRequest    c GET
>   134 RxURL        c /
>   134 RxProtocol   c HTTP/1.0
>   134 RxHeader     c Accept: image/gif, image/x-xbitmap, image/jpeg,  
>image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,  
>application/vnd.ms-powerpoint, application/msword, */*
>   134 RxHeader     c Accept-Language: sv
>   134 RxHeader     c UA-CPU: x86
>   134 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;  
>Windows NT 5.1; .NET CLR 1.1.4322)
>   134 RxHeader     c Host: www.smp.se
>   134 RxHeader     c Cookie:  
>__utma=147067189.81457932.1204189951.1204189951.1204189951.1;  
>__utmb=147067189; __utmz=147067189.1204189951.1.1.utmccn=(direct)| 
>utmcsr=(direct)|utmcmd=(none); InsightXE022004=216172787026292393
>   134 RxHeader     c X-NovINet: v1.2
>   134 RxHeader     c Via: 1.0 portos.sr.se:8080 (squid/2.6.STABLE18)
>   134 RxHeader     c Cache-Control: max-age=259200
>   134 VCL_call     c recv lookup
>   134 VCL_call     c hash hash
>   134 HitPass      c 2174455371
>   134 VCL_call     c pass pass
>   134 Backend      c 123 smp
>   134 ObjProtocol  c HTTP/1.1
>   134 ObjStatus    c 200
>   134 ObjResponse  c OK
>   134 ObjHeader    c Date: Thu, 28 Feb 2008 09:22:29 GMT
>   134 ObjHeader    c Server: Apache-Coyote/1.1
>   134 ObjHeader    c Content-Type: text/html;charset=ISO-8859-1
>   134 ObjHeader    c Content-Language: sv-SE
>   134 ObjHeader    c Set-Cookie:  
>JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
>   134 TTL          c 2174456149 RFC 120 1204190549 1204190549 0 0 0
>   134 VCL_call     c fetch pass
>   134 Length       c 0
>   134 VCL_call     c deliver deliver
>   134 TxProtocol   c HTTP/1.1
>   134 TxStatus     c 200
>   134 TxResponse   c OK
>   134 TxHeader     c Server: Apache-Coyote/1.1
>   134 TxHeader     c Content-Type: text/html;charset=ISO-8859-1
>   134 TxHeader     c Content-Language: sv-SE
>   134 TxHeader     c Set-Cookie:  
>JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
>   134 TxHeader     c Date: Thu, 28 Feb 2008 09:22:29 GMT
>   134 TxHeader     c X-Varnish: 2174456149
>   134 TxHeader     c Age: 0
>   134 TxHeader     c Via: 1.1 varnish
>   134 TxHeader     c Connection: close
>   134 ReqEnd       c 2174456149 1204190549.767153978  
>1204190549.773138046 0.000030041 0.005959034 0.000025034
>
>I have searched the mailinglist and found this thread which seems to  
>look like our problem but I'm not sure it's the same problem:
>http://projects.linpro.no/pipermail/varnish-misc/2008-February/001349.html
>
>Is there a known problem with the HTTP/1.0 protocol and Varnish?
>
>Regards
><fredrik />
>
>
>
>------------------------------
>
>_______________________________________________
>varnish-misc mailing list
>varnish-misc at projects.linpro.no
>http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>
>End of varnish-misc Digest, Vol 23, Issue 25
>********************************************




From fredrik.nygren at gotamedia.se  Fri Feb 29 12:48:43 2008
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Fri, 29 Feb 2008 13:48:43 +0100
Subject: varnish-misc Digest, Vol 23, Issue 25
In-Reply-To: <fc.00802d3c015844a73b9aca00bd159033.15844b2@vk.se>
References: <mailman.3.1204282804.27034.varnish-misc@projects.linpro.no>
	<fc.00802d3c015844a73b9aca00bd159033.15844b2@vk.se>
Message-ID: <3A69629F-222C-40B2-837D-32D02ADDEDD1@gotamedia.se>

Alright. Wonder then if somebody has any rpm's to share for Redhat EL4  
i386 with the patch included?

Regards
<fredrik />

On 29 feb 2008, at 12.25, Anders V?nnman wrote:

I guess its the same problem that ive had, and there is a patch  
regarding
it;

http://varnish.projects.linpro.no/ticket/197


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 29 Feb 2008 10:23:21 +0100
> From: Fredrik Nygren <fredrik.nygren at gotamedia.se>
> Subject: Blank pages with HTTP/1.0
> To: varnish-misc at projects.linpro.no
> Cc: Stina Lange <stina.lange at teliasonera.com>, Fredrik Sj?dell
> 	<fredrik.sjodell at gmail.com>,	Petri Luomala <p3 at bt.se>, Peter  
> Granstr?m
> 	<peter.granstrom at teliasonera.com>
> Message-ID: <6C00C181-BCF6-4DE9-A525-658DD180CE39 at gotamedia.se>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Hi,
> I have a couple of servers with Varnish 1.1.2-5 installed. Some
> visitors has reported a blank page when they are visiting us. What I
> can se from our logs the problem seems to be related to the visitors
> HTTP protocol version. Requests with HTTP/1.0 gets a blank page but
> HTTP/1.1 not. Our Apache logs shows this:
>
> [28/Feb/2008:10:32:14 +0100] "GET /index.jsp HTTP/1.1" 200 145883 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR  
> 1.1.4322)"
> [28/Feb/2008:10:39:53 +0100] "GET /index.jsp HTTP/1.1" 200 145863 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR  
> 1.1.4322)"
> [28/Feb/2008:10:44:18 +0100] "GET /index.jsp HTTP/1.1" 200 145886 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:44:32 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:44:43 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:44:44 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:44:45 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:44:47 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:10:45:04 +0100] "GET /index.jsp HTTP/1.0" 200 17491 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:11:21:09 +0100] "GET /index.jsp HTTP/1.1" 200 146633 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
> [28/Feb/2008:12:31:46 +0100] "GET /index.jsp HTTP/1.1" 200 146205 "-"
> "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
>
> Responses with 17491 bytes in return are blank page views.
> From our varnishlog I read the following:
>
> 134 SessionOpen  c 134.25.0.133 14373
>  134 ReqStart     c 134.25.0.133 14373 2174456149
>  134 RxRequest    c GET
>  134 RxURL        c /
>  134 RxProtocol   c HTTP/1.0
>  134 RxHeader     c Accept: image/gif, image/x-xbitmap, image/jpeg,
> image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,
> application/vnd.ms-powerpoint, application/msword, */*
>  134 RxHeader     c Accept-Language: sv
>  134 RxHeader     c UA-CPU: x86
>  134 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;
> Windows NT 5.1; .NET CLR 1.1.4322)
>  134 RxHeader     c Host: www.smp.se
>  134 RxHeader     c Cookie:
> __utma=147067189.81457932.1204189951.1204189951.1204189951.1;
> __utmb=147067189; __utmz=147067189.1204189951.1.1.utmccn=(direct)|
> utmcsr=(direct)|utmcmd=(none); InsightXE022004=216172787026292393
>  134 RxHeader     c X-NovINet: v1.2
>  134 RxHeader     c Via: 1.0 portos.sr.se:8080 (squid/2.6.STABLE18)
>  134 RxHeader     c Cache-Control: max-age=259200
>  134 VCL_call     c recv lookup
>  134 VCL_call     c hash hash
>  134 HitPass      c 2174455371
>  134 VCL_call     c pass pass
>  134 Backend      c 123 smp
>  134 ObjProtocol  c HTTP/1.1
>  134 ObjStatus    c 200
>  134 ObjResponse  c OK
>  134 ObjHeader    c Date: Thu, 28 Feb 2008 09:22:29 GMT
>  134 ObjHeader    c Server: Apache-Coyote/1.1
>  134 ObjHeader    c Content-Type: text/html;charset=ISO-8859-1
>  134 ObjHeader    c Content-Language: sv-SE
>  134 ObjHeader    c Set-Cookie:
> JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
>  134 TTL          c 2174456149 RFC 120 1204190549 1204190549 0 0 0
>  134 VCL_call     c fetch pass
>  134 Length       c 0
>  134 VCL_call     c deliver deliver
>  134 TxProtocol   c HTTP/1.1
>  134 TxStatus     c 200
>  134 TxResponse   c OK
>  134 TxHeader     c Server: Apache-Coyote/1.1
>  134 TxHeader     c Content-Type: text/html;charset=ISO-8859-1
>  134 TxHeader     c Content-Language: sv-SE
>  134 TxHeader     c Set-Cookie:
> JSESSIONID=4CF19E800052C32EC682743E8D6B8920.sehan9078gota8009; Path=/
>  134 TxHeader     c Date: Thu, 28 Feb 2008 09:22:29 GMT
>  134 TxHeader     c X-Varnish: 2174456149
>  134 TxHeader     c Age: 0
>  134 TxHeader     c Via: 1.1 varnish
>  134 TxHeader     c Connection: close
>  134 ReqEnd       c 2174456149 1204190549.767153978
> 1204190549.773138046 0.000030041 0.005959034 0.000025034
>
> I have searched the mailinglist and found this thread which seems to
> look like our problem but I'm not sure it's the same problem:
> http://projects.linpro.no/pipermail/varnish-misc/2008-February/001349.html
>
> Is there a known problem with the HTTP/1.0 protocol and Varnish?
>
> Regards
> <fredrik />
>
>
>
> ------------------------------
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>
> End of varnish-misc Digest, Vol 23, Issue 25
> ********************************************


_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc



From ingvar at linpro.no  Fri Feb 29 13:03:38 2008
From: ingvar at linpro.no (Ingvar Hagelund)
Date: Fri, 29 Feb 2008 14:03:38 +0100
Subject: varnish-misc Digest, Vol 23, Issue 25
In-Reply-To: <3A69629F-222C-40B2-837D-32D02ADDEDD1@gotamedia.se>
References: <mailman.3.1204282804.27034.varnish-misc@projects.linpro.no>	<fc.00802d3c015844a73b9aca00bd159033.15844b2@vk.se>
	<3A69629F-222C-40B2-837D-32D02ADDEDD1@gotamedia.se>
Message-ID: <47C802AA.4080008@linpro.no>

* Fredrik Nygren
> Alright. Wonder then if somebody has any rpm's to share for Redhat EL4  
> i386 with the patch included?

Post a request with a short recap of the discussion to the varnish-dist 
list, and I'll consider it.

Ingvar

-- 
Buddha wears an iPod


From michael at dynamine.net  Fri Feb 29 20:23:34 2008
From: michael at dynamine.net (Michael S. Fischer)
Date: Fri, 29 Feb 2008 12:23:34 -0800
Subject: Tuning varnish for high load
In-Reply-To: <658de5590802282152x6002e77fn93345953acbba4cb@mail.gmail.com>
References: <658de5590802282152x6002e77fn93345953acbba4cb@mail.gmail.com>
Message-ID: <86db848d0802291223n2400e8c5ya4ef0e648f4d124b@mail.gmail.com>

On Thu, Feb 28, 2008 at 9:52 PM, Mark Smallcombe <mark at funnyordie.com> wrote:

>  What tuning recommendations do you have for varnish to help it handle high load?

Funny you should ask, I've been spending a lot of time with Varnish in
the lab.  Here are a few observations I've made:

(N.B.  We're using 4-CPU Xeon hardware running RHEL 4.5, which runs
the 2.6.9 Linux kernel.  All machines have at least 4GB RAM and run
the 64-bit Varnish build, but our results are equally applicable to
32-bit builds)

- When the cache hit ratio is very high (i.e. 100%), we discovered
that Varnish's default configuration of thread_pool_max is too high.
When there are too many worker threads, Varnish spends an inordinate
amount of time in system call space.  We're not sure whether this is
due to some flaw in Varnish, our ancient Linux kernel (we were unable
to test with a modern 2.6.22 or later kernel that apparently has a
better scheduler), or is just a fundamental problem when a threaded
daemon like Varnish tries to service thousands of concurrent
connections.  After much tweaking we determined that, on our hardware,
the optimal ratio of threads per CPU is about 16, or around 48-50
threads on a 4-CPU box.  To eliminate dropping work requests, it is
also advisable to raise overflow_max to a significantly higher ratio
than the default (e.g. 10000%).  This will cause Varnish to consume
somewhat more RAM, but will provide outstanding performance.  With
these tweaks, we were able to get Varnish to serve 10,000 concurrent
connections, flooding a Gigabit Ethernet channel with 5 KB cached
objects.

- Conversely, when the cache hit ratio is 0, the default of 100
threads is too low. (To create this scenario, we used 2 Varnish boxes:
 the front-end proxy was configured to "pass" all requests to an
optimized backend Varnish instance that served all requests from
cache.)  On the same 4-CPU hardware, we found that the optimal
thread_pool_max value in this situation is about 750.  Again, we were
able to serve 10,0000 concurrent connections after optimizing the
settings.

I find this interesting, because one would think that Varnish would be
making the system spend much more time in the scheduler in the second
scenario because it is doing significantly less work (no lookups, just
handing off connections to the appropriate backend).  I suspect that
there may be some thread-scalability issues with the cache lookup
process.   If someone with a suitably powerful lab setup (i.e. Gigabit
Ethernet, big hardware) can test with a more modern Linux kernel, I'd
be very interested in the results.  Feel free to contact me if you
need assistance with setup/analysis.

Finally: Varnish performance is absolutely atrocious on a 8-CPU RHEL
4.5 system -- so bad that I have to turn down thread_pool_max to 4 or
restrict it to run only on 4 CPUs via taskset(1).  I've heard that
MySQL has similar problems, so I suspect that this is a Linux kernel
issue.

Best regards,

--Michael


From andrew at imeem.com  Fri Feb 29 20:54:15 2008
From: andrew at imeem.com (Andrew Knapp)
Date: Fri, 29 Feb 2008 12:54:15 -0800
Subject: Child dying with "Too many open files"
In-Reply-To: <86db848d0802281551j3dfa0221v5e9867bd340b40e3@mail.gmail.com>
References: <0A3A6EA86530E64EA3BEA603EC4401CA01FC33B0@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802201747w68f34006hf95d27f682e46892@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA01FC3463@dexbe014-8.exch014.msoutlookonline.net>
	<0A3A6EA86530E64EA3BEA603EC4401CA020732BA@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802281356l7cf41a5g9dc24327bb065ba8@mail.gmail.com>
	<0A3A6EA86530E64EA3BEA603EC4401CA020EA84C@dexbe014-8.exch014.msoutlookonline.net>
	<86db848d0802281551j3dfa0221v5e9867bd340b40e3@mail.gmail.com>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CA020EAAE3@dexbe014-8.exch014.msoutlookonline.net>

I'm still getting the "Too many open files" error on the child.

$ sudo sysctl -a | grep file
fs.file-max = 131072

NFILES is also set to 131072. Any ideas?

-Andy

> -----Original Message-----
> From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On Behalf
> Of Michael S. Fischer
> Sent: Thursday, February 28, 2008 3:51 PM
> To: Andrew Knapp
> Cc: varnish-misc at projects.linpro.no
> Subject: Re: Child dying with "Too many open files"
> 
> I can't help but wonder if you'd set it too high.  What happens when
> you set NFILES and fs.file-max both to 131072?  I've tested that as a
> known good value.
> 
> --Michael
> 
> On Thu, Feb 28, 2008 at 2:58 PM, Andrew Knapp <andrew at imeem.com>
wrote:
> > Yup, it is. Here's some output:
> >
> >  $ ps auxwww | grep varnish
> >  root     12036  0.0  0.0  27704   648 ?        Ss   14:54   0:00
> >  /usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T
> <internalip>:6082
> >
> > -t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
> >  varnish -g varnish -P /var/run/varnish.pid
> >  varnish  12037  1.2  0.4 13119108 39936 ?      Sl   14:54   0:00
> >  /usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T
> <internalip>:6082
> >
> > -t 120 -w 10,700,30 -s file,/c01/varnish/varnish_storage.bin,12G -u
> >  varnish -g varnish -P /var/run/varnish.pid
> >
> >  -Andy
> >
> >
> >  > -----Original Message-----
> >  > From: michaelonlaw at gmail.com [mailto:michaelonlaw at gmail.com] On
> Behalf
> >  > Of Michael S. Fischer
> >
> >
> > > Sent: Thursday, February 28, 2008 1:57 PM
> >  > To: Andrew Knapp
> >  > Cc: varnish-misc at projects.linpro.no
> >  > Subject: Re: Child dying with "Too many open files"
> >  >
> >  > Is varnishd being started as root?  (even if it drops privileges
> >  > later) Only root can have > 1024 file descriptors open, to my
> >  > knowledge.
> >  >
> >  > --Michael
> >  >
> >  > On Thu, Feb 28, 2008 at 11:48 AM, Andrew Knapp <andrew at imeem.com>
> >  > wrote:
> >  > > Didn't really get a answer to this, so I'm trying again.
> >  > >
> >  > >  I've done some testing with the NFILES variable, and I keep
> getting
> >  > the
> >  > >  same error as before ("Too many open files"). I've also
> verified
> >  > that
> >  > >  the limit is actually being applied by putting a ulimit -a in
> the
> >  > >  /etc/init.d/varnish script.
> >  > >
> >  > >  Anyone have any ideas? I'm running the 1.1.2-5 rpms from
sf.net
> on
> >  > >  Centos 5.1.
> >  > >
> >  > >  Thanks,
> >  > >  Andy
> >  > >
> >  > >
> >  > >  > -----Original Message-----
> >  > >  > From: varnish-misc-bounces at projects.linpro.no
> [mailto:varnish-
> >  > misc-
> >  > >  > bounces at projects.linpro.no] On Behalf Of Andrew Knapp
> >  > >
> >  > > > Sent: Wednesday, February 20, 2008 5:52 PM
> >  > >  > To: Michael S. Fischer
> >  > >  > Cc: varnish-misc at projects.linpro.no
> >  > >
> >  > >
> >  > > > Subject: RE: Child dying with "Too many open files"
> >  > >  >
> >  > >  > Here's the output:
> >  > >  >
> >  > >  > $ sysctl fs.file-max
> >  > >  > fs.file-max = 767606
> >  > >  >
> >  > >  > > -----Original Message-----
> >  > >  > > From: michaelonlaw at gmail.com
> [mailto:michaelonlaw at gmail.com] On
> >  > >  > Behalf
> >  > >  > > Of Michael S. Fischer
> >  > >  > > Sent: Wednesday, February 20, 2008 5:48 PM
> >  > >  > > To: Andrew Knapp
> >  > >  > > Cc: varnish-misc at projects.linpro.no
> >  > >  > > Subject: Re: Child dying with "Too many open files"
> >  > >  > >
> >  > >  > > Does 'sysctl fs.file-max' say?  It should be >= the
ulimit.
> >  > >  > >
> >  > >  > > --Michael
> >  > >  > >
> >  > >  > > On Wed, Feb 20, 2008 at 4:04 PM, Andrew Knapp
> >  <andrew at imeem.com>
> >  > >  > wrote:
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > Hello,
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > I'm getting this error when running varnishd:
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > >>
> >  > >  > > >
> >  > >  > > > Child said (2, 15369): <<Assert error in wrk_thread(),
> >  > >  cache_pool.c
> >  > >  > > line
> >  > >  > > > 217:
> >  > >  > > >
> >  > >  > > >   Condition((pipe(w->pipe)) == 0) not true.
> >  > >  > > >
> >  > >  > > >   errno = 24 (Too many open files)
> >  > >  > > >
> >  > >  > > > >>
> >  > >  > > >
> >  > >  > > > Cache child died pid=15369 status=0x6
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > uname -a:
> >  > >  > > >
> >  > >  > > > Linux <hostname> 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30
> 00:45:55
> >  > EST
> >  > >  > > 2007
> >  > >  > > > x86_64 x86_64 x86_64 GNU/Linux
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > command used to start varnish:
> >  > >  > > >
> >  > >  > > > /usr/sbin/varnishd -d -d -a :80 -f
/etc/varnish/photo.vcl
> -T
> >  > >  > > > <internalIP>:6082 -t 120 -w 10,700,30 -s
> >  > >  > > > file,/c01/varnish/varnish_storage.bin,12G -u varnish -g
> >  > varnish -P
> >  > >  > > > /var/run/varnish.pid
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > I have NFILES=270000 set in /etc/sysconfig/varnish. Do I
> just
> >  > need
> >  > >  > to
> >  > >  > > up
> >  > >  > > > that value?
> >  > >  > > >
> >  > >  > > >
> >  > >  > > >
> >  > >  > > > Thanks,
> >  > >  > > >
> >  > >  > > > Andy
> >  > >  > > > _______________________________________________
> >  > >  > > >  varnish-misc mailing list
> >  > >  > > >  varnish-misc at projects.linpro.no
> >  > >  > > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> >  > >  > > >
> >  > >  > > >
> >  > >  > _______________________________________________
> >  > >  > varnish-misc mailing list
> >  > >  > varnish-misc at projects.linpro.no
> >  > >  > http://projects.linpro.no/mailman/listinfo/varnish-misc
> >  > >  _______________________________________________
> >  > >  varnish-misc mailing list
> >  > >  varnish-misc at projects.linpro.no
> >  > >  http://projects.linpro.no/mailman/listinfo/varnish-misc
> >  > >
> >  > >
> >
> >


From f.nygren at gmail.com  Wed Feb 13 17:48:02 2008
From: f.nygren at gmail.com (Fredrik Nygren)
Date: Wed, 13 Feb 2008 17:48:02 -0000
Subject: Using varnish
In-Reply-To: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
References: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
Message-ID: <24473B83-F31A-4B93-85C6-57E722297346@gmail.com>

I'm a member of the development team at Gota Media which runs four  
swedish newspapers (Barometern.se, BLT.se, BT.se and SMP.se). Right  
now we are evaluating Varnish and it looks good. I also know that  
SvD.se runs Varnish.

Regards
Fredrik Nygren
Gota Media


On 13 feb 2008, at 17.36, Anders V?nnman wrote:

Hi,

We are in the process of evaluating Varnish as an alternative for Squid
for our sites. We have got an internal varnish up and running and it  
seems
just great. Of course I have many questions, is there anyone on a  
swedish
newspaper using varnish?

// Anders V?nnman


_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc



From f.nygren at gmail.com  Wed Feb 13 18:46:29 2008
From: f.nygren at gmail.com (Fredrik Nygren)
Date: Wed, 13 Feb 2008 18:46:29 -0000
Subject: Using varnish
In-Reply-To: <47B32FD1.503@torlen.net>
References: <fc.00802d3c015573fd00802d3c015573fd.1557400@vk.se>
	<47B32FD1.503@torlen.net>
Message-ID: <46FA8979-96C4-40ED-97A7-19D515C2BAF5@gmail.com>

I'm a member of the development team at Gota Media which runs four  
swedish newspapers (Barometern.se, BLT.se, BT.se and SMP.se). Right  
now we are evaluating Varnish and it looks good.

Regards
Fredrik Nygren
Gota Media

On 13 feb 2008, at 18.58, Erik Torlen wrote:

Do you just want to know a swedish newspaper that's using varnish?

If so, Aftonbladet and SvD is both using varnish.

/ Erik

Anders V?nnman skrev:
> Hi,
>
> We are in the process of evaluating Varnish as an alternative for  
> Squid
> for our sites. We have got an internal varnish up and running and it  
> seems
> just great. Of course I have many questions, is there anyone on a  
> swedish
> newspaper using varnish?
>
> // Anders V?nnman
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>

_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc