From varnish-bugs at varnish-cache.org  Tue Feb  1 13:30:22 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 01 Feb 2011 13:30:22 -0000
Subject: [Varnish] #854: patch: extra features for the varnish initrc script
Message-ID: <046.bcb4bdb8297b12f012b4621c408f2685@varnish-cache.org>

#854: patch: extra features for the varnish initrc script
----------------------------------------+-----------------------------------
 Reporter:  jhalfmoon                   |        Type:  enhancement
   Status:  new                         |    Priority:  low        
Milestone:                              |   Component:  build      
  Version:  trunk                       |    Severity:  trivial    
 Keywords:  initrc patch extra feature  |  
----------------------------------------+-----------------------------------
 Hi,

 The following patch adds a few feautures to the varnish
 /etc/init.d/varnish script:

 - status  shows current daemon status and loaded vcls
 - purge   cleans out all vcls except the active vcls
 - reload  allows you to safely load a new vcl config into varnish.
 - prev    activates the previous config, if present
 - next    activates the next config, if present

 These last two feauture allow for a quick rollback of the config, in case
 an error is detected in a config.

 Also, the initrc allows for multiple varnish instances by creating
 symlinks to the initrc script. That way you do not have to create multiple
 initrc scripts. If for example the following links exist:

 /etc/init.d/varnish-acceptance -> /etc/init.d/varnish
 /etc/init.d/varnish-test -> /etc/init.d/varnish

 The the 'varnish-acceptance' instance would get its config files from the
 following location:

 /etc/varnish-acceptance
 /etc/sysconfig/varnish-acceptance

 and the 'varnish-test' instance would get its files from:

 /etc/varnish-test
 /etc/sysconfig/varnish-test

 You can disable the 'multi-instance' feature by changing the
 'instancename' variable in the initrc script from instancename=`basename
 $0` to 'instancename=varnish' . I also added an example sysconfig file, to
 show how to use the multi-instance feature.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/854>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb  2 12:48:56 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 02 Feb 2011 12:48:56 -0000
Subject: [Varnish] #855: trac internal error when browsing by revision
Message-ID: <042.66de011872fdea2250b4e2792e2771f4@varnish-cache.org>

#855: trac internal error when browsing by revision
---------------------+------------------------------------------------------
 Reporter:  slink    |       Owner:  thfeen
     Type:  defect   |      Status:  new   
 Priority:  normal   |   Milestone:        
Component:  website  |     Version:  trunk 
 Severity:  normal   |    Keywords:        
---------------------+------------------------------------------------------
 http://www.varnish-
 cache.org/trac/log/bin/varnishd?rev=6af4255312dc5fa13fa62cdaef27c67af78e2b4c

 gives:

 {{{
  Trac detected an internal error:

 TypeError: expecting datetime, int, long, float, or None; got <class
 'genshi.template.eval.Undefined'>
 ]]]

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/855>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb  2 12:50:43 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 02 Feb 2011 12:50:43 -0000
Subject: [Varnish] #855: trac internal error when browsing by revision
In-Reply-To: <042.66de011872fdea2250b4e2792e2771f4@varnish-cache.org>
References: <042.66de011872fdea2250b4e2792e2771f4@varnish-cache.org>
Message-ID: <051.3e33ad597fb39e9f7cbea249ab0fd772@varnish-cache.org>

#855: trac internal error when browsing by revision
---------------------+------------------------------------------------------
 Reporter:  slink    |       Owner:  thfeen
     Type:  defect   |      Status:  new   
 Priority:  lowest   |   Milestone:        
Component:  website  |     Version:  trunk 
 Severity:  trivial  |    Keywords:        
---------------------+------------------------------------------------------
Changes (by slink):

  * priority:  normal => lowest
  * severity:  normal => trivial


Comment:

 seems to apply to directories only

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/855#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb  2 13:17:31 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 02 Feb 2011 13:17:31 -0000
Subject: [Varnish] #856: nm -an hack does not work on solaris
Message-ID: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org>

#856: nm -an hack does not work on solaris
----------------------+-----------------------------------------------------
 Reporter:  slink     |       Owner:  slink
     Type:  defect    |      Status:  new  
 Priority:  lowest    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  trivial   |    Keywords:       
----------------------+-----------------------------------------------------
 code introduced with [677faa4ed03326eb9432e0f9c3522d3052f292dc] extracts
 symbols output by nm.

 The default, /usr/bin/nm, does not understand the -an option.

 Alternatives

  * use gnm, if present
  * use /usr/bin/nm with different options

 the options which seem to generate output closest to (GNU) nm -an are:

 {{{
 nm -h -v -p -t x
 }}}

 giving:

 {{{
 0x00000000 f .libs/varnishd
 0x00000000 s
 0x00000000 s
 0x00000000 s
 ...
 0x08050000 d _START_
 0x08050114 s
 0x08050128 s
 0x08050138 s
 ...
 0x0805b244 D _PROCEDURE_LINKAGE_TABLE_
 0x0805b244 s
 0x0805b254 U atexit
 0x0805b264 U __fpstart
 0x0805b274 U exit
 0x0805b284 U _exit
 ...
 0x0806cf64 T VEP_Init
 0x0806d0e0 T VEP_Finish
 0x0806d274 t ved_sendchunk
 0x0806d384 t ved_decode_len
 ...
 0x080be640 B heritage
 0x080bea60 B mgt_vcl_dir
 0x080bea64 B vsm_end
 0x080bea68 B _end
 0x080bea68 b _END_
 }}}

 Please note:

  * the address in hex format is prefixed with 0x
  * identifiers in the second column are similar, but not identical to GNU
 nm:

  A       Absolute symbol.
  B       bss (uninitialized data space) symbol.
  C       COMMON symbol.
  D       Data object symbol.
  F       File symbol.
  N       Symbol has no type.
  L       Thread-Local storage symbol.
  S       Section symbol.
  T       Text symbol.
  U       Undefined.

  If the symbol's binding attribute is:

  LOCAL     The key letter is lower case.

  WEAK      The key letter is upper case. If the -l modifier
            is  specified, the upper case key letter is fol-
            lowed by a *

  GLOBAL    The key letter is upper case.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/856>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb  2 13:17:42 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 02 Feb 2011 13:17:42 -0000
Subject: [Varnish] #856: nm -an hack does not work on solaris
In-Reply-To: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org>
References: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org>
Message-ID: <051.4ad616a0bce3660443527a8bd557a639@varnish-cache.org>

#856: nm -an hack does not work on solaris
----------------------+-----------------------------------------------------
 Reporter:  slink     |       Owner:  slink  
     Type:  defect    |      Status:  new    
 Priority:  lowest    |   Milestone:         
Component:  varnishd  |     Version:  trunk  
 Severity:  trivial   |    Keywords:  Solaris
----------------------+-----------------------------------------------------
Changes (by slink):

  * keywords:  => Solaris


-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/856#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb  2 19:05:24 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 02 Feb 2011 19:05:24 -0000
Subject: [Varnish] #857: ESI includes don't account for manually timed out
	files
Message-ID: <047.329f52309ba6d7dd0a8c55eb8b3e357f@varnish-cache.org>

#857: ESI includes don't account for manually timed out files
------------------------+---------------------------------------------------
 Reporter:  dhelkowski  |        Type:  defect
   Status:  new         |    Priority:  normal
Milestone:              |   Component:  build 
  Version:  2.1.4       |    Severity:  normal
 Keywords:              |  
------------------------+---------------------------------------------------
 I have ESI setup in varnish. I have a file 'a.ehtml' that includes
 'b.html' via an ESI include. I have my hit function setup to do 'set
 obj.ttl=0s' when a 'no-cache' request is sent in.

 If I make a request to b.html to reset it via 'no-cache', 'a.ehtml' still
 continues to be cached for the original ttl of 'b.html' before I set it to
 0.

 The relevant portion of vcl_hit:
 if( req.http.Cache-Control == "no-cache" ) {
     if (! (req.http.User-Agent ~ "bot|MSIE") ) {
       set obj.ttl = 0s;
       return(restart);
     }
   }

 The revelant portion of vcl_fetch:
 if( req.url ~ "\.ehtml$" || beresp.http.Content-Type == "text/ehtml" ) {
     set beresp.http.Content-Type = "text/html";
     esi;
   }

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/857>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Feb  3 13:54:30 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 03 Feb 2011 13:54:30 -0000
Subject: [Varnish] #857: ESI includes don't account for manually timed
	out files
In-Reply-To: <047.329f52309ba6d7dd0a8c55eb8b3e357f@varnish-cache.org>
References: <047.329f52309ba6d7dd0a8c55eb8b3e357f@varnish-cache.org>
Message-ID: <056.c6eb0cfb3ce3e21623dd0d43c984731f@varnish-cache.org>

#857: ESI includes don't account for manually timed out files
------------------------+---------------------------------------------------
 Reporter:  dhelkowski  |        Type:  defect
   Status:  new         |    Priority:  normal
Milestone:              |   Component:  build 
  Version:  2.1.4       |    Severity:  normal
 Keywords:              |  
------------------------+---------------------------------------------------

Comment(by dhelkowski):

 Note that there is a double vertical bar in the last if statement
 connecting the two conditions, but it got stripped out due to my not using
 a code block; eg, it should be:

 {{{
 if( req.url ~ "\.ehtml$" || beresp.http.Content-Type == "text/ehtml" ) {
   set beresp.http.Content-Type = "text/html";
   esi;
 }
 }}}

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/857#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 13:07:42 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 13:07:42 -0000
Subject: [Varnish] #811: No recent binary packages for 32-bit RHEL/CentOS
In-Reply-To: <050.1325b4e88b8e050530222133dcf1869c@varnish-cache.org>
References: <050.1325b4e88b8e050530222133dcf1869c@varnish-cache.org>
Message-ID: <059.0681a8950ad194750cb02c38ba5c89d8@varnish-cache.org>

#811: No recent binary packages for 32-bit RHEL/CentOS
---------------------------+------------------------------------------------
 Reporter:  chadwackerman  |        Owner:  tfheen
     Type:  enhancement    |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  build          |      Version:  2.1.4 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Yaaai, fixed stuff.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/811#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 13:14:12 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 13:14:12 -0000
Subject: [Varnish] #856: nm -an hack does not work on solaris
In-Reply-To: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org>
References: <042.080a76f34695697aba6aad61deeb2708@varnish-cache.org>
Message-ID: <051.db719e9d727cc1e964bc81273e9e960f@varnish-cache.org>

#856: nm -an hack does not work on solaris
----------------------+-----------------------------------------------------
 Reporter:  slink     |       Owner:  slink  
     Type:  defect    |      Status:  new    
 Priority:  lowest    |   Milestone:         
Component:  varnishd  |     Version:  trunk  
 Severity:  trivial   |    Keywords:  Solaris
----------------------+-----------------------------------------------------

Comment(by phk):

 Try to see if you can make dlsym() work better for you.

 The reason for the hack is that I got nearly no useful symbols with
 dlsym() when I tested it, so I added the "nm -a" hack and moved on...

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/856#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 13:18:07 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 13:18:07 -0000
Subject: [Varnish] #853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test
	in configure.ac
In-Reply-To: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org>
References: <042.9773b80b7c13e9c38342f4031a121616@varnish-cache.org>
Message-ID: <051.481508b57498d10deddcdc9c138b97b9@varnish-cache.org>

#853: Improvement of SO_RCVTIMEO / SO_SNDTIMEO test in configure.ac
-------------------------+--------------------------------------------------
 Reporter:  jdzst        |       Owner:  tfheen
     Type:  enhancement  |      Status:  new   
 Priority:  low          |   Milestone:        
Component:  build        |     Version:  trunk 
 Severity:  minor        |    Keywords:        
-------------------------+--------------------------------------------------
Changes (by tfheen):

  * owner:  => tfheen


-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/853#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 13:20:45 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 13:20:45 -0000
Subject: [Varnish] #851: bad file descriptor
In-Reply-To: <043.c18a6c81c330acd0839d3e63154e1559@varnish-cache.org>
References: <043.c18a6c81c330acd0839d3e63154e1559@varnish-cache.org>
Message-ID: <052.4d2d083b793c7b4adb17295537c1d828@varnish-cache.org>

