From varnish-bugs at varnish-cache.org Mon Jul 1 09:23:00 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Jul 2013 09:23:00 -0000 Subject: [Varnish] #1323: suffix-byte-range requests larger than the file size don't work Message-ID: <047.84cb6dd391a524ebaf1be3c574302f07@varnish-cache.org> #1323: suffix-byte-range requests larger than the file size don't work ---------------------------+-------------------- Reporter: gquintard | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.4 | Severity: normal Keywords: range request | ---------------------------+-------------------- Varnish prints a Content-Range header starting with a negative number, due to a missing check in do_range (cache_response.c) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 1 10:03:35 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Jul 2013 10:03:35 -0000 Subject: [Varnish] #1322: varnishd master segfault when parsing <=varnish-3 director vcl In-Reply-To: <040.9413d6c1cb10608299178d8543e1f30a@varnish-cache.org> References: <040.9413d6c1cb10608299178d8543e1f30a@varnish-cache.org> Message-ID: <055.ae9849686a83146bc476996e55c658b6@varnish-cache.org> #1322: varnishd master segfault when parsing <=varnish-3 director vcl ---------------------------+-------------------- Reporter: jw | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: vcl, director | ---------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 2 08:34:39 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Jul 2013 08:34:39 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.150cc9f1ce99b699ca37dcbab8ae2029@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by daghf): The problem is actually a bit more general than only applying to redirects. Any response with Content-Encoding: gzip and an empty body will trigger this. I guess it could be argued that the backend shouldn't send c-e: gzip with c-l: 0, but varnish should perhaps handle it more gracefully .. (Test case attached) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jul 2 12:27:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Jul 2013 12:27:22 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.aa2d7a019ec8696f886bf849460554c7@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by daghf): Hans Schou presents a workaround for this in varnish-misc: https://www .varnish-cache.org/lists/pipermail/varnish-misc/2013-July/023178.html Add his VCL snippet to your vcl_fetch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 3 03:55:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Jul 2013 03:55:12 -0000 Subject: [Varnish] #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data In-Reply-To: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> References: <044.dedba8f13c20d02f02a39731a1edea7c@varnish-cache.org> Message-ID: <059.21d859208ed30bbef242fa90938ebbf8@varnish-cache.org> #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data ----------------------+--------------------- Reporter: martin | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+--------------------- Comment (by lgx): 3.0.3 has the same problem. The reason is, VGZ_WrwGunzip dones't process the return code VGZ_END of VGZ_Gunzip. So it will loop forever at this situation. I think the fix would be: if (i < VGZ_OK) { /* XXX: VSL ? */ return (-1); } + else if(i == VGZ_END) + { + break; + } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 4 17:31:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Jul 2013 17:31:12 -0000 Subject: [Varnish] #1324: vdir_pick_by_weight() will fail to pick any backend if weight is equal vd->total_weight Message-ID: <040.e7f16aea9984285613c85cdb24f17942@varnish-cache.org> #1324: vdir_pick_by_weight() will fail to pick any backend if weight is equal vd->total_weight -------------------+-------------------- Reporter: jw | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------- vdir_pick_by_weight() returns WRONG(""); if vdir_pick_be() is caled with w=1.0 as a will never be larger if (w < a) return (u); As assert(w >= 0.0 && w <= 1.0) in vdir_pick_be() indicates, it should be possible to call it with an value of 1.0, thus i assume the correct fix would be: if (w <= a) return (u); -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 5 12:10:06 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Jul 2013 12:10:06 -0000 Subject: [Varnish] #1325: varnishlog -m option stopped working Message-ID: <042.808cb3a68d1dc0263dd42a8e6ecd8a1d@varnish-cache.org> #1325: varnishlog -m option stopped working -------------------+------------------------ Reporter: xani | Type: defect Status: new | Priority: normal Milestone: | Component: varnishlog Version: 3.0.4 | Severity: normal Keywords: | -------------------+------------------------ after upgrade from 3.0.3 to 3.0.4 adding -m option causes varnishlog to not output any log How to reproduce: # varnishlog -m 'TxStatus:.*' does not output anything using 3.0.3 varnishlog binary with 3.0.4 varnish produces correct output -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 5 12:34:09 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Jul 2013 12:34:09 -0000 Subject: [Varnish] #1326: repo.v-c.o is missing source packages Message-ID: <046.cfc4e54dee3b7bd4245082fd6619ba53@varnish-cache.org> #1326: repo.v-c.o is missing source packages -----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 3.0.4 Severity: normal | Keywords: -----------------------+------------------- On Debian wheezy, when using the varnish-cache.org package repository, there is an issue with the source packages: {{{ root at lb1:~# apt-get source varnish Reading package lists... Done Building dependency tree Reading state information... Done E: Ignore unavailable version '3.0.4-1' of package 'varnish' E: Unable to find a source package for varnish }}} This makes it more difficult to build vmods. {{{ root at lb1:~# dpkg -l varnish Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-============================-===================-===================-============================================================= ii varnish 3.0.4-1~wheezy amd64 state of the art, high-performance web accelerator root at lb1:~# root at lb1:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 7.1 (wheezy) Release: 7.1 Codename: wheezy root at lb1:~# grep varnish /etc/apt/sources.list deb http://repo.varnish-cache.org/debian/ wheezy varnish-3.0 deb http://repo.varnish-cache.org/debian/ squeeze varnish-3.0 root at lb1:~# }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jul 10 22:04:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Jul 2013 22:04:24 -0000 Subject: [Varnish] #1327: Crash if http_max_hdr is not multiple of 4 Message-ID: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> #1327: Crash if http_max_hdr is not multiple of 4 -------------------+---------------------- Reporter: Dan42 | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | -------------------+---------------------- Using the ubuntu package of varnishd, I get a full-blown crash if `http_max_hdr` is not a multiple of 4. launching with: {{{ $ echo 'backend fortytwo { .host = "127.0.0.1"; .port = "4242"; }' > 42.vcl $ sudo /usr/sbin/varnishd -F -f 42.vcl -s malloc,500M -a 127.0.0.1:4200 -n ANN -T 127.0.0.1:42001 -p http_max_hdr=255 }}} and getting: {{{ child (10143) Started Pushing vcls failed: CLI communication error (hdr) Stopping Child Child (10143) died signal=6 Child (10143) Panic message: Assert error in WS_Init(), cache_ws.c line 80: Condition(PAOK(space)) not true. thread = (cache-timeout) ident = Linux,3.3.6-030306-generic,x86_64,-smalloc,-smalloc,-hcritbit,no_waiter Backtrace: 0x42f965: /usr/sbin/varnishd() [0x42f965] 0x43ed13: /usr/sbin/varnishd(WS_Init+0x143) [0x43ed13] 0x433739: /usr/sbin/varnishd() [0x433739] 0x433b33: /usr/sbin/varnishd(SES_Alloc+0x23) [0x433b33] 0x4312d8: /usr/sbin/varnishd() [0x4312d8] 0x7f05c5fd1e9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f05c5fd1e9a] 0x7f05c5cfeccd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f05c5cfeccd] Child (-1) said Child starts Child cleanup complete }}} If it really has to be multiples of 4, then at least exit with a saner error message and mention the limitation in the docs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jul 12 12:31:46 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Jul 2013 12:31:46 -0000 Subject: [Varnish] #1328: Varnish stuck in a vcl.load frenzy Message-ID: <042.826222e91149519a795dfec17962c29b@varnish-cache.org> #1328: Varnish stuck in a vcl.load frenzy -------------------+---------------------- Reporter: nuba | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | -------------------+---------------------- Hello there, This has happened a few times already, and it usually happens at about the same time in all three instances I am running this setup: varnish being passed a new vcl to use via varnish-agent every two minutes or so. When it happens, varnish becomes unresponsive, and unable to enter varnishadm. Varnishlog shows a neverending flood of: {{{ 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202357" ./vcl.Hv_KYu88.so 0 CLI - Wr 200 58 Loaded "./vcl.Hv_KYu88.so" as "ip-10-232-70-74_1373202357" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202457" ./vcl.jdny_Rpn.so 0 CLI - Wr 200 58 Loaded "./vcl.jdny_Rpn.so" as "ip-10-232-70-74_1373202457" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202562" ./vcl.la0GFhua.so 0 CLI - Wr 200 58 Loaded "./vcl.la0GFhua.so" as "ip-10-232-70-74_1373202562" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202666" ./vcl.4Duon614.so 0 CLI - Wr 200 58 Loaded "./vcl.4Duon614.so" as "ip-10-232-70-74_1373202666" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202774" ./vcl.1zMXtVdb.so 0 CLI - Wr 200 58 Loaded "./vcl.1zMXtVdb.so" as "ip-10-232-70-74_1373202774" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202875" ./vcl.5PZ5oLqZ.so 0 CLI - Wr 200 58 Loaded "./vcl.5PZ5oLqZ.so" as "ip-10-232-70-74_1373202875" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373202976" ./vcl.vrp9XgjZ.so 0 CLI - Wr 200 58 Loaded "./vcl.vrp9XgjZ.so" as "ip-10-232-70-74_1373202976" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203076" ./vcl.uaMggMif.so 0 CLI - Wr 200 58 Loaded "./vcl.uaMggMif.so" as "ip-10-232-70-74_1373203076" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203176" ./vcl.K29CXnmc.so 0 CLI - Wr 200 58 Loaded "./vcl.K29CXnmc.so" as "ip-10-232-70-74_1373203176" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203282" ./vcl.9KfydVWX.so 0 CLI - Wr 200 58 Loaded "./vcl.9KfydVWX.so" as "ip-10-232-70-74_1373203282" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203388" ./vcl.LIeqzMOq.so 0 CLI - Wr 200 58 Loaded "./vcl.LIeqzMOq.so" as "ip-10-232-70-74_1373203388" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203494" ./vcl.ujTZ4BCO.so 0 CLI - Wr 200 58 Loaded "./vcl.ujTZ4BCO.so" as "ip-10-232-70-74_1373203494" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203597" ./vcl.DJZi5KHF.so 0 CLI - Wr 200 58 Loaded "./vcl.DJZi5KHF.so" as "ip-10-232-70-74_1373203597" 0 CLI - Rd vcl.load "ip-10-232-70-74_1373203696" ./vcl.exCEPgli.so }}} this is on a machine that has this many compiled vcls: {{{ root at ip-10-232-70-74:~# ls -l /var/lib/varnish/ip-10-232-70-74/ | wc -l 20615 }}} If needed, I can "prepare" this setup in a box you could ssh to and debug it up & broken. Or let me know if there's anything else you'd like me to collect. Thanks, Nuba Some extra info, in case it might be useful {{{ Linux ip-10-232-70-74 3.2.0-25-virtual #40-Ubuntu SMP Wed May 23 22:20:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux ubuntu at ip-10-232-70-74:~$ ldd /usr/sbin/varnishd linux-vdso.so.1 => (0x00007fff8d3ff000) libvarnish.so => /usr/lib/varnish/libvarnish.so (0x00007fc8c9955000) libvarnishcompat.so => /usr/lib/varnish/libvarnishcompat.so (0x00007fc8c9753000) libvcl.so => /usr/lib/varnish/libvcl.so (0x00007fc8c9531000) libvgz.so => /usr/lib/varnish/libvgz.so (0x00007fc8c931d000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc8c90d8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc8c8ed3000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc8c8bd7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc8c89ba000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8c85fa000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc8c83f2000) /lib64/ld-linux-x86-64.so.2 (0x00007fc8c9b6b000) ubuntu at ip-10-232-70-74:~$ ldd /usr/lib/varnish/* /usr/lib/varnish/libvarnishcompat.so: linux-vdso.so.1 => (0x00007fff01fff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa765ca0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa7658e1000) /lib64/ld-linux-x86-64.so.2 (0x00007fa7660c9000) /usr/lib/varnish/libvarnish.so: linux-vdso.so.1 => (0x00007fff85736000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdb911c4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdb90ec8000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fdb90c8a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdb90a6d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdb906ae000) /lib64/ld-linux-x86-64.so.2 (0x00007fdb915ea000) /usr/lib/varnish/libvcl.so: linux-vdso.so.1 => (0x00007fff9b1ff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f73942ed000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7393f2e000) /lib64/ld-linux-x86-64.so.2 (0x00007f7394735000) /usr/lib/varnish/libvgz.so: linux-vdso.so.1 => (0x00007fff609ff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb29b2c8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb29af09000) /lib64/ld-linux-x86-64.so.2 (0x00007fb29b703000) /usr/lib/varnish/vmods: ldd: /usr/lib/varnish/vmods: not regular file ubuntu at ip-10-232-70-74:~$ ldd /usr/lib/varnish/*/* /usr/lib/varnish/vmods/libvmod_header.a: not a dynamic executable /usr/lib/varnish/vmods/libvmod_header.la: not a dynamic executable /usr/lib/varnish/vmods/libvmod_header.so: linux-vdso.so.1 => (0x00007fff28bff000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effe782f000) /lib64/ld-linux-x86-64.so.2 (0x00007effe7dfc000) /usr/lib/varnish/vmods/libvmod_std.so: linux-vdso.so.1 => (0x00007fff3b9ff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97a198b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97a15cc000) /lib64/ld-linux-x86-64.so.2 (0x00007f97a1db7000) ubuntu at ip-10-232-70-74:~$ my varnish came from ubuntu at ip-10-232-70-74:~/varnish-3.0.3$ grep varnish /etc/apt/sources.list deb http://repo.varnish-cache.org/ubuntu/ precise varnish-3.0 ubuntu at ip-10-232-70-74:~/varnish-3.0.3$ dpkg -l '*varnish*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============================-==============================-============================================================================ un libvarnish-dev (no description available) un libvarnish1 (no description available) ii libvarnishapi-dev 3.0.3-1~precise development files for Varnish ii libvarnishapi1 3.0.3-1~precise shared libraries for Varnish ii varnish 3.0.3-1~precise state of the art, high-performance web accelerator un varnish-doc (no description available) ubuntu at ip-10-232-70-74:~/varnish-3.0.3$ dpkg -p varnish Package: varnish Priority: optional Section: web Installed-Size: 1276 Maintainer: Varnish Package Maintainers Architecture: amd64 Version: 3.0.3-1~precise Replaces: libvarnishapi1 (<< 3.0.0-5) Depends: libc6 (>= 2.14), libedit2 (>= 2.11-20080614-1), libncurses5 (>= 5.5-5~), libpcre3 (>= 8.10), libtinfo5, libvarnishapi1, gcc (>= 3.3), libc6-dev | libc6.1-dev | libc-dev, adduser Suggests: varnish-doc Size: 534824 Description: state of the art, high-performance web accelerator Varnish Cache is a state of the art web accelerator written with performance and flexibility in mind. . Varnish Cache stores web pages in memory so web servers don't have to create the same web page over and over again. Varnish serves pages much faster than any application server; giving the website a significant speed up. . Some of the features include: * A modern design * VCL - a very flexible configuration language * Load balancing with health checking of backends * Partial support for ESI - Edge Side Includes * URL rewriting * Graceful handling of "dead" backends Homepage: http://varnish-cache.org/ The headers vmod was compiled from source. ubuntu at ip-10-232-70-74:~/varnish-3.0.3$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz stepping : 7 microcode : 0x70d cpu MHz : 1795.673 cache size : 20480 KB physical id : 1 siblings : 2 core id : 0 cpu cores : 1 apicid : 32 initial apicid : 32 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb xsaveopt pln pts dts bogomips : 3591.34 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz stepping : 7 microcode : 0x70d cpu MHz : 1795.673 cache size : 20480 KB physical id : 1 siblings : 2 core id : 0 cpu cores : 1 apicid : 32 initial apicid : 32 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb xsaveopt pln pts dts bogomips : 3591.34 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: ubuntu at ip-10-232-70-74:~/varnish-3.0.3$ free total used free shared buffers cached Mem: 7629480 2077108 5552372 0 80224 1036820 -/+ buffers/cache: 960064 6669416 Swap: 0 0 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 07:59:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 07:59:53 -0000 Subject: [Varnish] #1327: Crash if http_max_hdr is not multiple of 4 In-Reply-To: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> References: <043.582a578349c23acd06cc444ba23f147c@varnish-cache.org> Message-ID: <058.6bb7b5a6363c4676e7644678bde4a417@varnish-cache.org> #1327: Crash if http_max_hdr is not multiple of 4 ----------------------+-------------------- Reporter: Dan42 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): I cannot reproduce this in -trunk, and I belive the fix that makes the difference is in b7620169552e638771676df2f57749657cf12f0b -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 08:26:03 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 08:26:03 -0000 Subject: [Varnish] #1324: vdir_pick_by_weight() will fail to pick any backend if weight is equal vd->total_weight In-Reply-To: <040.e7f16aea9984285613c85cdb24f17942@varnish-cache.org> References: <040.e7f16aea9984285613c85cdb24f17942@varnish-cache.org> Message-ID: <055.f5afabc713dbc649ba01c2f5b4c364a5@varnish-cache.org> #1324: vdir_pick_by_weight() will fail to pick any backend if weight is equal vd->total_weight --------------------+---------------------------------------- Reporter: jw | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [65c8593dc828b0ac6944d3897cf33d64028c6c43]: {{{ #!CommitTicketReference repository="" revision="65c8593dc828b0ac6944d3897cf33d64028c6c43" Fix boundary condition on an assert. Fixes #1324 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 08:38:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 08:38:29 -0000 Subject: [Varnish] #1322: varnishd master segfault when parsing <=varnish-3 director vcl In-Reply-To: <040.9413d6c1cb10608299178d8543e1f30a@varnish-cache.org> References: <040.9413d6c1cb10608299178d8543e1f30a@varnish-cache.org> Message-ID: <055.baf52fde166cdf12f5e34f77057e90f1@varnish-cache.org> #1322: varnishd master segfault when parsing <=varnish-3 director vcl ---------------------------+--------------------- Reporter: jw | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: vcl, director | ---------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [adf3f128e661bd5d7a55edcb30a3b964c18b1a7a]: {{{ #!CommitTicketReference repository="" revision="adf3f128e661bd5d7a55edcb30a3b964c18b1a7a" Report the right token in the error message. Fixes #1322 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 08:44:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 08:44:50 -0000 Subject: [Varnish] #1328: Varnish stuck in a vcl.load frenzy In-Reply-To: <042.826222e91149519a795dfec17962c29b@varnish-cache.org> References: <042.826222e91149519a795dfec17962c29b@varnish-cache.org> Message-ID: <057.25d601d947e527cab73e71f44f20d6b2@varnish-cache.org> #1328: Varnish stuck in a vcl.load frenzy ----------------------+------------------------- Reporter: nuba | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I'm going to close this ticket with an "error 42" conclusion. Varnish allows you to have multiple VCLs loaded so you can switch between them, but having 20000 concurrent VCL's loaded does not make any kind of sense. You should change your setup so you vcl.discard old VCLs, either by pruning the list of loaded VCLs so it's never longer than some N (20 ?) entries, or by having your back-office system keep track and discard old VCL's when the new one is activated. PS: I don't see any vcl.use commands ? Are you sure the VCL's you load gets put into use ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 09:04:07 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 09:04:07 -0000 Subject: [Varnish] #1241: Use Upstart on Ubuntu machines In-Reply-To: <046.f7286b12ea20583b4a4ae804e660c4ba@varnish-cache.org> References: <046.f7286b12ea20583b4a4ae804e660c4ba@varnish-cache.org> Message-ID: <061.8a517adc1025dc976014ea456665d459@varnish-cache.org> #1241: Use Upstart on Ubuntu machines -------------------------+------------------------------ Reporter: silvinci | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => invalid Comment: This is not a bug, this is a featurerequest. Moved to the Wiki: https://www.varnish-cache.org/trac/wiki/Future_Feature -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 09:05:19 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 09:05:19 -0000 Subject: [Varnish] #1076: Unable to ban on object http status In-Reply-To: <041.502fa3a290b14b0e8496aad415d3f2b1@varnish-cache.org> References: <041.502fa3a290b14b0e8496aad415d3f2b1@varnish-cache.org> Message-ID: <056.0706135066251ece13f15b553ee2ccc2@varnish-cache.org> #1076: Unable to ban on object http status ----------------------+--------------------- Reporter: mha | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: This is fixed in 3.0.4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:05:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:05:53 -0000 Subject: [Varnish] #1033: purge; in vcl_pass In-Reply-To: <046.5c6ed7d7ed0c2d768626ff3e3184eaef@varnish-cache.org> References: <046.5c6ed7d7ed0c2d768626ff3e3184eaef@varnish-cache.org> Message-ID: <061.96060e762d0cf0a60beed4f8e8fab00f@varnish-cache.org> #1033: purge; in vcl_pass ----------------------+----------------------- Reporter: kristian | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This is overtaken by events: In VCL4 we have return(purge) in vcl_recv to deal with this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:07:52 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:07:52 -0000 Subject: [Varnish] #1018: Man vcl missing director options In-Reply-To: <043.0ef8568f105acbda1448ea0094a04325@varnish-cache.org> References: <043.0ef8568f105acbda1448ea0094a04325@varnish-cache.org> Message-ID: <058.9cc42e9dda5cc8404e1285198d9ed32e@varnish-cache.org> #1018: Man vcl missing director options ---------------------------+---------------------- Reporter: scoof | Owner: drwilco Type: documentation | Status: closed Priority: lowest | Milestone: Component: documentation | Version: trunk Severity: trivial | Resolution: invalid Keywords: | ---------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This ticket is OBE, directors are now in VMODS -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:08:57 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:08:57 -0000 Subject: [Varnish] #1163: .saintmode_threshold with ESI In-Reply-To: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> References: <045.5eb39dca6fe96b66a032aa3d10aa6903@varnish-cache.org> Message-ID: <060.8bddb850577607861b1ebc360769ff15@varnish-cache.org> #1163: .saintmode_threshold with ESI ----------------------------+------------------------- Reporter: fenidik | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: esi, saintmode | ----------------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: Timeout -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:13:10 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:13:10 -0000 Subject: [Varnish] #1219: degraded speed with persistent storage In-Reply-To: <047.d33cc554f18272c8c3e85a89b7fa6dd4@varnish-cache.org> References: <047.d33cc554f18272c8c3e85a89b7fa6dd4@varnish-cache.org> Message-ID: <062.ba33e5c106a1f0be02443809658e1283@varnish-cache.org> #1219: degraded speed with persistent storage -----------------------+------------------------- Reporter: stavrinov | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | -----------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: timeout -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:17:51 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:17:51 -0000 Subject: [Varnish] #1053: Persistent storage: Catch-all ticket (was: Persistent storage: space leakage) In-Reply-To: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> References: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> Message-ID: <061.2fa2faa70975e00acfb3f389b180fcfe@varnish-cache.org> #1053: Persistent storage: Catch-all ticket ----------------------+--------------------- Reporter: dumbbell | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+--------------------- Comment (by phk): I am turning this ticket into a "catch-all" persistent ticket, and will link other tickets to this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:18:36 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:18:36 -0000 Subject: [Varnish] #1215: cache object stub In-Reply-To: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> References: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> Message-ID: <062.0e95cd154351f85c5d34c0f4eb2e466d@varnish-cache.org> #1215: cache object stub -----------------------+------------------------ Reporter: stavrinov | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: duplicate Keywords: | -----------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Linking this to our catch-all persistent ticket #1053 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:19:46 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:19:46 -0000 Subject: [Varnish] #1052: Persistent storage: less scary message when a silo is freshly created In-Reply-To: <046.a299a393f221b68cf1b4dd30204576e2@varnish-cache.org> References: <046.a299a393f221b68cf1b4dd30204576e2@varnish-cache.org> Message-ID: <061.d97d19c0b5e0b2d99610ec9c888634d3@varnish-cache.org> #1052: Persistent storage: less scary message when a silo is freshly created -------------------------+------------------------ Reporter: dumbbell | Owner: martin Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: trivial | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Linking this to our catch-all persistent ticket #1053 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:20:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:20:18 -0000 Subject: [Varnish] #1264: [PATCH] Add varnishlog -t for plain text logging In-Reply-To: <046.bfc5e2cd040f2bbf6ceddc00f85cfcd3@varnish-cache.org> References: <046.bfc5e2cd040f2bbf6ceddc00f85cfcd3@varnish-cache.org> Message-ID: <061.0dcf1900b652d7e117d4fb0276ae49f0@varnish-cache.org> #1264: [PATCH] Add varnishlog -t for plain text logging -------------------------+-------------------- Reporter: lkundrak | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by lkarsten): Hello, and thanks for contributing to Varnish. The varnishlog API has seen a major rewrite since this was written. I don't think this patch applies any more. On another note, I'm not convinced that we should put this functionality into varnishlog itself. The UNIX way of doing this is to pipe the output to /usr/bin/tee or similar. There has been no interest in it for 5 months, so I'm closing this ticket now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:20:36 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:20:36 -0000 Subject: [Varnish] #1264: [PATCH] Add varnishlog -t for plain text logging In-Reply-To: <046.bfc5e2cd040f2bbf6ceddc00f85cfcd3@varnish-cache.org> References: <046.bfc5e2cd040f2bbf6ceddc00f85cfcd3@varnish-cache.org> Message-ID: <061.6b8f76eef935c794cc2dd38c9743a970@varnish-cache.org> #1264: [PATCH] Add varnishlog -t for plain text logging -------------------------+---------------------- Reporter: lkundrak | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:21:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:21:53 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <058.466c14016f2db1a13fd82e6d553805f9@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+------------------------ Reporter: acdha | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Resolution: duplicate Keywords: | ----------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Link this over to our catch-all persistent ticket: #1053 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:24:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:24:18 -0000 Subject: [Varnish] #1083: Persistent Varnish crashes since using bans and lurker In-Reply-To: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> References: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> Message-ID: <064.08dba93bfa0d175d29f5a4e6950c32f2@varnish-cache.org> #1083: Persistent Varnish crashes since using bans and lurker -------------------------+------------------------ Reporter: rmohrbacher | Owner: martin Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Linking this to our Catch-All persistent ticket #1053 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:49:08 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:49:08 -0000 Subject: [Varnish] #1315: Varnish doesn't respect req.ttl = 0s In-Reply-To: <043.51e28a4bf824b5282ca32638aed81d0a@varnish-cache.org> References: <043.51e28a4bf824b5282ca32638aed81d0a@varnish-cache.org> Message-ID: <058.9488670bd9423289850d831c1adbc208@varnish-cache.org> #1315: Varnish doesn't respect req.ttl = 0s --------------------+-------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): This was discussed during bugwash today. It is not documented anywhere that req.ttl exists. The feature it implements is that this request should not be served any objects that are older than req.ttl. Setting it to 0s might mean hash_always_miss? There is no obvious reason (without looking at the code, or reading the IRC discussion) to why a request should have a TTL. PHK pointed out that VCL4 changes a lot. Should also discuss req.grace and req.keep. Fir Needs more thought, revisit this later on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:24:00 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:24:00 -0000 Subject: [Varnish] #1313: ban obj.size > 10MB seems broken In-Reply-To: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> References: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> Message-ID: <058.876e075a291e084db7133b5d198f8856@varnish-cache.org> #1313: ban obj.size > 10MB seems broken ---------------------------+-------------------- Reporter: perbu | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by scoof): * owner: martin => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:56:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:56:30 -0000 Subject: [Varnish] #1313: ban obj.size > 10MB seems broken In-Reply-To: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> References: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> Message-ID: <058.5e099016176f2ffe6ca001bb83e89c4e@varnish-cache.org> #1313: ban obj.size > 10MB seems broken ---------------------------+--------------------- Reporter: perbu | Owner: scoof Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Changes (by scoof): * status: new => closed * resolution: => fixed Comment: Removed example in [d0c0ee9bebb85cf127aa0203e8a78db0549b9efb]. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:30:41 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:30:41 -0000 Subject: [Varnish] #1257: Varnish restarting it self, large cache. In-Reply-To: <051.4eb1f47d3c10c74deb792ffa3ee19c81@varnish-cache.org> References: <051.4eb1f47d3c10c74deb792ffa3ee19c81@varnish-cache.org> Message-ID: <066.b7ae6d91eb626dd6efd6aa916068e479@varnish-cache.org> #1257: Varnish restarting it self, large cache. ---------------------------+------------------------- Reporter: anders-bazoom | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: major | Resolution: worksforme Keywords: | ---------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I'm timing this ticket out now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 15 10:25:13 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Jul 2013 10:25:13 -0000 Subject: [Varnish] #1053: Persistent storage: Catch-all ticket In-Reply-To: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> References: <046.15b4aca0756757e34fe8cc21c10552fc@varnish-cache.org> Message-ID: <061.4fc419118816686beae1f4cfe0743012@varnish-cache.org> #1053: Persistent storage: Catch-all ticket ----------------------+--------------------- Reporter: dumbbell | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+--------------------- Comment (by phk): See also these tickets, which linked to this "catch-all" ticket: #1215 (partial objects) #1052 (scary message) #1077 (assert) #1083 (ban lurker issue) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jul 18 13:30:01 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Jul 2013 13:30:01 -0000 Subject: [Varnish] #1329: Option to respect X-Forwarded-For header in varnishncsa Message-ID: <046.f6a0609e3c05067c33e5f0c9ce3f579c@varnish-cache.org> #1329: Option to respect X-Forwarded-For header in varnishncsa ----------------------+------------------------- Reporter: mhelmich | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: 3.0.4 | Severity: minor Keywords: | ----------------------+------------------------- While varnishncsa offers a "-f" flag in order to respect a X-Forwarded-For request header, this flag implies a fixed log line format and cannot be used in conjunction with "-F". The attached commit changes the "-f" behaviour causing varnishncsa to use the value from the X-Forwarded-For header (if present) instead of the client IP while allowing a custom log format at the same time. No change to the log line format is required anymore, the forwarded address will be inserted into the %h placeholder. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 22 10:27:43 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Jul 2013 10:27:43 -0000 Subject: [Varnish] #1329: Option to respect X-Forwarded-For header in varnishncsa In-Reply-To: <046.f6a0609e3c05067c33e5f0c9ce3f579c@varnish-cache.org> References: <046.f6a0609e3c05067c33e5f0c9ce3f579c@varnish-cache.org> Message-ID: <061.fff8fc106a5c3fe34ef24d922fc21a3e@varnish-cache.org> #1329: Option to respect X-Forwarded-For header in varnishncsa -------------------------+-------------------- Reporter: mhelmich | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.4 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Comment (by tfheen): I would be more inclined towards removing the -f switch completely, since it's redundant now we have the -F switch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 22 10:29:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Jul 2013 10:29:16 -0000 Subject: [Varnish] #1317: Varnish Crashes intermittenly In-Reply-To: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> References: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> Message-ID: <077.2daa95b2d5b2b2dccbb92f712bb74e45@varnish-cache.org> #1317: Varnish Crashes intermittenly ------------------------------+------------------------------ Reporter: swapnil.borade@? | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: major | Resolution: invalid Keywords: | ------------------------------+------------------------------ Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: No response from submitter, closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 22 12:31:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Jul 2013 12:31:28 -0000 Subject: [Varnish] #1287: Varnish 3.0.3 - segfault in libvarnish.so. In-Reply-To: <044.f166c5ec2ec8ea0bd77090495e866ce4@varnish-cache.org> References: <044.f166c5ec2ec8ea0bd77090495e866ce4@varnish-cache.org> Message-ID: <059.bfc031f930a5561b5f08f2973863aa53@varnish-cache.org> #1287: Varnish 3.0.3 - segfault in libvarnish.so. ------------------------------------+--------------------- Reporter: robroy | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: segfault libvarnish.so | ------------------------------------+--------------------- Comment (by martin): This error is caused by passing an empty string to synthetic as the first part of a string list. This happens because either the file read through std.fileread is non-existant, or the file is too large to fit in the workspace while dealing with the temporary header variable in the vcl_error code. (Note that the synthetic function is able to accept the result from std.fileread directly, making it unnecessary to pass it through a temp header. Using the temp header will also result in a large HTTP header being passed to the client, wasting bandwidth). Patch for this issue has been sent to the dev list awaiting review. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 22 12:24:09 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Jul 2013 12:24:09 -0000 Subject: [Varnish] #1329: Option to respect X-Forwarded-For header in varnishncsa In-Reply-To: <046.f6a0609e3c05067c33e5f0c9ce3f579c@varnish-cache.org> References: <046.f6a0609e3c05067c33e5f0c9ce3f579c@varnish-cache.org> Message-ID: <061.fb3f6d568b733292a1f4ade08fdc1252@varnish-cache.org> #1329: Option to respect X-Forwarded-For header in varnishncsa -------------------------+-------------------- Reporter: mhelmich | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.4 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Comment (by mhelmich): For us the "-f" switch (with the patched behaviour) has proven itself quite useful. In our case, we handle both requests with and without X -Forwarded-For header (and currently I don't see how to handle this with the -F switch alone). Some more background on this:[[BR]] We operate varnish behind a loadbalancing system that operates on an IPv4/IPv6 dual-stack. The internal network is IPv4-only. For native IPv4 requests, the client IP contains the actual IP address; for translated IPv6 request however, varnish sees only the IPv4 address of our loadbalancing system (which -- in this case -- sets the X-Forwarded-For header with the forwarded IPv6 address). One possible (and more general) use case might be, when you are running varnish behind another reverse proxy as SSL terminator. When you have varnish listening on port 80, and an nginx on port 443, you will probably also have both request with and without an X-Forwarded-For header. This allows us to just use the "%h" parameter in the log line format and to have it replaced with the X-Forwarded-For header if present, or the actual client ip otherwise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 22 15:02:55 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Jul 2013 15:02:55 -0000 Subject: [Varnish] #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values Message-ID: <043.aa626a75c4fe2e02d466c0020d05a41b@varnish-cache.org> #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values -------------------+------------------------ Reporter: geoff | Type: defect Status: new | Priority: high Milestone: | Component: varnishlog Version: 3.0.3 | Severity: major Keywords: | -------------------+------------------------ I've set 'component' to 'varnishlog', but it's actually about the logging API. I'm using the VSL_Dispatch callback in two tools to read from the log, and for both of them, it's intermittently called with the argument fd == ((unsigned) -1) and/or spec == 0, although the log entry unquestionably belongs to a client or backend transaction (because the tag is something like TxHeader or RxURL, and the content of the log payload is clearly correct for the tag). As a reminder: fd is the number that appears in the leftmost column of varnishlog, and spec is reflected in varnishlog's 'c'/'b'/'-' column. spec has the value VSL_S_CLIENT or VSL_S_BACKEND for the 'c' or 'b' cases. To reproduce the error, it seems to be enough to let varnishd and a log- reading tool run until one or the other value appears. varnishlog itself frequently shows '-' in the 'c'/'b' column, although it's clearly either a client or backend entry; but varnishlog simply passes over calls in which fd > 65535 (and hence may be suppressing entries when fd is not set correctly). A number of things suggest to me that a memory barrier is lacking, somewhere between writing these two values to the SHM log and reading them, although I haven't been able to prove it by adding one of the V*MB() calls to the code. I've tried forcing core dumps when either of the two uninitialized values are seen in VSL_Dispatch, but then when I read the core dump afterward, the correct values are there. Also, when I use varnishlog -w to save SHM contents to file, the correct values appear in the saved log although the VSL_Dispatch call of another process saw the uninitialized value(s) for the same entries. In both cases, the data in memory is evidently fresh by the time it is written to file, but not when read for the call to VSL_Dispatch. And the problem appears to happen less often when Varnish is under a heavier load. My guess is that under high load, the varnishd process, writing to the SHM log, is consistently further ahead in the log than the VSL reading process, so when the VSL reader "catches up", log contents have had time to become fresh. But when the load is low, the VSL reader accesses a location in the SHM log very soon after it has been written, and thus is more likely to encounter stale data. One of our two tools cannot work correctly unless the fd parameter has a correct value, and it's seeing the uninitialized values on the order of tens of thousands of times a day on a live site (in beta, so that the load is still low). So the impact is fairly severe (not to mention the information that users of varnishlog are presumably not seeing). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 29 08:47:08 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Jul 2013 08:47:08 -0000 Subject: [Varnish] #1326: repo.v-c.o is missing source packages In-Reply-To: <046.cfc4e54dee3b7bd4245082fd6619ba53@varnish-cache.org> References: <046.cfc4e54dee3b7bd4245082fd6619ba53@varnish-cache.org> Message-ID: <061.ef304e8803c656150c5cbfc61a74eb77@varnish-cache.org> #1326: repo.v-c.o is missing source packages -----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 3.0.4 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by lkarsten): This was reported on IRC, and when I tried to verify it my test system was incorrectly configured which lead to this bug. For people finding this bug in the future, please check that your Debian system actually has a deb-src line for the repository in sources.list. :-) Installing the source works fine for me now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 29 08:47:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Jul 2013 08:47:27 -0000 Subject: [Varnish] #1326: repo.v-c.o is missing source packages In-Reply-To: <046.cfc4e54dee3b7bd4245082fd6619ba53@varnish-cache.org> References: <046.cfc4e54dee3b7bd4245082fd6619ba53@varnish-cache.org> Message-ID: <061.e9ee8b47fd7e5dbc396fa3bcfba54f57@varnish-cache.org> #1326: repo.v-c.o is missing source packages -----------------------+---------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 3.0.4 Severity: normal | Resolution: invalid Keywords: | -----------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jul 29 10:07:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Jul 2013 10:07:18 -0000 Subject: [Varnish] #1325: varnishlog -m option stopped working In-Reply-To: <042.808cb3a68d1dc0263dd42a8e6ecd8a1d@varnish-cache.org> References: <042.808cb3a68d1dc0263dd42a8e6ecd8a1d@varnish-cache.org> Message-ID: <057.f76121f7ac1c7fe3b95f429822c45d8b@varnish-cache.org> #1325: varnishlog -m option stopped working ------------------------+-------------------- Reporter: xani | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by scoof): Seems to work if you add -c -- Ticket URL: Varnish The Varnish HTTP Accelerator