#851: bad file descriptor
----------------------+-----------------------------------------------------
 Reporter:  tfheen    |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
Changes (by phk):

  * owner:  => phk


Comment:

 Looks like VSM got corrupted, probably by child not starting completely or
 getting killed while fudging VSM.

 We should probably do a sanity-check on VSM in mgt before starting child.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/851#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 13:27:02 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 13:27:02 -0000
Subject: [Varnish] #784: Varnish crash at HSH_Lookup()
In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org>
References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org>
Message-ID: <054.abf4b1cb7b3bead02b211a25c41169c5@varnish-cache.org>

#784: Varnish crash at HSH_Lookup()
----------------------+-----------------------------------------------------
 Reporter:  censored  |       Owner:  perbu                   
     Type:  defect    |      Status:  new                     
 Priority:  normal    |   Milestone:                          
Component:  varnishd  |     Version:  2.1.3                   
 Severity:  normal    |    Keywords:  varnishd HSH_Lookup died
----------------------+-----------------------------------------------------
Changes (by phk):

  * owner:  phk => perbu


Old description:

> On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup().
>
> {{{
> -a :55555
> -T localhost:4092
> -f /etc/varnish/default.vcl
> -s malloc,880G
> -p thread_pools=4
> -p thread_pool_min=200
> -p thread_pool_max=2400
> -p thread_pool_add_delay=2
> -p lru_interval=20"
>
> --default.vcl--
>  backend default {
>      .host = "6.6.6.6";
>      .port = "80";
>  }
>
>  sub vcl_recv {
>      unset req.http.cookie;
>
>      if (req.request == "HEAD") {
>          return(pass);
>      }
>  }
> --EOF--
>
> syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not
> responding to ping, killing it.
> syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died
> signal=6
> syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316)
> Panic message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012
>   Condition((o)->magic == 0x32851d42) not true.#012
> thread = (cache-worker)#012
> ident = Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012
> Backtrace:#012
>
> 0x424608: /usr/sbin/varnishd [0x424608]#012
>   0x41e2df: /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012
>   0x412c9b: /usr/sbin/varnishd [0x412c9b]#012
>   0x4151ad: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012
>   0x426a48: /usr/sbin/varnishd [0x426a48]#012
>   0x425d23: /usr/sbin/varnishd [0x425d23]#012
>   0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012
>   0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012
> sp = 0x7fdede746008 {#012
>   fd = 198, id = 198, xid = 159666020,#012
>   client = 1.1.1.1:25723,#012  step = STP_LOOKUP,#012
>   handling = hash,#012
>   restarts = 0, esis = 0#012
>   ws = 0x7fdede746078 { #012
>     id = "sess",#012
>     {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012  },#012
>   http[req] = {#012
>     ws = 0x7fdede746078[sess]#012
>       "GET",#012
>       "/static/file.png",#012
>       "HTTP/1.1",#012
>       "Accept-Encoding: gzip",#012
>       "User-Agent: Jakarta Commons-HttpClient/3.1",#012
>       "Host: foo.bar.com",#012
>       "X-Forwarded-For: 4.4.4.4, 1.1.1.1",#012
>   },#012
>   worker = 0x7fccc53a3e70 {#012
>     ws = 0x7fccc53a3fe0 { #012
>       id = "wrk",#012
>       {s,f,r,e} = {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012
>     },#012
>     },#012
>     vcl = {#012
>       srcname = {#012
>         "input",#012
>         "Default",#012
>       },#012
>     },#012
> },#012
>
> syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete
> syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started
> }}}

New description:

 On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup().

 {{{
 -a :55555
 -T localhost:4092
 -f /etc/varnish/default.vcl
 -s malloc,880G
 -p thread_pools=4
 -p thread_pool_min=200
 -p thread_pool_max=2400
 -p thread_pool_add_delay=2
 -p lru_interval=20"

 --default.vcl--
  backend default {
      .host = "6.6.6.6";
      .port = "80";
  }

  sub vcl_recv {
      unset req.http.cookie;

      if (req.request == "HEAD") {
          return(pass);
      }
  }
 --EOF--

 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not
 responding to ping, killing it.
 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died
 signal=6
 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316)
 Panic message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012
   Condition((o)->magic == 0x32851d42) not true.#012
 thread = (cache-worker)#012
 ident = Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012
 Backtrace:#012

 0x424608: /usr/sbin/varnishd [0x424608]#012
   0x41e2df: /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012
   0x412c9b: /usr/sbin/varnishd [0x412c9b]#012
   0x4151ad: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012
   0x426a48: /usr/sbin/varnishd [0x426a48]#012
   0x425d23: /usr/sbin/varnishd [0x425d23]#012
   0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012
   0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012
 sp = 0x7fdede746008 {#012
   fd = 198, id = 198, xid = 159666020,#012
   client = 1.1.1.1:25723,#012  step = STP_LOOKUP,#012
   handling = hash,#012
   restarts = 0, esis = 0#012
   ws = 0x7fdede746078 { #012
     id = "sess",#012
     {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012  },#012
   http[req] = {#012
     ws = 0x7fdede746078[sess]#012
       "GET",#012
       "/static/file.png",#012
       "HTTP/1.1",#012
       "Accept-Encoding: gzip",#012
       "User-Agent: Jakarta Commons-HttpClient/3.1",#012
       "Host: foo.bar.com",#012
       "X-Forwarded-For: 4.4.4.4, 1.1.1.1",#012
   },#012
   worker = 0x7fccc53a3e70 {#012
     ws = 0x7fccc53a3fe0 { #012
       id = "wrk",#012
       {s,f,r,e} = {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012
     },#012
     },#012
     vcl = {#012
       srcname = {#012
         "input",#012
         "Default",#012
       },#012
     },#012
 },#012

 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete
 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started
 }}}

--

Comment:

 This seems like useful doc material for an obscure config-issue, should go
 in sphinx-docs somewhere.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/784#comment:7>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 14:31:35 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 14:31:35 -0000
Subject: [Varnish] #857: ESI includes don't account for manually timed
	out files
In-Reply-To: <047.329f52309ba6d7dd0a8c55eb8b3e357f@varnish-cache.org>
References: <047.329f52309ba6d7dd0a8c55eb8b3e357f@varnish-cache.org>
Message-ID: <056.388cf47e2b520fc64adc06b893044a55@varnish-cache.org>

#857: ESI includes don't account for manually timed out files
-------------------------+--------------------------------------------------
  Reporter:  dhelkowski  |        Type:  defect
    Status:  closed      |    Priority:  normal
 Milestone:              |   Component:  build 
   Version:  2.1.4       |    Severity:  normal
Resolution:  invalid     |    Keywords:        
-------------------------+--------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 I'm having a bit of a hard time trying to understand the issue.

 Yo've got two pages, a.ehtml and b.html, the VCL you provide sets content-
 type manually, then starts esi-parsing for *.ehtml. At which point b.html
 is included. But then it sounds like you're saying a.html isn't refreshed,
 but....

 All in all, this seems more like a configuration/VCL/esi-issue than an
 actual bug.

 I recommend sending a mail to varnish-misc (see http://www.varnish-
 cache.org/lists/mailman/listinfo/varnish-misc/ ) and explaining it in
 detail. The added benefit is that you get a much larger audience.

 For now I'll close this ticket, but feel free to re-open it _after_ you've
 tried the mail list and the consensus seems to be that it is a bug.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/857#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb  7 23:50:52 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Feb 2011 23:50:52 -0000
Subject: [Varnish] #858: caching behavior for root domains (homepage)
Message-ID: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>

#858: caching behavior for root domains (homepage)
------------------------------------------+---------------------------------
 Reporter:  txynidakis                    |        Type:  task  
   Status:  new                           |    Priority:  normal
Milestone:  Varnish 2.1 release           |   Component:  build 
  Version:  trunk                         |    Severity:  normal
 Keywords:  caching root (homepage) URLS  |  
------------------------------------------+---------------------------------
 Hi
 I'm still learning Varnish so please forgive some of my ignorance

 in the configs for varnish, we set up the caching rules not to cache .aspx
 pages.

 our home page is the root domain http://v8supercars.com.au

 in the varnish trace the request is 'GET /' which makes sence but without
 the .aspx extension it's doesn't get fall into the .aspx rule that we
 have.

 is there additionl rules that we need to add into the configs.

 Kind regards

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/858>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Feb 10 01:03:34 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 10 Feb 2011 01:03:34 -0000
Subject: [Varnish] #859: varnish does not process non-cachehigh traffic and
	waits on them
Message-ID: <041.e1cde82d4aea99dea2c04d0245788d7b@varnish-cache.org>

#859: varnish does not process non-cachehigh traffic and waits on them
-------------------+--------------------------------------------------------
 Reporter:  hyou   |        Type:  defect 
   Status:  new    |    Priority:  highest
Milestone:         |   Component:  build  
  Version:  2.1.2  |    Severity:  blocker
 Keywords:         |  
-------------------+--------------------------------------------------------
 It seems we are receiving more requests at a time than Varnish can handle
 under its configuration which has proven to be non-optimal.

 The requests process fine on apache back-end, and there seems to be no
 stress on the webservers.  However,

 1)  the response getting back to Akamai has 0 byte in content.
 2)  minutes after we stop sending the requests to varnish, varnish is
 still busy processing the the old requests sending them to apache.
 3)  Using JMeter for test, we get 503 errors returned, however on apache
 servers we get 200 success request in logs with some 301s.

 At first, thought the problem can be Keep-alive, but there seems to be no
 place that it gets set.  Sess_timeout by default is 5 sec, correct?
 Anything you think we should change?


 Our setup is Akami ---> Zeus load balancer ---> 2 varnish servers in round
 robin sharing cache ---> 4 apache severs Round Robin ----> Drupal 6



 Here is our config settings:

 Varnish file:

  Configuration file for varnish


 ? Maximum number of open files (for ulimit -n)
 NFILES=131072

 ? Locked shared memory (for ulimit -l)
 ? Default log size is 82MB + header
 MEMLOCK=82000

 DAEMON_OPTS="-a :80 ?
              -T 10.64.74.19:6082 ?
              -f /etc/varnish/default.vcl ?
              -u varnish -g varnish ?
              -s file,/var/lib/varnish/varnish_storage.bin,1G"




 and /etc/varnish/default.vcl contains:


 backend web1 ?
 .host = "tv-web1";
 .port = "80";
 .connect_timeout = 600s;
 .first_byte_timeout = 600s;
 .between_bytes_timeout = 600s;
 ?

 backend web2 ?
 .host = "tv-web2";
 .port = "80";
 .connect_timeout = 600s;
 .first_byte_timeout = 600s;
 .between_bytes_timeout = 600s;
 ?

 backend web3 ?
 .host = "tv-web3";
 .port = "80";
 .connect_timeout = 600s;
 .first_byte_timeout = 600s;
 .between_bytes_timeout = 600s;
 ?

 backend web5 ?
 .host = "tv-web5";
 .port = "80";
 .connect_timeout = 600s;
 .first_byte_timeout = 600s;
 .between_bytes_timeout = 600s;
 ?



 director www round-robin ?
   ? .backend = web1; ?
   ? .backend = web2; ?
   ? .backend = web3; ?
   ? .backend = web5; ?
 ?

 sub vcl_recv ?
 set req.backend = www;

 ? This section will turn off varnish for the whole site but allow us to do
 testing.
   ? Cache things with these extensions
   if (req.url ?
 "?.(ico?js?css?jpg?jpeg?png?gif?gz?tgz?bz2?tbz?mp3?ogg?swf?ICO?JS?CSS?JPG?JPEG?PNG?GIF?GZ?TGZ?BZ2?TBZ?MP3?OOG?SWF)")
 ?
     unset req.http.Cookie;
     unset req.http.User-Agent;
     return(lookup);
   ?


 ? Set so only www uses varnish
   if (req.http.host ? "origin.tv.com") ?
     return(pass);
   ?
   if (req.http.host ? "www?.tv?.com?origin?.www?.tv?.com") ?

   ?else?
     return(pass);
   ?

   if (req.http.User-Agent ? "MSIE") ?
     set req.http.User-Agent = "MSIE";
   ? else ?
     set req.http.User-Agent = "Mozilla";
   ?

 ? Normalize the host header always to be www.tv.com to reduce cache.  This
 is where we will need to set up Mobile.
   set req.http.host = "www.tv.com";
   remove req.http.X-Forwarded-For;
   set req.http.X-Forwarded-For = client.ip;

   // No varnish for install, update, or cron
   if (req.url ?
 "ahah_helper?.php?_points?.php?install?.php?update?.php?cron?.php") ?
     return (pass);
   ?

   // To users: if you have additional cookies being set by your system
 (e.g.
   // from a javascript analytics file or similar) you will need to add VCL
   // at this point to strip these cookies from the req object, otherwise
   // Varnish will not cache the response. This is safe for cookies that
 your
   // backed (Drupal) doesn't process.
   //
   // Again, the common example is an analytics or other Javascript add-on.
   // You should do this here, before the other cookie stuff, or by adding
   // to the regular-expression above.

  // Remove has_js and Google Analytics __* cookies.
   set req.http.Cookie = regsuball(req.http.Cookie,
 "(^?;?s*)(__?a-z?+?has_js)=?^;?*", "");
   // Remove a ";" prefix, if present.
   set req.http.Cookie = regsub(req.http.Cookie, "^;?s*", "");
   // Remove empty cookies.
   if (req.http.Cookie ? "^?s*$") ?
     unset req.http.Cookie;
   ?




   // Normalize the Accept-Encoding header
   // as per: http://varnish-cache.org/wiki/FAQ/Compression
   if (req.http.Accept-Encoding) ?
     if (req.url ? "?.(jpg?png?gif?gz?tgz?bz2?tbz?mp3?ogg)$") ?
       ? No point in compressing these
       remove req.http.Accept-Encoding;
     ? elsif (req.http.Accept-Encoding ? "gzip") ?
       set req.http.Accept-Encoding = "gzip";
    ? elsif (req.http.Accept-Encoding ? "deflate") ?
       set req.http.Accept-Encoding = "deflate";
     ? else ?
       ? unkown algorithm
       remove req.http.Accept-Encoding;
     ?
   ?

 ? This lets post requests go through because those may need cookies.
   if (req.request != "GET" && req.request != "HEAD") ?
    return (pass);
   ?

   // Let's have a little grace
   set req.grace = 30s;

 ? We are unsetting the cookies otherwise no drupal page will cache
 properly.  We try to set these back in vcl_miss not sure it's working
 though.
   set req.http.OLD-Cookie = req.http.Cookie;
   unset req.http.Cookie;

   return(lookup);
 ?

 sub vcl_miss ?
   if (req.url ?
 "?.(ico?js?css?jpg?jpeg?png?gif?gz?tgz?bz2?tbz?mp3?ogg?swf?ICO?JS?CSS?JPG?JPEG?PNG?GIF?GZ?TGZ?BZ2?TBZ?MP3?OOG?SWF)")
 ?

   ? else ?
     if (req.http.OLD-Cookie) ?
       set bereq.http.Cookie = req.http.OLD-Cookie;
       unset req.http.OLD-Cookie;
     ?
   ?
   return (fetch);
 ?

 sub vcl_hit ?
   if (req.http.Cache-Control ? "no-cache") ?
     ? Ignore requests via proxy caches,  IE users and badly behaved
 crawlers
     ? like msnbot that send no-cache with every request.
     if (! (req.http.Via ?? req.http.User-Agent ? "bot?MSIE")) ?
       set obj.ttl = 0s;
       return (restart);
     ?
   ?
 ?

 // Strip any cookies before an image/js/css is inserted into cache.
 // Also: future-support for ESI.
 sub vcl_fetch ?
   // Varnish determined the object was not cacheable
   if (!beresp.cacheable) ?
     set beresp.http.Varnish-X-Cacheable = "NO:Not Cacheable";
     set beresp.http.storage = "1";
     return(deliver);

   ?


 ? Check for no-store header and deliver if it exists.
   if (beresp.http.Edge-control ? "no-store")?
     set beresp.http.storage = "1";
     set beresp.cacheable = false;
     return(deliver);
   ?

 ? Cache things with these extensions
   if (bereq.url ?
 "?.(ico?js?css?jpg?jpeg?png?gif?gz?tgz?bz2?tbz?mp3?ogg?swf?ICO?JS?CSS?JPG?JPEG?PNG?GIF?GZ?TGZ?BZ2?TBZ?MP3?OOG?SWF)")
 ?
     unset beresp.http.set-cookie;

     /* Remove Expires from backend, it's not long enough */
     unset beresp.http.expires;

     /* Set the clients TTL on this object */
     set beresp.http.static = "true";
     /* Set how long Varnish will keep it */
     set beresp.ttl = 1d;
     return(deliver);
   ?

     unset beresp.http.set-cookie;
     unset beresp.http.expires;
     unset beresp.http.Cookie;

     /* Set how long Varnish will keep it */
     set beresp.ttl = 1d;

   return (deliver);
 ?

 sub vcl_deliver ?
    ?add cache hit data
    if (obj.hits > 0) ?
      ?if hit add hit count
      set resp.http.Varnish-X-Cache = "HIT";
      set resp.http.Vanrish-X-Cache-Hits = obj.hits;
    ? else ?
      set resp.http.Varnish-X-Cache = "MISS";
    ?

 ?

 sub vcl_hash ?

   if (req.http.Cookie) ?
     //set req.hash += req.http.Cookie;
   ?
 ?

 sub vcl_error ?
   // Let's deliver a slightly more friedly error page.
   // You can customize this as you wish.
   set obj.http.Content-Type = "text/html; charset=utf-8";
   synthetic ?"
   <?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>"? obj.status " " obj.response ?"</title>
       <style type="text/css">
       ?page ?width: 400px; padding: 10px; margin: 20px auto; border: 1px
 solid black; background-color: ?FFF;?
       p ?margin-left:20px;?
       body ?background-color: ?DDD; margin: auto;?
       </style>
     </head>
     <body>
     <div id="page">
     <h1>Page Could Not Be Loaded</h1>
     <p>We're very sorry, but the page could not be loaded properly. This
 should be fixed very soon, and we apologize for any inconvenience.</p>
     <hr />
     <h4>Debug Info:</h4>
     <pre>
 Status: "? obj.status ?"
 Response: "? obj.response ?"
 XID: "? req.xid ?"
 </pre>
       <address><a href="http://www.varnish-
 cache.org/">Varnish</a></address>
       </div>
     </body>
    </html>
    "?;
    return (deliver);

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/859>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Feb 10 03:50:09 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 10 Feb 2011 03:50:09 -0000
Subject: [Varnish] #859: varnish does not process non-cachehigh traffic
	and waits on them
In-Reply-To: <041.e1cde82d4aea99dea2c04d0245788d7b@varnish-cache.org>
References: <041.e1cde82d4aea99dea2c04d0245788d7b@varnish-cache.org>
Message-ID: <050.099fb8091c51ef788c85daba58d8ab49@varnish-cache.org>

#859: varnish does not process non-cachehigh traffic and waits on them
-------------------+--------------------------------------------------------
 Reporter:  hyou   |        Type:  defect 
   Status:  new    |    Priority:  highest
Milestone:         |   Component:  build  
  Version:  2.1.2  |    Severity:  blocker
 Keywords:         |  
-------------------+--------------------------------------------------------

Comment(by kb):

 I suspect you're seeing an "infinite" restart in vcl_hit().  I think you
 want to remove the Cache-Control header, rather than just repeat an
 identical request?  Setting the obj.ttl won't do what you want, plus I
 think it's irrelevant with the immediate restart.

 BTW, this is probably better for the -misc mailing list, rather than a
 bug, since there's no actual triaged bug yet.
 --
 kb

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/859#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Feb 10 22:11:26 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 10 Feb 2011 22:11:26 -0000
Subject: [Varnish] #310: WS_Reserve panic + error
In-Reply-To: <040.75b83f2a5390779c25adf146cd0b53d5@varnish-cache.org>
References: <040.75b83f2a5390779c25adf146cd0b53d5@varnish-cache.org>
Message-ID: <049.05e4c0286e648fd49b0f8ed099ef505c@varnish-cache.org>

#310: WS_Reserve panic + error
----------------------+-----------------------------------------------------
 Reporter:  sky       |        Owner:  kristian           
     Type:  defect    |       Status:  assigned           
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  2.1.4              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------

Comment(by harm):

 I can confirm that this issue still exists in v2.1.5
 {{{
 Feb 10 23:04:29 true1 varnishd[6213]: Child (20808) Panic message: Assert
 error in WS_Reserve(), cache_ws.c line 174:  Condition(ws->r == NULL) not
 true.
 thread = (cache-worker)#012ident =
 Linux,2.6.32-26-server,x86_64,-smalloc,-hcritbit,epoll
 Backtrace:  0x426778: /usr/sbin/varnishd()
 [0x426778]#012  0x432084: /usr/sbin/varnishd(WS_Reserve+0x54)
 [0x432084]#012  0x42be95: /usr/sbin/varnishd() [0x42be95]#012  0x4309b8:
 /usr/sbin/varnishd(VRT_SetHdr+0xf8)
 [0x4309b8]#012  0x7f3bf06f7fb3: ./vcl.1P9zoqAU.so(+0x1fb3)
 [0x7f3bf06f7fb3]#012  0x42b5e3: /usr/sbin/varnishd(VCL_hit_method+0x43)
 [0x42b5e3]#012  0x413b01: /usr/sbin/varnishd()
 [0x413b01]#012  0x415a3d: /usr/sbin/varnishd(CNT_Session+0x33d)
 [0x415a3d]#012  0x427f28: /usr/sbin/varnishd()
 [0x427f28]#012  0x4282fb: /usr/sbin/varnishd()
 [0x4282fb]
 sp = 0x7f3b2703e008 {
 #012  fd = 14, id = 14, xid = 2058269645,#012  client = 87.233.6.43
 36464,#012  step = STP_HIT,#012  handling = deliver,#012  restarts = 0,
 esis = 0#012  ws = 0x7f3b2703e080 { #012    id = "sess",#012
 }}}


 I have the following {{{ vcl_hit }}}
 {{{
 sub vcl_hit {
         if (!obj.cacheable) {
                 return(pass);
         }

         set obj.http.X-Cache = "Cache-Hit";

         return (deliver);
 }

 }}}

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/310#comment:14>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 14 19:55:08 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 14 Feb 2011 19:55:08 -0000
Subject: [Varnish] #860: Object not cached after force-refreshing
Message-ID: <044.a332d5bf46cf9068bc22e6e0542620b1@varnish-cache.org>

#860: Object not cached after force-refreshing
---------------------------------+------------------------------------------
 Reporter:  pulse00              |        Type:  defect
   Status:  new                  |    Priority:  normal
Milestone:  Varnish 2.1 release  |   Component:  build 
  Version:  trunk                |    Severity:  normal
 Keywords:                       |  
---------------------------------+------------------------------------------
 After force-refreshing an object from the backend, the resource is not
 cached anymore by varnish. I've tried multiple force-refresh techniques:

 http://varnish-cache.org/trac/wiki/VCLExampleEnableForceRefresh

 http://varnish-cache.org/trac/wiki/VCLExampleHashAlwaysMiss

 What's happening before a resource is force-refreshed:

 1. vcl_recv is called

 2. vcl_hit |?vcl_miss is called depending on the object's existence in the
 cache

 After one of the above techniques is used to force-refresh the cache for
 an object from the backend, only vcl_recv is called, but vcl_hit |
 vcl_miss is never called, although in vcl i specifically return(lookup)
 for the object. So the object is passed through to the backend and not put
 back in the cache.

 varnishd (varnish-2.1.5 SVN 0843d7a)

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/860>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 14 23:58:46 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 14 Feb 2011 23:58:46 -0000
Subject: [Varnish] #858: caching behavior for root domains (homepage)
In-Reply-To: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
Message-ID: <056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>

#858: caching behavior for root domains (homepage)
------------------------------------------+---------------------------------
 Reporter:  txynidakis                    |        Type:  task  
   Status:  new                           |    Priority:  normal
Milestone:  Varnish 2.1 release           |   Component:  build 
  Version:  trunk                         |    Severity:  normal
 Keywords:  caching root (homepage) URLS  |  
------------------------------------------+---------------------------------

Comment(by txynidakis):

 is there any update to this?

 Kind regards
 Tony

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/858#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From thebog at gmail.com  Tue Feb 15 09:14:57 2011
From: thebog at gmail.com (thebog)
Date: Tue, 15 Feb 2011 10:14:57 +0100
Subject: [Varnish] #858: caching behavior for root domains (homepage)
In-Reply-To: <056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
	<056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>
Message-ID: <AANLkTimiQ1xpNjDJ_CPfDg8cNV+KMmmW-TS-V1cfc+Th@mail.gmail.com>

Hi,

sorry for not giving you an answer in this e-mail, but the reason you
are not answered is that you have posted a question in a bugsubmit.

Use the varnish-misc mailinglists for questions, or better yet, IRC.

http://www.varnish-cache.org/support

YS
Anders Berg


On Tue, Feb 15, 2011 at 12:58 AM, Varnish
<varnish-bugs at varnish-cache.org> wrote:
> #858: caching behavior for root domains (homepage)
> ------------------------------------------+---------------------------------
> ?Reporter: ?txynidakis ? ? ? ? ? ? ? ? ? ?| ? ? ? ?Type: ?task
> ? Status: ?new ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Priority: ?normal
> Milestone: ?Varnish 2.1 release ? ? ? ? ? | ? Component: ?build
> ?Version: ?trunk ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Severity: ?normal
> ?Keywords: ?caching root (homepage) URLS ?|
> ------------------------------------------+---------------------------------
>
> Comment(by txynidakis):
>
> ?is there any update to this?
>
> ?Kind regards
> ?Tony
>
> --
> Ticket URL: <http://www.varnish-cache.org/trac/ticket/858#comment:1>
> Varnish <http://varnish-cache.org/>
> The Varnish HTTP Accelerator
>
> _______________________________________________
> varnish-bugs mailing list
> varnish-bugs at varnish-cache.org
> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
>



From varnish-bugs at varnish-cache.org  Tue Feb 15 09:31:44 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Feb 2011 09:31:44 -0000
Subject: [Varnish] #858: caching behavior for root domains (homepage)
In-Reply-To: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
Message-ID: <056.97bc05a7b3f6da2d53f22e936c89c7a3@varnish-cache.org>

#858: caching behavior for root domains (homepage)
----------------------------------+-----------------------------------------
  Reporter:  txynidakis           |        Type:  task                        
    Status:  closed               |    Priority:  normal                      
 Milestone:  Varnish 2.1 release  |   Component:  build                       
   Version:  trunk                |    Severity:  normal                      
Resolution:  invalid              |    Keywords:  caching root (homepage) URLS
----------------------------------+-----------------------------------------
Changes (by tfheen):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 This does not appear to be a bug in Varnish.  I'd recommend asking for
 user support on the varnish-misc mailing list.

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/858#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Feb 15 10:07:32 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Feb 2011 10:07:32 -0000
Subject: [Varnish] #861: Crash in VGZ_Destroy() when using ESI with do_gzip=1
Message-ID: <044.66316e80cf88823b7e784e7f13c9362a@varnish-cache.org>

#861: Crash in VGZ_Destroy() when using ESI with do_gzip=1
-----------------------------+----------------------------------------------
 Reporter:  kriller          |        Type:  defect  
   Status:  new              |    Priority:  normal  
Milestone:  Varnish 3.0 dev  |   Component:  varnishd
  Version:  trunk            |    Severity:  normal  
 Keywords:  ESI gzip         |  
-----------------------------+----------------------------------------------
 Varnish crashes in VGZ_Destroy() when enabling beresp.do_gzip and
 beresp.do_esi in vcl_fetch:

 Backtrace and sample ESI and final document is attached.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/861>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Feb 15 10:33:37 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Feb 2011 10:33:37 -0000
Subject: [Varnish] #861: Crash in VGZ_Destroy() when using ESI with
	do_gzip=1
In-Reply-To: <044.66316e80cf88823b7e784e7f13c9362a@varnish-cache.org>
References: <044.66316e80cf88823b7e784e7f13c9362a@varnish-cache.org>
Message-ID: <053.239b387d688c54ffe496665eb2c2c985@varnish-cache.org>

#861: Crash in VGZ_Destroy() when using ESI with do_gzip=1
------------------------------+---------------------------------------------
  Reporter:  kriller          |        Type:  defect  
    Status:  closed           |    Priority:  normal  
 Milestone:  Varnish 3.0 dev  |   Component:  varnishd
   Version:  trunk            |    Severity:  normal  
Resolution:  fixed            |    Keywords:  ESI gzip
------------------------------+---------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Fixed in 499c3de911ec8042f7418a60742428c4ae04384d

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/861#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From thebog at gmail.com  Tue Feb 15 22:56:00 2011
From: thebog at gmail.com (thebog)
Date: Tue, 15 Feb 2011 23:56:00 +0100
Subject: [Varnish] #858: caching behaviour for root domains (homepage)
In-Reply-To: <4ADDD2718038414E91589285477BA11C44D85D12FA@WSMSG3152V.srv.dir.telstra.com>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
	<056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>
	<AANLkTimiQ1xpNjDJ_CPfDg8cNV+KMmmW-TS-V1cfc+Th@mail.gmail.com>
	<4ADDD2718038414E91589285477BA11C44D85D12FA@WSMSG3152V.srv.dir.telstra.com>
Message-ID: <AANLkTi=bLuQcqZiyoSS+eMhZOmQGPkrLgneRrJEruwgs@mail.gmail.com>

You send an email with your questions to:

varnish-misc at varnish-cache.org

easy as that. :) Or use the IRC channel and start a chat.

Some info can also be found in the documentation:

http://www.varnish-cache.org/docs/2.1/

and on old wiki:

http://www.varnish-cache.org/trac/wiki/VCLExamples

YS
Anders Berg

On Tue, Feb 15, 2011 at 10:41 PM, Xynidakis, Tony A
<Antony.A.Xynidakis at team.telstra.com> wrote:
> Hi Anders
> I've subscribed to the mailing list but I'm not sure where to open or submit a case.
>
> Kind regards
> Tony
>
> -----Original Message-----
> From: thebog [mailto:thebog at gmail.com]
> Sent: Tuesday, 15 February 2011 8:15 PM
> To: Varnish
> Cc: Xynidakis, Tony A
> Subject: Re: [Varnish] #858: caching behavior for root domains (homepage)
>
> Hi,
>
> sorry for not giving you an answer in this e-mail, but the reason you
> are not answered is that you have posted a question in a bugsubmit.
>
> Use the varnish-misc mailinglists for questions, or better yet, IRC.
>
> http://www.varnish-cache.org/support
>
> YS
> Anders Berg
>
>
> On Tue, Feb 15, 2011 at 12:58 AM, Varnish
> <varnish-bugs at varnish-cache.org> wrote:
>> #858: caching behavior for root domains (homepage)
>> ------------------------------------------+---------------------------------
>> ?Reporter: ?txynidakis ? ? ? ? ? ? ? ? ? ?| ? ? ? ?Type: ?task
>> ? Status: ?new ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Priority: ?normal
>> Milestone: ?Varnish 2.1 release ? ? ? ? ? | ? Component: ?build
>> ?Version: ?trunk ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Severity: ?normal
>> ?Keywords: ?caching root (homepage) URLS ?|
>> ------------------------------------------+---------------------------------
>>
>> Comment(by txynidakis):
>>
>> ?is there any update to this?
>>
>> ?Kind regards
>> ?Tony
>>
>> --
>> Ticket URL: <http://www.varnish-cache.org/trac/ticket/858#comment:1>
>> Varnish <http://varnish-cache.org/>
>> The Varnish HTTP Accelerator
>>
>> _______________________________________________
>> varnish-bugs mailing list
>> varnish-bugs at varnish-cache.org
>> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
>>
>



From Antony.A.Xynidakis at team.telstra.com  Tue Feb 15 21:41:05 2011
From: Antony.A.Xynidakis at team.telstra.com (Xynidakis, Tony A)
Date: Wed, 16 Feb 2011 08:41:05 +1100
Subject: [Varnish] #858: caching behaviour for root domains (homepage)
In-Reply-To: <AANLkTimiQ1xpNjDJ_CPfDg8cNV+KMmmW-TS-V1cfc+Th@mail.gmail.com>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
	<056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>
	<AANLkTimiQ1xpNjDJ_CPfDg8cNV+KMmmW-TS-V1cfc+Th@mail.gmail.com>
Message-ID: <4ADDD2718038414E91589285477BA11C44D85D12FA@WSMSG3152V.srv.dir.telstra.com>

Hi Anders
I've subscribed to the mailing list but I'm not sure where to open or submit a case.

Kind regards
Tony

-----Original Message-----
From: thebog [mailto:thebog at gmail.com] 
Sent: Tuesday, 15 February 2011 8:15 PM
To: Varnish
Cc: Xynidakis, Tony A
Subject: Re: [Varnish] #858: caching behavior for root domains (homepage)

Hi,

sorry for not giving you an answer in this e-mail, but the reason you
are not answered is that you have posted a question in a bugsubmit.

Use the varnish-misc mailinglists for questions, or better yet, IRC.

http://www.varnish-cache.org/support

YS
Anders Berg


On Tue, Feb 15, 2011 at 12:58 AM, Varnish
<varnish-bugs at varnish-cache.org> wrote:
> #858: caching behavior for root domains (homepage)
> ------------------------------------------+---------------------------------
> ?Reporter: ?txynidakis ? ? ? ? ? ? ? ? ? ?| ? ? ? ?Type: ?task
> ? Status: ?new ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Priority: ?normal
> Milestone: ?Varnish 2.1 release ? ? ? ? ? | ? Component: ?build
> ?Version: ?trunk ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Severity: ?normal
> ?Keywords: ?caching root (homepage) URLS ?|
> ------------------------------------------+---------------------------------
>
> Comment(by txynidakis):
>
> ?is there any update to this?
>
> ?Kind regards
> ?Tony
>
> --
> Ticket URL: <http://www.varnish-cache.org/trac/ticket/858#comment:1>
> Varnish <http://varnish-cache.org/>
> The Varnish HTTP Accelerator
>
> _______________________________________________
> varnish-bugs mailing list
> varnish-bugs at varnish-cache.org
> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
>



From Antony.A.Xynidakis at team.telstra.com  Tue Feb 15 23:01:22 2011
From: Antony.A.Xynidakis at team.telstra.com (Xynidakis, Tony A)
Date: Wed, 16 Feb 2011 10:01:22 +1100
Subject: [Varnish] #858: caching behaviour for root domains (homepage)
In-Reply-To: <AANLkTi=bLuQcqZiyoSS+eMhZOmQGPkrLgneRrJEruwgs@mail.gmail.com>
References: <047.442d610fa502a9f369ef87e3df86c966@varnish-cache.org>
	<056.c6da54ecfada48238ed67d0657597873@varnish-cache.org>
	<AANLkTimiQ1xpNjDJ_CPfDg8cNV+KMmmW-TS-V1cfc+Th@mail.gmail.com>
	<4ADDD2718038414E91589285477BA11C44D85D12FA@WSMSG3152V.srv.dir.telstra.com>
	<AANLkTi=bLuQcqZiyoSS+eMhZOmQGPkrLgneRrJEruwgs@mail.gmail.com>
Message-ID: <4ADDD2718038414E91589285477BA11C44D865544A@WSMSG3152V.srv.dir.telstra.com>

Thanks Anders
Yeah I figured it out once i 'actually' read the confirmation email!!

Kind regards
Tony


-----Original Message-----
From: thebog [mailto:thebog at gmail.com] 
Sent: Wednesday, 16 February 2011 9:56 AM
To: Xynidakis, Tony A
Cc: Varnish
Subject: Re: [Varnish] #858: caching behaviour for root domains (homepage)

You send an email with your questions to:

varnish-misc at varnish-cache.org

easy as that. :) Or use the IRC channel and start a chat.

Some info can also be found in the documentation:

http://www.varnish-cache.org/docs/2.1/

and on old wiki:

http://www.varnish-cache.org/trac/wiki/VCLExamples

YS
Anders Berg

On Tue, Feb 15, 2011 at 10:41 PM, Xynidakis, Tony A
<Antony.A.Xynidakis at team.telstra.com> wrote:
> Hi Anders
> I've subscribed to the mailing list but I'm not sure where to open or submit a case.
>
> Kind regards
> Tony
>
> -----Original Message-----
> From: thebog [mailto:thebog at gmail.com]
> Sent: Tuesday, 15 February 2011 8:15 PM
> To: Varnish
> Cc: Xynidakis, Tony A
> Subject: Re: [Varnish] #858: caching behavior for root domains (homepage)
>
> Hi,
>
> sorry for not giving you an answer in this e-mail, but the reason you
> are not answered is that you have posted a question in a bugsubmit.
>
> Use the varnish-misc mailinglists for questions, or better yet, IRC.
>
> http://www.varnish-cache.org/support
>
> YS
> Anders Berg
>
>
> On Tue, Feb 15, 2011 at 12:58 AM, Varnish
> <varnish-bugs at varnish-cache.org> wrote:
>> #858: caching behavior for root domains (homepage)
>> ------------------------------------------+---------------------------------
>> ?Reporter: ?txynidakis ? ? ? ? ? ? ? ? ? ?| ? ? ? ?Type: ?task
>> ? Status: ?new ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Priority: ?normal
>> Milestone: ?Varnish 2.1 release ? ? ? ? ? | ? Component: ?build
>> ?Version: ?trunk ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Severity: ?normal
>> ?Keywords: ?caching root (homepage) URLS ?|
>> ------------------------------------------+---------------------------------
>>
>> Comment(by txynidakis):
>>
>> ?is there any update to this?
>>
>> ?Kind regards
>> ?Tony
>>
>> --
>> Ticket URL: <http://www.varnish-cache.org/trac/ticket/858#comment:1>
>> Varnish <http://varnish-cache.org/>
>> The Varnish HTTP Accelerator
>>
>> _______________________________________________
>> varnish-bugs mailing list
>> varnish-bugs at varnish-cache.org
>> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
>>
>



From varnish-bugs at varnish-cache.org  Fri Feb 18 19:31:45 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 18 Feb 2011 19:31:45 -0000
Subject: [Varnish] #849: Session timeout while receiving POST data from
	client causes multiple broken backend requests
In-Reply-To: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org>
References: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org>
Message-ID: <049.783fdfae5ab9ad130220eec623b87689@varnish-cache.org>

#849: Session timeout while receiving POST data from client causes multiple
broken backend requests
-----------------------------------------------------------------------------------+
 Reporter:  lew                                                                    |        Type:  defect  
   Status:  new                                                                    |    Priority:  normal  
Milestone:                                                                         |   Component:  varnishd
  Version:  2.1.4                                                                  |    Severity:  normal  
 Keywords:  503, post, backend write error: 11 (Resource temporarily unavailable)  |  
-----------------------------------------------------------------------------------+

Comment(by rtsh):

 I believe this is an issue.  It affects us in our production environment
 when receiving requests from people on slow connections (typically it's
 affected visitors from India and the Phillipines, as well as mobile
 devices).  We've worked around this by increasing sess_timeout to 60s as
 per the original comment.  However, I feel this is closely associated with
 ticket 748.

 To help someone debug this further, I have a precise test case attached.
 This was done on:


 {{{
 [root at xx ~]# rpm -qa |grep varnish
 varnish-libs-2.1.5-1
 varnish-2.1.5-1
 [root at xx ~]# uname -a
 Linux xx 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64
 x86_64 GNU/Linux
 [root at xx ~]# cat /etc/redhat-release
 CentOS release 5.5 (Final)
 [root at xx ~]#
 }}}



 To reproduce the issue, install varnish from RPM, then change
 /etc/sysconfig/varnish to be:

 {{{
 NFILES=131072
 MEMLOCK=82000
 DAEMON_OPTS="-a 10.1.2.130:80  \
              -T :6082 \
              -f /etc/varnish/default.vcl \
              -u varnish -g varnish \
              -p purge_dups=on \
              -p shm_workspace=32768 \
              -p ping_interval=1 \
              -p sess_workspace=65536 \
              -s file,/var/lib/varnish/varnish_storage.bin,1G"
 }}}

 Note that ping_interval is set to 1 simply to help produce more detailed
 timestamps in the varnishlog.  Create a minimal VCL file, as follows:

 {{{
 backend b1 { .host = "127.0.0.1"; .port = "80"; .connect_timeout = 30s;
 .first_byte_timeout = 30s; .between_bytes_timeout = 30s; }
 backend b2 { .host = "127.0.0.1"; .port = "80"; .connect_timeout = 30s;
 .first_byte_timeout = 30s; .between_bytes_timeout = 30s; }
 backend b3 { .host = "127.0.0.1"; .port = "80"; .connect_timeout = 30s;
 .first_byte_timeout = 30s; .between_bytes_timeout = 30s; }

 director pool random {
   { .backend = b1; .weight = 1; }
   { .backend = b2; .weight = 1; }
   { .backend = b3; .weight = 1; }
 }


 sub vcl_recv {
   set req.backend = pool;
   return (pass);
 }

 sub vcl_error {
   if (req.restarts<2) {
     restart;
   }
 }
 }}}

 To test, simply telnet to varnish on port 80 and send an incomplete POST
 request (just copy and paste as far as "test" and a new line - the
 HTTP/1.1 503 response comes back from Varnish after some time.)

 {{{

 [root at xx ~]# telnet a.b.c.130 80
 Trying a.b.c.130...
 Connected to xx (a.b.c.130).
 Escape character is '^]'.
 POST / HTTP/1.1
 Host: foo
 Content-length: 400

 test
 HTTP/1.1 503 Service Unavailable
 Server: Varnish
 Retry-After: 0
 Content-Type: text/html; charset=utf-8
 Content-Length: 419
 Date: Fri, 18 Feb 2011 19:13:59 GMT
 X-Varnish: 2120546936
 Age: 15
 Via: 1.1 varnish
 Connection: close


 <?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>503 Service Unavailable</title>
   </head>
   <body>
     <h1>Error 503 Service Unavailable</h1>
     <p>Service Unavailable</p>
     <h3>Guru Meditation:</h3>
     <p>XID: 2120546936</p>
     <hr>
     <p>Varnish cache server</p>
   </body>
 </html>
 Connection closed by foreign host.
 [root at xx ~]#
 }}}

 The varnishlog follows.  What is important to note is that despite each
 backend's timeout being set to 30 seconds for each possible timeout
 parameter, the total time to serve the request was 15 seconds, which
 equates to three times the sess_timeout parameter, and isn't affected by
 the backend definitions in the VCL.

 {{{
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056416 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056417 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056418 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056419 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056420 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056421 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056422 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056423 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056424 1.0
    11 SessionOpen  c a.b.c.130 48442 a.b.c.130:80
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056425 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056426 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056427 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056428 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056429 1.0
    11 ReqStart     c a.b.c.130 48442 2120546936
    11 RxRequest    c POST
    11 RxURL        c /
    11 RxProtocol   c HTTP/1.1
    11 RxHeader     c Host: foo
    11 RxHeader     c Content-length: 400
    11 VCL_call     c recv
    11 VCL_return   c pass
    11 VCL_call     c hash
    11 VCL_return   c hash
    11 VCL_call     c pass
    11 VCL_return   c pass
    13 BackendOpen  b b1 127.0.0.1 34200 127.0.0.1 80
    11 Backend      c 13 pool b1
    13 TxRequest    b POST
    13 TxURL        b /
    13 TxProtocol   b HTTP/1.1
    13 TxHeader     b Host: foo
    13 TxHeader     b Content-length: 400
    13 TxHeader     b X-Varnish: 2120546936
    11 FetchError   c backend write error: 11 (Resource temporarily
 unavailable)
    13 BackendClose b b1
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056430 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056431 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056432 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056433 1.0
    11 VCL_call     c error
    11 VCL_return   c restart
    11 VCL_call     c recv
    11 VCL_return   c pass
    11 VCL_call     c hash
    11 VCL_return   c hash
    11 VCL_call     c pass
    11 VCL_return   c pass
    13 BackendOpen  b b2 127.0.0.1 34201 127.0.0.1 80
    11 Backend      c 13 pool b2
    13 TxRequest    b POST
    13 TxURL        b /
    13 TxProtocol   b HTTP/1.1
    13 TxHeader     b Host: foo
    13 TxHeader     b Content-length: 400
    13 TxHeader     b X-Varnish: 2120546936
    11 FetchError   c backend write error: 11 (Resource temporarily
 unavailable)
    13 BackendClose b b2
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056434 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056435 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056436 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056437 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056438 1.0
    11 VCL_call     c error
    11 VCL_return   c restart
    11 VCL_call     c recv
    11 VCL_return   c pass
    11 VCL_call     c hash
    11 VCL_return   c hash
    11 VCL_call     c pass
    11 VCL_return   c pass
    13 BackendOpen  b b3 127.0.0.1 34202 127.0.0.1 80
    11 Backend      c 13 pool b3
    13 TxRequest    b POST
    13 TxURL        b /
    13 TxProtocol   b HTTP/1.1
    13 TxHeader     b Host: foo
    13 TxHeader     b Content-length: 400
    13 TxHeader     b X-Varnish: 2120546936
    11 FetchError   c backend write error: 11 (Resource temporarily
 unavailable)
    13 BackendClose b b3
    11 VCL_call     c error
    11 VCL_return   c deliver
    11 VCL_call     c deliver
    11 VCL_return   c deliver
    11 TxProtocol   c HTTP/1.1
    11 TxStatus     c 503
    11 TxResponse   c Service Unavailable
    11 TxHeader     c Server: Varnish
    11 TxHeader     c Retry-After: 0
    11 TxHeader     c Content-Type: text/html; charset=utf-8
    11 TxHeader     c Content-Length: 419
    11 TxHeader     c Date: Fri, 18 Feb 2011 19:13:59 GMT
    11 TxHeader     c X-Varnish: 2120546936
    11 TxHeader     c Age: 15
    11 TxHeader     c Via: 1.1 varnish
    11 TxHeader     c Connection: close
    11 Length       c 419
    11 ReqEnd       c 2120546936 1298056424.244601965 1298056439.268516064
 0.000581026 15.023117065 0.000797033
    11 SessionClose c error
    11 StatSess     c a.b.c.130 48442 15 1 1 0 3 0 236 419
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056439 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056440 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056441 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056442 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056443 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056444 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056445 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056446 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 200 19 PONG 1298056447 1.0
 }}}

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/849#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Feb 19 18:25:17 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 19 Feb 2011 18:25:17 -0000
Subject: [Varnish] #862: locking varnish
Message-ID: <045.0bf8b47425198055e7617379a05d71f2@varnish-cache.org>

#862: locking varnish
---------------------------------+------------------------------------------
 Reporter:  santosmr             |        Type:  defect  
   Status:  new                  |    Priority:  high    
Milestone:  Varnish 2.1 release  |   Component:  varnishd
  Version:  trunk                |    Severity:  critical
 Keywords:                       |  
---------------------------------+------------------------------------------
 Hello

 My varnish hangs from time to time something for 24 hours.
 In the log I found the following message: /var/log/messages

 Feb 17 10:52:06 proxyb2 varnishd[12396]: Child (12401) said
 Feb 17 10:52:06 proxyb2 varnishd[12396]: Child (12401) said Child starts
 Feb 17 10:52:06 proxyb2 varnishd[12396]: Child (12401) said managed to
 mmap 2147483648 bytes of 2147483648
 Feb 17 10:52:06 proxyb2 varnishd[12396]: Child (12401) said Child dies
 Feb 17 10:52:06 proxyb2 varnishd[12396]: Child (12401) died
 Feb 17 10:53:07 proxyb2 varnishd[12396]: Manager got SIGINT
 Feb 17 10:53:09 proxyb2 varnishd[12502]: child (12507) Started
 Feb 17 10:53:09 proxyb2 varnishd[12502]: Pushing vcls failed:
 dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object
 file: Permission denied

 varnishadm and went into my output is:

 param.show
 200 2367
 acceptor_sleep_decay       0.900000 []
 acceptor_sleep_incr        0.001000 [s]
 acceptor_sleep_max         0.050000 [s]
 auto_restart               on [bool]
 ban_lurker_sleep           0.000000 [s]
 between_bytes_timeout      60.000000 [s]
 cache_vbe_conns            off [bool]
 cc_command                 "exec cc -fpic -shared -Wl,-x -o %o %s"
 cli_buffer                 8192 [bytes]
 cli_timeout                10 [seconds]
 clock_skew                 10 [s]
 connect_timeout            0.400000 [s]
 critbit_cooloff            180.000000 [s]
 default_grace              10 [seconds]
 default_ttl                120 [seconds]
 diag_bitmap                0x0 [bitmap]
 err_ttl                    0 [seconds]
 esi_syntax                 0 [bitmap]
 fetch_chunksize            128 [kilobytes]
 first_byte_timeout         60.000000 [s]
 group                      varnish (102)
 http_headers               64 [header lines]
 http_range_support         off [bool]
 listen_address             :80
 listen_depth               1024 [connections]
 log_hashstring             off [bool]
 log_local_address          off [bool]
 lru_interval               2 [seconds]
 max_esi_includes           5 [includes]
 max_restarts               4 [restarts]
 overflow_max               100 [%]
 ping_interval              3 [seconds]
 pipe_timeout               60 [seconds]
 prefer_ipv6                off [bool]
 purge_dups                 on [bool]
 rush_exponent              3 [requests per request]
 saintmode_threshold        10 [objects]
 send_timeout               600 [seconds]
 sess_timeout               10 [seconds]
 sess_workspace             65536 [bytes]
 session_linger             50 [ms]
 session_max                100000 [sessions]
 shm_reclen                 255 [bytes]
 shm_workspace              8192 [bytes]
 syslog_cli_traffic         on [bool]
 thread_pool_add_delay      20 [milliseconds]
 thread_pool_add_threshold  2 [requests]
 thread_pool_fail_delay     200 [milliseconds]
 thread_pool_max            2000 [threads]
 thread_pool_min            10 [threads]
 thread_pool_purge_delay    1000 [milliseconds]
 thread_pool_stack          unlimited [bytes]
 thread_pool_timeout        120 [seconds]
 thread_pools               2 [pools]
 thread_stats_rate          10 [requests]
 user                       varnish (101)
 vcl_trace                  off [bool]
 waiter                     default (epoll, poll)


 and

 stats
 200 1951
       143048  Client connections accepted
       682714  Client requests received
       480993  Cache hits
       196973  Cache misses
        15674  Backend conn. success
       186049  Backend conn. reuses
        14918  Backend conn. was closed
       200975  Backend conn. recycles
            1  Fetch head
       187473  Fetch with Length
        14099  Fetch chunked
           89  Fetch wanted close
           52  Fetch zero len
          202  N struct sess_mem
          114  N struct sess
         9527  N struct object
         9548  N struct objectcore
         1980  N struct objecthead
        19768  N struct smf
          555  N small free smf
            2  N large free smf
            7  N struct vbe_conn
           25  N worker threads
          565  N worker threads created
         5766  N overflowed work requests
            6  N backends
       187446  N expired objects
       265340  N LRU moved objects
       632047  Objects sent with write
       143043  Total Sessions
       682714  Total Requests
         4748  Total pass
       201714  Total fetch
    192649441  Total header bytes
   6922785643  Total body bytes
        11120  Session Closed
          677  Session Pipeline
          844  Session Read Ahead
       672822  Session Linger
       658718  Session herd
     33830604  SHM records
      2233862  SHM writes
           17  SHM flushes due to overflow
          372  SHM MTX contention
           15  SHM cycles through buffer
       399606  allocator requests
        19211  outstanding allocations
    338653184  bytes allocated
   1808830464  bytes free
            7  SMS allocator requests
         3493  SMS bytes allocated
         3493  SMS bytes freed
       201718  Backend requests made
            1  N vcl total
            1  N vcl available
            1  N total active purges
            1  N new purges added
       677949  HCB Lookups without lock
        28241  HCB Lookups with lock
        28241  HCB Inserts
        36255  Client uptime


 My profile *.vcl

 # Define as maquinas de backend
 backend blog1 {
         .host = "10.17.0.100";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 backend blog2 {
         .host = "10.17.0.101";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 backend blog3 {
         .host = "10.17.0.102";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 backend blog4 {
         .host = "10.17.0.99";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 backend blog5 {
         .host = "10.17.0.98";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 backend blog6 {
         .host = "10.17.0.97";
         .port = "80";
         .connect_timeout = 50s;
         .first_byte_timeout = 120s;
         .between_bytes_timeout = 50s;
 }

 director web_director round-robin {
         { .backend = blog1; }
         { .backend = blog2; }
         { .backend = blog3; }
         { .backend = blog4; }
         { .backend = blog5; }
         { .backend = blog6; }
 }

 # ACL para o purge list
 acl purge {
         "localhost";
 sub vcl_recv {
         # normalize Accept-Encoding to reduce vary
         if (req.http.Accept-Encoding) {
                 if (req.http.User-Agent ~ "MSIE 6") {
                         unset req.http.Accept-Encoding;
                 } elsif (req.http.Accept-Encoding ~ "gzip") {
                         set req.http.Accept-Encoding = "gzip";
                 } elsif (req.http.Accept-Encoding ~ "deflate") {
                         set req.http.Accept-Encoding = "deflate";
                 } else {
                         unset req.http.Accept-Encoding;
                 }
         }

         # PURGE
         if (req.request == "PURGE") {
                 if (!client.ip ~ purge) {
                         error 403 "Forbbiden.";
                 }

                 # Purging ban-lurker friendly
                 purge("obj.http.X-Cache-Url ~ ^" req.url "$ && obj.http.X
 -Cache-Hostname == " req.http.host);

                 error 200 "Purged.";
                 return (lookup);
         }

         # Informa o tipo de backend, no caso balanceamento
         set req.backend = web_director;
         # Se for administracao, ou wp-cron, nao fazer cache
         if (req.url ~ "wp-(login|admin|cron)") {
                return (pass);
         }

         # Ativa PURGES depois de posts de comentarios
         #if (req.request == "POST" && req.url ~ "wp-comments-post.php") {
         #       if (req.http.host ~ "^(www.)?bispomacedo.com.br$") {
         #                       # limpa a home do usu??rio.
         #                purge("req.url ==
 "regsub(req.http.Referer,"http://(www.)?bispomacedo.com.br",""));
         #                # limpa a pagina do post.
         #                purge("req.url ==
 "regsub(req.http.Referer,"http://(www.)?bispomacedo.com.br/([^/.]*)/(.*)$","/\2/"));
         #        } elsif (req.http.host ~ "^(www.)?bispomacedo.blog.br$")
 {
         #                # limpa a home do usu??rio.
         #                purge("req.url ==
 "regsub(req.http.Referer,"http://(www.)?bispomacedo.blog.br",""));
         #                # limpa a pagina do post.
         #                purge("req.url ==
 "regsub(req.http.Referer,"http://(www.)?bispomacedo.blog.br/([^/.]*)/(.*)$","/\2/"));
         #        }
         #}

         # Nao faz cache de requisicoes que nao sejam estas GET ou HEAD
         if (req.request != "GET" && req.request != "HEAD") { return
 (pass); }

         # Se por acaso o usuario estiver logado ou usou site
 (comentarios), entao nao fazer cache
         if (req.http.Authorization || req.http.Cookie ~ "wordpress_") {
                 return (pass);
         }

         # Se o header informar para n??o fazer cache, obdecemos ...
         if (req.http.Cache-Control ~ "no-cache") {
                 return (pass);
         }

         # Excessoes de cache
         if (req.url ~ "/wp-content/plugins/wp-email/email-image-
 verify.php") {
                 return (pass);
         }

         # Se chegou ate aqui, e' vistante comum e nao se enquadra em cache
         return (lookup);
 }

 sub vcl_fetch {
         # Se for administracao, ou wp-cron, nao fazer cache
         if (req.url ~ "wp-(login|admin|cron)") {
                 return (pass);
         }

         # Configura cabecalhos especiais para o uso do ban lurker
         set beresp.http.X-Cache-Url = req.url;
         set beresp.http.X-Cache-Hostname = req.http.host;

         # Cache para os objetos
         set beresp.cacheable = true;

         # Tempo de vida dos objetos
         if (req.url ~
 "\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|mp3|mp4|m4a|ogg|mov|avi|wmv)$")
 { set beresp.ttl = 60m; } # Imagens e
 multimedia - 60 minutos
         elsif (req.url ~ "\.(css|js)$") { set beresp.ttl = 10m; } # CSS e
 JavaScript - 10 minutos
         else { set beresp.ttl = 1m; } # Como padrao - 1 minuto

         # Entrega
         return (deliver);

         # Retira os cookies da jogada
         unset beresp.http.Set-Cookie;

         # Se o backend falhar, servir do cache com tempo de vida ate 30
 minutos
         set req.grace = 30m;
 }

 sub vcl_deliver {
         # Retira os cabecalhos especiais de uso do ban lurker
         unset resp.http.X-Cache-Url;
         unset resp.http.X-Cache-Hostname;

         # Retira os cabecalhos de informacoes de forward do varnish
         unset resp.http.x-served-by-hostname;
         unset resp.http.x-served-by-identity;
         unset resp.http.x-varnish;
         unset resp.http.via;

         return (deliver);
 }

 sub vcl_pipe {
         unset bereq.http.x-varnish;
         set bereq.http.connection = "close";

         return (pipe);
 }

 sub vcl_pass {
         #unset bereq.http.x-varnish;
         return (pass);
 }

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

         if (!obj.cacheable) {
                 return (pass);
         }
         return (deliver);
 }

 sub vcl_miss {
         unset bereq.http.x-varnish;

         if (req.request == "PURGE") {
                 error 404 "Not in cache.";
         }
         return (fetch);
 }

 sub vcl_error {
     #if (obj.status == 503) {
     #    restart;
     #}

      set obj.http.eontent-Type = "text/html; charsetnutf-8";
      synthetic {"
 <?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>"} obj.status " " obj.response {"</title>
    </head>
    <body>
      <h1>Error "} obj.status " " obj.response {"</h1>
      <p>"} obj.response {"</p>
      <h3>Guru Meditation</h3>
      <p>XID: "} req.xid {"</p>
      <hr>
      <address>
         <a href="http://bispomacedo.com.br/">Blog do Bispo Macedo</a>
      </address>
    </body>
  </html>
 "};
      return (deliver);
 }



 could help me with this little problem

 tks

 santosmr

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/862>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 13:06:45 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 13:06:45 -0000
Subject: [Varnish] #862: locking varnish
In-Reply-To: <045.0bf8b47425198055e7617379a05d71f2@varnish-cache.org>
References: <045.0bf8b47425198055e7617379a05d71f2@varnish-cache.org>
Message-ID: <054.0824a3c097434f8556eab87f1e745ead@varnish-cache.org>

#862: locking varnish
----------------------------------+-----------------------------------------
  Reporter:  santosmr             |        Type:  defect  
    Status:  closed               |    Priority:  high    
 Milestone:  Varnish 2.1 release  |   Component:  varnishd
   Version:  trunk                |    Severity:  critical
Resolution:  invalid              |    Keywords:          
----------------------------------+-----------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 This looks more like script/install/package/os-confusion than a Varnish
 bug at first glance. As such, I'm closing this ticket.

 I suggest you explain the problem and environment on the varnish-misc mail
 list ( see http://www.varnish-cache.org/support for details). You'll have
 a much larger audience.

 Feel free to re-open the ticket if -- after discussion on varnish-misc or
 similar -- you're still convinced this is a bug.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/862#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 13:11:25 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 13:11:25 -0000
Subject: [Varnish] #860: Object not cached after force-refreshing
In-Reply-To: <044.a332d5bf46cf9068bc22e6e0542620b1@varnish-cache.org>
References: <044.a332d5bf46cf9068bc22e6e0542620b1@varnish-cache.org>
Message-ID: <053.12ebf4f6ede036f4728a6cee21a6059d@varnish-cache.org>

#860: Object not cached after force-refreshing
----------------------------------+-----------------------------------------
  Reporter:  pulse00              |        Type:  defect
    Status:  closed               |    Priority:  normal
 Milestone:  Varnish 2.1 release  |   Component:  build 
   Version:  trunk                |    Severity:  normal
Resolution:  invalid              |    Keywords:        
----------------------------------+-----------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 At first glance, this sounds more like a configuration issue than a bug in
 Varnish. As such, I am closing the ticket.

 I suggest you explain the problem and environment on the varnish-misc mail
 list (see http://www.varnish-cache.org/support for details) ?? you'll have
 a much larger audience.

 If you're still convinced this is a bug after you've discussed the matter
 on varnish-misc you are free to re-open the ticket of course.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/860#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 13:12:56 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 13:12:56 -0000
Subject: [Varnish] #859: varnish does not process non-cachehigh traffic
	and waits on them
In-Reply-To: <041.e1cde82d4aea99dea2c04d0245788d7b@varnish-cache.org>
References: <041.e1cde82d4aea99dea2c04d0245788d7b@varnish-cache.org>
Message-ID: <050.881eac42e13d5a0c138414ed1403231c@varnish-cache.org>

#859: varnish does not process non-cachehigh traffic and waits on them
----------------------+-----------------------------------------------------
  Reporter:  hyou     |        Type:  defect 
    Status:  closed   |    Priority:  highest
 Milestone:           |   Component:  build  
   Version:  2.1.2    |    Severity:  blocker
Resolution:  invalid  |    Keywords:         
----------------------+-----------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 As kb pointed out, this is probably more of a varnish-misc case than
 anything. See http://www.varnish-cache.org/support for details.

 I'm closing this ticket, as you'll have a much larger audience on varnish-
 misc. Feel free to re-open it if you're still convinced this is a bug
 after a discussion on -misc.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/859#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 13:17:16 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 13:17:16 -0000
Subject: [Varnish] #847: vcl_pipe() closes connection on POST requests
	on timeout 60s
In-Reply-To: <043.7ca131263f9cf6243ae46b42836def7f@varnish-cache.org>
References: <043.7ca131263f9cf6243ae46b42836def7f@varnish-cache.org>
Message-ID: <052.de09bf14675c03a0c84db1c7ec7b82d8@varnish-cache.org>

#847: vcl_pipe() closes connection on POST requests on timeout 60s
----------------------+-----------------------------------------------------
 Reporter:  werdan    |        Owner:  kristian           
     Type:  defect    |       Status:  closed             
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:  worksforme         
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 Closing this as the original reporter hasn't replied back. I am assuming
 some configuration messup, and recommend that followups go to varnish-misc
 (see http://www.varnish-cache.org/support for details) before this is
 potentially re-opened (you'll have a much larger audience anyway).

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/847#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 13:19:09 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 13:19:09 -0000
Subject: [Varnish] #841: varnish 2.1.4
In-Reply-To: <043.6d2854f79c943132b9245f23e64c5b29@varnish-cache.org>
References: <043.6d2854f79c943132b9245f23e64c5b29@varnish-cache.org>
Message-ID: <052.124cca87ea3e44636cb4b40d019faf21@varnish-cache.org>

#841: varnish 2.1.4
--------------------+-------------------------------------------------------
 Reporter:  sdz007  |        Owner:  kristian         
     Type:  defect  |       Status:  closed           
 Priority:  normal  |    Milestone:  After Varnish 2.1
Component:  build   |      Version:  2.1.4            
 Severity:  normal  |   Resolution:  fixed            
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 I'm closing this as there's been no response.

 This may or may not be related to a content-length header-issue that was
 fixed in 2.1.5, so before re-opening, please try with Varnish 2.1.5. I am
 assuming 2.1.5 fixed this for lack of feedback.

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/841#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 21 14:25:59 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Feb 2011 14:25:59 -0000
Subject: [Varnish] #837: varnishadm purge.list fails frequently
In-Reply-To: <043.a2d15772321998574922abae75b7be94@varnish-cache.org>
References: <043.a2d15772321998574922abae75b7be94@varnish-cache.org>
Message-ID: <052.b6d4730824191d5e92e23ec47e5e1fb7@varnish-cache.org>

#837: varnishadm purge.list fails frequently
----------------------+-----------------------------------------------------
 Reporter:  jelder    |       Owner:  kristian         
     Type:  defect    |      Status:  assigned         
 Priority:  lowest    |   Milestone:  After Varnish 2.1
Component:  varnishd  |     Version:  trunk            
 Severity:  normal    |    Keywords:  purge.list       
----------------------+-----------------------------------------------------
Changes (by kristian):

  * priority:  normal => lowest


Comment:

 I can confirm that this is still relevant, but the real solution isn't
 considered "make varnish output more" but "make the output intelligent".

 This isn't a huge priority, as the ban lurker and ban_dups should stop you
 from getting 1100 purges to begin with.

 In my test, the tool failed at 1100~ bans, while telnet worked fine a bit
 longer.

 (Consider this a "FYI" - no further update is really needed until we get
 around to solving this)

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/837#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Feb 22 17:52:42 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Feb 2011 17:52:42 -0000
Subject: [Varnish] #863: crash in vcl.discard when using dns director (2.1.5)
Message-ID: <045.da05e9b2e1ea6af44b141e7480fd15f6@varnish-cache.org>

#863: crash in vcl.discard when using dns director (2.1.5)
----------------------+-----------------------------------------------------
 Reporter:  askalski  |        Type:  defect  
   Status:  new       |    Priority:  normal  
Milestone:            |   Component:  varnishd
  Version:            |    Severity:  normal  
 Keywords:            |  
----------------------+-----------------------------------------------------
 (I left the version field blank, because there's no 2.1.5 option yet in
 trac.)

 I encountered a failed assertion when using vcl.discard on a vcl file that
 uses the DNS director.  The following is a log of how to minimally
 reproduce the crash.

 * Start the child using any VCL.  The particular configuration doesn't
 matter.
 * Load/inline a (second) VCL with a dns director, then discard it.  The
 running child will crash on a failed assertion.

 {{{
 $ sudo varnishd -d
 storage_file: filename: ./varnish.NQUX1x size 3547 MB.
 Using old SHMFILE
 Varnish on Linux,2.6.18-194.11.4.el5,x86_64,-sfile,-hcritbit
 200 236
 -----------------------------
 Varnish Cache CLI 1.0
 -----------------------------
 Linux,2.6.18-194.11.4.el5,x86_64,-sfile,-hcritbit

 Type 'help' for command list.
 Type 'quit' to close CLI session.
 Type 'start' to launch worker process.

 vcl.inline cf0 "backend be0 { .host = \"localhost\"; }"
 200 13
 VCL compiled.
 start
 socket(): Address family not supported by protocol
 child (16895) Started
 200 0

 Child (16895) said
 Child (16895) said Child starts
 Child (16895) said managed to mmap 3719565312 bytes of 3719565312
 vcl.inline cf1 "director dir0 dns { }"
 200 13
 VCL compiled.
 vcl.discard cf1
 Child (16895) not responding to CLI, killing it.
 400 29
 CLI communication error (hdr)
 Child (16895) died signal=6
 Child (16895) Panic message: Assert error in VRT_fini_dir(),
 cache_backend_cfg.c line 292:
   Condition((b)->magic == 0x3336351d) not true.
 errno = 9 (Bad file descriptor)
 thread = (cache-main)
 ident = Linux,2.6.18-194.11.4.el5,x86_64,-sfile,-hcritbit,epoll
 Backtrace:
   0x424016: varnishd [0x424016]
   0x40db99: varnishd(VRT_fini_dir+0x69) [0x40db99]
   0x2aab89801af8: ./vcl.OaGbHZXp.so [0x2aab89801af8]
   0x428357: varnishd [0x428357]
   0x3c55c067e0: /usr/lib64/libvarnish.so.1 [0x3c55c067e0]
   0x3c55c06c4b: /usr/lib64/libvarnish.so.1 [0x3c55c06c4b]
   0x3c55c094fd: /usr/lib64/libvarnish.so.1 [0x3c55c094fd]
   0x3c55c05ab2: /usr/lib64/libvarnish.so.1(CLS_Poll+0x192) [0x3c55c05ab2]
   0x414fc1: varnishd(CLI_Run+0x41) [0x414fc1]
   0x4230e3: varnishd(child_main+0xe3) [0x4230e3]


 Child cleanup complete
 socket(): Address family not supported by protocol
 child (16933) Started
 Child (16933) said
 Child (16933) said Child starts
 Child (16933) said managed to mmap 3719565312 bytes of 3719565312
 }}}

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/863>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb 23 11:33:30 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 23 Feb 2011 11:33:30 -0000
Subject: [Varnish] #701: Parameters to limit URI / header sizes
In-Reply-To: <042.493cf661d63924842b246786a8245a7c@varnish-cache.org>
References: <042.493cf661d63924842b246786a8245a7c@varnish-cache.org>
Message-ID: <051.4b1c50ca9905147fd4acb55f6a72f3ee@varnish-cache.org>

#701: Parameters to limit URI / header sizes
------------------------------------------------+---------------------------
 Reporter:  slink                               |        Owner:  phk    
     Type:  enhancement                         |       Status:  closed 
 Priority:  normal                              |    Milestone:         
Component:  varnishd                            |      Version:  trunk  
 Severity:  normal                              |   Resolution:  invalid
 Keywords:  max_hdr_len max_uri_len limit size  |  
------------------------------------------------+---------------------------

Old description:

> There still exist various scenarios where varnish may panic on failed
> assertions when the session workspace gets overflowed. A prominent case
> is extensive header/URI processing involving creation of (multiple)
> copies on the workspace.
> To ensure stable operation, the workspace needs to be sized based on
> maximum values for URI / header sizes.
> Thus, I am proposing to add respective limits.
>
> The attached patch will add two parameters:
>
>  * max_hdr_len to limit the total size for request and response headers
> (as received from backends), excluding the request/status line, but
> including the terminal CRLF
>  * max_uri_len to limit the total size of the request URI as received
> from clients
>
> The latter limit is probably already implied for most installations by
> backend servers' limits, so it seems sensible to make the respective
> check early in the processing chain.
>
> Thanks, Nils

New description:

 There still exist various scenarios where varnish may panic on failed
 assertions when the session workspace gets overflowed. A prominent case is
 extensive header/URI processing involving creation of (multiple) copies on
 the workspace.
 To ensure stable operation, the workspace needs to be sized based on
 maximum values for URI / header sizes.
 Thus, I am proposing to add respective limits.

 The attached patch will add two parameters:

  * max_hdr_len to limit the total size for request and response headers
 (as received from backends), excluding the request/status line, but
 including the terminal CRLF
  * max_uri_len to limit the total size of the request URI as received from
 clients

 The latter limit is probably already implied for most installations by
 backend servers' limits, so it seems sensible to make the respective check
 early in the processing chain.

 Thanks, Nils

--

Comment(by phk):

 I have added some new parameters in
 6edf9c379ed0ff20171c87c056730cf9084949b4 which allows you to tune the size
 of the total req/resp and of any individual header *except* the URI, which
 I will leave to VCL to check.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/701#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Feb 23 20:18:00 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 23 Feb 2011 20:18:00 -0000
Subject: [Varnish] #863: crash in vcl.discard when using dns director
	(2.1.5)
In-Reply-To: <045.da05e9b2e1ea6af44b141e7480fd15f6@varnish-cache.org>
References: <045.da05e9b2e1ea6af44b141e7480fd15f6@varnish-cache.org>
Message-ID: <054.6cad64ae3df71d53bcf9054fefa2509b@varnish-cache.org>

#863: crash in vcl.discard when using dns director (2.1.5)
----------------------+-----------------------------------------------------
 Reporter:  askalski  |        Type:  defect  
   Status:  new       |    Priority:  normal  
Milestone:            |   Component:  varnishd
  Version:            |    Severity:  normal  
 Keywords:            |  
----------------------+-----------------------------------------------------

Comment(by askalski):

 In the generated C code, the director is freed twice:

 {{{
 static void
 VGC_Fini(struct cli *cli)
 {

         VRT_fini_dir(cli, VGCDIR(_default));  // once...
         VRT_fini_dir(cli, VGCDIR(default_1));
         VRT_fini_dir(cli, VGCDIR(default_2));
         VRT_fini_dir(cli, VGCDIR(default_3));
         VRT_fini_dir(cli, VGCDIR(default_4));
         VRT_fini_dir(cli, VGCDIR(_default));  // ...and again
         VRT_re_fini(VGC_re_0);
 }
 }}}

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/863#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Feb 24 08:25:26 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 24 Feb 2011 08:25:26 -0000
Subject: [Varnish] #863: crash in vcl.discard when using dns director
	(2.1.5)
In-Reply-To: <045.da05e9b2e1ea6af44b141e7480fd15f6@varnish-cache.org>
References: <045.da05e9b2e1ea6af44b141e7480fd15f6@varnish-cache.org>
Message-ID: <054.c6295035f79b091923b7357e422c7588@varnish-cache.org>

#863: crash in vcl.discard when using dns director (2.1.5)
-----------------------+----------------------------------------------------
  Reporter:  askalski  |        Type:  defect  
    Status:  closed    |    Priority:  normal  
 Milestone:            |   Component:  varnishd
   Version:            |    Severity:  normal  
Resolution:  fixed     |    Keywords:          
-----------------------+----------------------------------------------------
Changes (by tfheen):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Thanks, fixed in 44f47f0 in trunk.

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/863#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Feb 26 19:19:04 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 26 Feb 2011 19:19:04 -0000
Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors
Message-ID: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>

#864: Varnishlog crashes when searching for 503 errors
---------------------+------------------------------------------------------
 Reporter:  kriller  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  2.1.5    |    Severity:  normal
 Keywords:           |  
---------------------+------------------------------------------------------
 I'm trying to find the cause of some 503 errors I'm observing during a
 load-test.

 Running "varnishlog -r /path/to/logfile -o TxStatus 503" causes varnishlog
 to segfault with the following backtrace:

 Program received signal SIGSEGV, Segmentation fault.
 0x00000000004015cb in h_order (priv=0x0, tag=SLT_SessionOpen, fd=6843503,
 len=0, spec=1, ptr=0x774777 "o") at varnishlog.c:130
 130             if (ob[fd] == NULL) {
 (gdb) bt full
 #0  0x00000000004015cb in h_order (priv=0x0, tag=SLT_SessionOpen,
 fd=6843503, len=0, spec=1, ptr=0x774777 "o") at varnishlog.c:130
         type = 99 'c'
         __func__ = "h_order"
 #1  0x00007ffff77c3e73 in VSL_Dispatch (vd=0x6d4010, func=0x40152f
 <h_order>, priv=0x0) at shmlog.c:383
         i = 1
         u = 6843503
         l = 0
         s = 1
         p = 0x774770 "\006"
         __PRETTY_FUNCTION__ = "VSL_Dispatch"
 #2  0x0000000000401aa1 in do_order (vd=0x6d4010, argc=2,
 argv=0x7fffffffe0f8) at varnishlog.c:227
         i = 32767
         error = 0x0
         erroroffset = 0
 #3  0x0000000000401f25 in main (argc=6, argv=0x7fffffffe0d8) at
 varnishlog.c:391
         c = -1
         a_flag = 0
         D_flag = 0
         o_flag = 1
         u_flag = 0
         n_arg = 0x0
         P_arg = 0x0
         w_arg = 0x0
         pfh = 0x0
         vd = 0x6d4010

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/864>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 12:57:00 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 12:57:00 -0000
Subject: [Varnish] #837: varnishadm purge.list fails frequently
In-Reply-To: <043.a2d15772321998574922abae75b7be94@varnish-cache.org>
References: <043.a2d15772321998574922abae75b7be94@varnish-cache.org>
Message-ID: <052.aa9c1c46cb9f711c8902e3df5034d938@varnish-cache.org>

#837: varnishadm purge.list fails frequently
----------------------+-----------------------------------------------------
 Reporter:  jelder    |       Owner:                   
     Type:  defect    |      Status:  new              
 Priority:  lowest    |   Milestone:  After Varnish 2.1
Component:  varnishd  |     Version:  trunk            
 Severity:  normal    |    Keywords:  purge.list       
----------------------+-----------------------------------------------------
Changes (by kristian):

  * owner:  kristian =>
  * status:  assigned => new


-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/837#comment:6>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 13:12:35 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 13:12:35 -0000
Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors
In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
Message-ID: <053.82982cbd2426d3eb7d013e5ba42ed51b@varnish-cache.org>

#864: Varnishlog crashes when searching for 503 errors
---------------------+------------------------------------------------------
 Reporter:  kriller  |       Owner:  kristian
     Type:  defect   |      Status:  new     
 Priority:  normal   |   Milestone:          
Component:  build    |     Version:  2.1.5   
 Severity:  normal   |    Keywords:          
---------------------+------------------------------------------------------
Changes (by kristian):

  * owner:  => kristian


Comment:

 Are you able to read the log without using a filter and -o? And is the log
 written by varnishlog itself, or are you accessing the raw shmlog
 directly? I'd like to see the actual command-lines(plural), just to be
 sure.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/864#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 13:16:20 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 13:16:20 -0000
Subject: [Varnish] #836: Display bug in varnishstat
In-Reply-To: <043.a9f7b1ffc8082a1c667fa3db7404a740@varnish-cache.org>
References: <043.a9f7b1ffc8082a1c667fa3db7404a740@varnish-cache.org>
Message-ID: <052.c2b04528da43c38015fefecceb199e26@varnish-cache.org>

#836: Display bug in varnishstat
-------------------------+--------------------------------------------------
 Reporter:  jelder       |        Owner:  martin           
     Type:  defect       |       Status:  closed           
 Priority:  normal       |    Milestone:  After Varnish 2.1
Component:  varnishstat  |      Version:  trunk            
 Severity:  normal       |   Resolution:  worksforme       
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by martin):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 I have not been able to reproduce this on my system. If you have more
 detailed steps to trigger this, please reopen the ticket with more
 information.

 Regards,
 Martin Blix Grydeland

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/836#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 13:34:29 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 13:34:29 -0000
Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors
In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
Message-ID: <053.77e42c4da79dccee30d74ac80fda4d52@varnish-cache.org>

#864: Varnishlog crashes when searching for 503 errors
---------------------+------------------------------------------------------
 Reporter:  kriller  |       Owner:  kristian
     Type:  defect   |      Status:  new     
 Priority:  normal   |   Milestone:          
Component:  build    |     Version:  2.1.5   
 Severity:  normal   |    Keywords:          
---------------------+------------------------------------------------------

Comment(by kriller):

 The log is initially written to a file by varnishlog, which is started by
 the debian startup-script (/usr/bin/varnishlog -a -w
 /var/log/varnish/varnish.log -D -P /var/run/varnishlog/varnishlog.pid).

 Using varnishlog without -o and a filter works fine (/usr/bin/varnishlog
 -r /var/log/varnishlog > /dev/null).

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/864#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 13:35:45 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 13:35:45 -0000
Subject: [Varnish] #864: Varnishlog crashes when searching for 503 errors
In-Reply-To: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
References: <044.0f71b58df67113f4c7c4ed801a63bd02@varnish-cache.org>
Message-ID: <053.095e01cc7664be239696f81b73930dff@varnish-cache.org>

#864: Varnishlog crashes when searching for 503 errors
---------------------+------------------------------------------------------
 Reporter:  kriller  |       Owner:  kristian
     Type:  defect   |      Status:  new     
 Priority:  normal   |   Milestone:          
Component:  build    |     Version:  2.1.5   
 Severity:  normal   |    Keywords:          
---------------------+------------------------------------------------------

Comment(by kriller):

 and the last path should of course have been /var/log/varnish/varnish.log
 instead of /var/log/varnishlog

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/864#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 14:04:27 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 14:04:27 -0000
Subject: [Varnish] #821: add netbsd to configure
In-Reply-To: <047.c77783af70cc776a96906333927645e0@varnish-cache.org>
References: <047.c77783af70cc776a96906333927645e0@varnish-cache.org>
Message-ID: <056.ee154a9caf1fe7d2a8fb221998a8c79b@varnish-cache.org>

#821: add netbsd to configure
-------------------------+--------------------------------------------------
  Reporter:  msporleder  |        Type:  enhancement
    Status:  closed      |    Priority:  normal     
 Milestone:              |   Component:  build      
   Version:  trunk       |    Severity:  normal     
Resolution:  fixed       |    Keywords:  netbsd     
-------------------------+--------------------------------------------------
Changes (by Tollef Fog Heen <tfheen@?>):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [e2287d2d8f0ce86ef391384d80283da7011f5e13]) Look for kqueue on NetBSD

 Fixes #821

-- 
Ticket URL: </ticket/821#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 14:08:25 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 14:08:25 -0000
Subject: [Varnish] #821: add netbsd to configure
In-Reply-To: <047.c77783af70cc776a96906333927645e0@varnish-cache.org>
References: <047.c77783af70cc776a96906333927645e0@varnish-cache.org>
Message-ID: <056.bc7ac777e3a3d97731a1424e0020d7c7@varnish-cache.org>

#821: add netbsd to configure
-------------------------+--------------------------------------------------
  Reporter:  msporleder  |        Type:  enhancement
    Status:  closed      |    Priority:  normal     
 Milestone:              |   Component:  build      
   Version:  trunk       |    Severity:  normal     
Resolution:  fixed       |    Keywords:  netbsd     
-------------------------+--------------------------------------------------

Comment(by Tollef Fog Heen <tfheen@?>):

 (In [e2287d2d8f0ce86ef391384d80283da7011f5e13]) Look for kqueue on NetBSD

 Fixes #821

-- 
Ticket URL: </ticket/821#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 14:18:44 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 14:18:44 -0000
Subject: [Varnish] #814: yum installation error "[Errno -1] Header is
	not complete."
In-Reply-To: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org>
References: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org>
Message-ID: <060.20a537fd931b73ebd359fc5e2042ea36@varnish-cache.org>

#814: yum installation error "[Errno -1] Header is not complete."
-----------------------------+----------------------------------------------
  Reporter:  patrick.kaiser  |        Type:  defect   
    Status:  reopened        |    Priority:  normal   
 Milestone:                  |   Component:  packaging
   Version:  trunk           |    Severity:  normal   
Resolution:                  |    Keywords:           
-----------------------------+----------------------------------------------

Comment(by tfheen):

 Are you still able to reproduce this?  I believe we have fixed this in the
 meantime, but verification would be useful.

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/814#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 14:26:04 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 14:26:04 -0000
Subject: [Varnish] #825: varnish.spec dependency 'initscripts' not valid
	for SuSE/SLES
In-Reply-To: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org>
References: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org>
Message-ID: <049.792876a6fc1c16608b16936ca34764a0@varnish-cache.org>

#825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES
--------------------------------+-------------------------------------------
 Reporter:  pom                 |        Type:  defect
   Status:  new                 |    Priority:  normal
Milestone:  After Varnish 2.1   |   Component:  build 
  Version:  2.1.3               |    Severity:  minor 
 Keywords:  rpmbuild SUSE SLES  |  
--------------------------------+-------------------------------------------

Comment(by tfheen):

 What is the package providing the initscripts functionality on SLES?

 It seems like it's the package providing /etc/rc.d/init.d/functions and
 friends on centos at least.

-- 
Ticket URL: <http://www.varnish-cache.org/trac/ticket/825#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Feb 28 15:03:15 2011
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Feb 2011 15:03:15 -0000
Subject: [Varnish] #825: varnish.spec dependency 'initscripts' not valid
	for SuSE/SLES
In-Reply-To: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org>
References: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org>
Message-ID: <049.e38ee6143f650876f370e15c59ac0dca@varnish-cache.org>

#825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES
--------------------------------+-------------------------------------------
 Reporter:  pom                 |        Type:  defect
   Status:  new                 |    Priority:  normal
Milestone:  After Varnish 2.1   |   Component:  build 
  Version:  2.1.3               |    Severity:  minor 
 Keywords:  rpmbuild SUSE SLES  |  
--------------------------------+-------------------------------------------

Comment(by pom):

 Replying to [comment:2 tfheen]:
 > What is the package providing the initscripts functionality on SLES?
 >
 > It seems like it's the package providing /etc/rc.d/init.d/functions and
 friends on centos at least.

 At least what I've done for building and installing packages on
 SLES10(SP3) and SLES11 is a Requires line for "aaa_base". This works fine.
 Of course I had to remove "initscripts" from the spec file.

-- 
Ticket URL: <http://varnish-cache.org/trac/ticket/825#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator