From varnish-bugs at varnish-cache.org Fri Aug 2 15:13:11 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Aug 2013 15:13:11 -0000 Subject: [Varnish] #1331: Varnish coredump every day Message-ID: <057.61f245458e4feecbe1e632bca0171ded@varnish-cache.org> #1331: Varnish coredump every day -------------------------+---------------------- Reporter: jinjian.1@? | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.3 | Severity: critical Keywords: coredump | -------------------------+---------------------- we encountered varnish coredump issue everyday in this week. My version is 3.0.3 From var/log/messages: Aug 2 07:50:26 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:36 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:47 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:53 ip-10-36-1-238 stud[10104]: {client} Connection closed (in data) Aug 2 07:50:53 ip-10-36-1-238 stud[10104]: ipaddress :10.36.1.238 accept! Aug 2 07:50:57 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 stud[10104]: {backend} Connection reset by peer Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) died signal=3 (core dumped) Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: child (20041) Started Aug 2 07:51:04 ip-10-36-1-238 varnishd[28776]: Child (20041) said Child starts from coredump: (gdb) bt #0 0x00007fdce4b41054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fdce4b3c388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007fdce4b3c257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000434350 in vsl_get () #4 0x0000000000434508 in VSLR () #5 0x00000000004346d2 in VSL () #6 0x00007fdce66d2d95 in cls_vlu2 (priv=0x7fdce3d42780, av=0x7fd96e85b500) at cli_serve.c:292 #7 0x00007fdce66d347b in cls_vlu (priv=0x7fdce3d42780, p=0x2

0x2 out of bounds>) at cli_serve.c:339 > #8 0x00007fdce66d6e09 in LineUpProcess (l=0x7fdce3d1d730) at vlu.c:154 > #9 0x00007fdce66d3e7d in VCLS_Poll (cs=0x7fdce3d03290, timeout= optimized out>) at cli_serve.c:528 > #10 0x000000000041aa41 in CLI_Run () > #11 0x000000000042ea01 in child_main () > #12 0x000000000044155c in start_child () > #13 0x0000000000441ee8 in MGT_Run () > #14 0x000000000045037f in main () > > Our system is down for almost 1 minute during the recover process. > > The issue is very similar with https://www.varnish- > cache.org/trac/ticket/516 and https://www.varnish- > cache.org/trac/ticket/1054. But i could not find any solution there. Do > anybody could put some lights on it? New description: we encountered varnish coredump issue everyday in this week. My version is 3.0.3 From var/log/messages: {{{ Aug 2 07:50:26 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:36 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:47 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:50:53 ip-10-36-1-238 stud[10104]: {client} Connection closed (in data) Aug 2 07:50:53 ip-10-36-1-238 stud[10104]: ipaddress :10.36.1.238 accept! Aug 2 07:50:57 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 stud[10104]: {backend} Connection reset by peer Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) not responding to CLI, killing it. Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: Child (28777) died signal=3 (core dumped) Aug 2 07:51:02 ip-10-36-1-238 varnishd[28776]: child (20041) Started Aug 2 07:51:04 ip-10-36-1-238 varnishd[28776]: Child (20041) said Child starts }}} from coredump: {{{ (gdb) bt #0 0x00007fdce4b41054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fdce4b3c388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007fdce4b3c257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000434350 in vsl_get () #4 0x0000000000434508 in VSLR () #5 0x00000000004346d2 in VSL () #6 0x00007fdce66d2d95 in cls_vlu2 (priv=0x7fdce3d42780, av=0x7fd96e85b500) at cli_serve.c:292 #7 0x00007fdce66d347b in cls_vlu (priv=0x7fdce3d42780, p=0x2

) at cli_serve.c:339 #8 0x00007fdce66d6e09 in LineUpProcess (l=0x7fdce3d1d730) at vlu.c:154 #9 0x00007fdce66d3e7d in VCLS_Poll (cs=0x7fdce3d03290, timeout=) at cli_serve.c:528 #10 0x000000000041aa41 in CLI_Run () #11 0x000000000042ea01 in child_main () #12 0x000000000044155c in start_child () #13 0x0000000000441ee8 in MGT_Run () #14 0x000000000045037f in main () }}} Our system is down for almost 1 minute during the recover process. The issue is very similar with https://www.varnish- cache.org/trac/ticket/516 and https://www.varnish- cache.org/trac/ticket/1054. But i could not find any solution there. Do anybody could put some lights on it? -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 5 10:16:40 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Aug 2013 10:16:40 -0000 Subject: [Varnish] #1331: Varnish coredump every day In-Reply-To: <057.61f245458e4feecbe1e632bca0171ded@varnish-cache.org> References: <057.61f245458e4feecbe1e632bca0171ded@varnish-cache.org> Message-ID: <072.2b01db0aaf3972537efa5c1eff081550@varnish-cache.org> #1331: Varnish coredump every day -------------------------+--------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: coredump | -------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 5 10:25:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Aug 2013 10:25:29 -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.86b35caf4fe520dba29ddfeaa6355589@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): You can do this with the -F switch alone if you just log what you want in VCL (std.log("IP:"+client.ip) and then use %{VCL_Log:IP} in your format string. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 5 11:13:39 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Aug 2013 11:13:39 -0000 Subject: [Varnish] #1331: Varnish coredump every day In-Reply-To: <057.61f245458e4feecbe1e632bca0171ded@varnish-cache.org> References: <057.61f245458e4feecbe1e632bca0171ded@varnish-cache.org> Message-ID: <072.390033b0825b3cde415bff95821954f1@varnish-cache.org> #1331: Varnish coredump every day -------------------------+------------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: worksforme Keywords: coredump | -------------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: Hi, This looks like your Varnish is suffering under too much IO load, and page-ins take longer than the CLI timeout causing the manager process to SIGQUIT the child. Remedies include: - Reducing disk IO (more RAM / smaller cache set) - Increasing cli_timeout parameter - Putting the Varnish SHM file on tmpfs, to avoid it being paged out. See https://www.varnish-software.com/static/book/Tuning.html and google for more information. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 6 09:56:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Aug 2013 09:56: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.3581ae87879b09c77a1e82f3fd4e80cb@varnish-cache.org> #1325: varnishlog -m option stopped working ------------------------+----------------------------------------- Reporter: xani | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ------------------------+----------------------------------------- Changes (by Tollef Fog Heen ): * owner: => Tollef Fog Heen * status: new => closed * resolution: => fixed Comment: In [412c4f754dd805e06803efa170e5d62afd23dd0d]: {{{ #!CommitTicketReference repository="" revision="412c4f754dd805e06803efa170e5d62afd23dd0d" Emit BackendXID and check c_flag/b_flag properly 07d488cb96c703dd7c0ccf7049448c6291f1f0cf partially broke varnishlog, since libvarnishapi did not properly check if both -c and -b were given. In addition, varnishd did not emit a tag at the start of a backend transaction. Emit BackendXID since that seems appropriate. Fixes #1325 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 6 13:20:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Aug 2013 13:20:47 -0000 Subject: [Varnish] #1332: ENUM in Object member method hides subsequent methods Message-ID: <040.62e2fd5e6f9040f25ea2fd5511a3f4a0@varnish-cache.org> #1332: ENUM in Object member method hides subsequent methods ---------------------------+-------------------- Reporter: jw | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: vmod VCL_ENUM | ---------------------------+-------------------- When an object contains a method that takes an ENUM as arguments, methods after the enums can not be reached in VCL. Consider the following vmod.vcc: {{{ Module etest Object etest() { Method VOID .bar(ENUM { AA, BB, CC, DD }) Method VOID .foo() } }}} foo becomes invisible the the VCL compiler: {{{ backend default { .host = "127.0.0.1"; .port = "80"; } backend b1 { .host = "192.168.100.11"; .port = "8000"; } import etest; sub vcl_init { new et = etest.etest(); } sub vcl_recv { et.foo(); et.bar(AA); set req.backend = b1; } }}} {{{ ./sbin/varnishd -a 127.0.0.1:8080 -d -f ./etc/varnish/default.vcl -C Message from VCC-compiler: Not running as root, no priv-sep Expected an action, 'if', '{' or '}' ('input' Line 19 Pos 9) et.foo(); --------######--- }}} Switching the position of foo and bar in vmod.vcc "solves" the issue, as there is no method after. The reason seems to be, that ENUM ends with \0\0, plus a third \0 for the Method ends appears as \0\0\0 just as the end of the Object definition. const char * const Vmod_etest_Spec[] = { /* Object etest */ "OBJ\0" "etest.etest\0Vmod_etest_Func.etest__init\0VOID\0\0" "struct vmod_etest_etest\0" "etest.etest\0Vmod_etest_Func.etest__fini\0VOID\0\0" "etest.etest.bar\0Vmod_etest_Func.etest_bar\0VOID\0ENUM\0AA\0BB\0CC\0DD\0\0\0" "etest.etest.foo\0Vmod_etest_Func.etest_foo\0VOID\0\0" "\0", /* Functions */ /* Init/Fini */ 0 }; Just for the case you want to reproduce: etest.c {{{ #include #include "vrt.h" #include "cache/cache.h" #include "vcc_if.h" struct vmod_etest_etest { unsigned magic; //needed #define VMOD_ETEST_ETEST_MAGIC 0x9454a5ce }; VCL_VOID __match_proto__(td_etest_etest__init) vmod_etest__init(const struct vrt_ctx *ctx, struct vmod_etest_etest **etestp, const char *vcl_name) { struct vmod_etest_etest *etest; CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); AN(etestp); AZ(*etestp); ALLOC_OBJ(etest, VMOD_ETEST_ETEST_MAGIC); AN(etest); *etestp = etest; } VCL_VOID __match_proto__(td_etest_etest__fini) vmod_etest__fini(struct vmod_etest_etest **etestp) { struct vmod_etest_etest *etest; etest = *etestp; *etestp = NULL; CHECK_OBJ_NOTNULL(etest, VMOD_ETEST_ETEST_MAGIC); FREE_OBJ(etest); } VCL_VOID __match_proto__(td_etest_etest_foo) vmod_etest_foo(const struct vrt_ctx *ctx, struct vmod_etest_etest *etest) { CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); CHECK_OBJ_NOTNULL(etest, VMOD_ETEST_ETEST_MAGIC); txt t; char *msg = "DEBUG etest.foo()"; t.b = msg; t.e = msg + strlen(msg); VSLbt(ctx->vsl, SLT_Debug, t); } VCL_VOID __match_proto__(td_etest_etest_bar) vmod_etest_bar(const struct vrt_ctx *ctx, struct vmod_etest_etest *etest, VCL_ENUM e) { CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); CHECK_OBJ_NOTNULL(etest, VMOD_ETEST_ETEST_MAGIC); txt t; char *msg = "DEBUG etest.bar()"; t.b = msg; t.e = msg + strlen(msg); VSLbt(ctx->vsl, SLT_Debug, t); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From lubing at beisen.com Thu Aug 1 08:09:29 2013 From: lubing at beisen.com (=?gb2312?B?wqyx+A==?=) Date: Thu, 1 Aug 2013 16:09:29 +0800 Subject: =?gb2312?B?tPC4tDogdmFybmlzaC1idWdzIERpZ2VzdCwgVm9sIDgyLCBJc3N1ZSAxNQ==?= In-Reply-To: References: Message-ID: <001e01ce8e8e$7294fcf0$57bef6d0$@com> [root at test-lighttp bin]# /usr/local/varnish-3.0.2/bin/varnishncsa -F "%{X-Forwarded-For}i %h %l %u %D %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" The following error occurred? Unknown format starting at: %D %t "%r" %s %b "%{Referer}i" "%{User-agent}i" From varnish-bugs at varnish-cache.org Mon Aug 12 10:26:34 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Aug 2013 10:26:34 -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.8fae8df8f8c3c4b11c36fa251e8576c9@varnish-cache.org> #1287: Varnish 3.0.3 - segfault in libvarnish.so. ------------------------------------+--------------------- Reporter: robroy | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: segfault libvarnish.so | ------------------------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [7ec9d11ee2e9d8f8e3084e6a0e95b9b97c10a93a]: {{{ #!CommitTicketReference repository="" revision="7ec9d11ee2e9d8f8e3084e6a0e95b9b97c10a93a" Fix seg fault in VRT_synth_page when the string list has a NULL pointer as the first element. Fixes: #1287 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 12 10:29:48 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Aug 2013 10:29:48 -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.6e85fd60269563ddfd0c95a3c023bed0@varnish-cache.org> #1287: Varnish 3.0.3 - segfault in libvarnish.so. ------------------------------------+--------------------- Reporter: robroy | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: segfault libvarnish.so | ------------------------------------+--------------------- Comment (by Martin Blix Grydeland ): In [88d785b3a963105dd76c49ba2e4303afabc5e1db]: {{{ #!CommitTicketReference repository="" revision="88d785b3a963105dd76c49ba2e4303afabc5e1db" Fix seg fault in VRT_synth_page when the string list has a NULL pointer as the first element. Fixes: #1287 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 13 08:38:01 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Aug 2013 08:38:01 -0000 Subject: [Varnish] #1332: ENUM in Object member method hides subsequent methods In-Reply-To: <040.62e2fd5e6f9040f25ea2fd5511a3f4a0@varnish-cache.org> References: <040.62e2fd5e6f9040f25ea2fd5511a3f4a0@varnish-cache.org> Message-ID: <055.5aa4ad3f4800d2be2a712edadd8ce5eb@varnish-cache.org> #1332: ENUM in Object member method hides subsequent methods ---------------------------+----------------------------------------------- Reporter: jw | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: vmod VCL_ENUM | ---------------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [df22bd225a437abdd4e9742f8593a81128852407]: {{{ #!CommitTicketReference repository="" revision="df22bd225a437abdd4e9742f8593a81128852407" Add special parsing of ENUM in vmod object method argument spec The missing handler would end the object spec prematurily, hiding the rest of the methods. Fixes: #1332 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 19 10:04:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Aug 2013 10:04:32 -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.995000ec683d472692802d845596f850@varnish-cache.org> #1329: Option to respect X-Forwarded-For header in varnishncsa -------------------------+---------------------- Reporter: mhelmich | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.4 Severity: minor | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 19 15:07:36 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Aug 2013 15:07:36 -0000 Subject: [Varnish] #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values In-Reply-To: <043.aa626a75c4fe2e02d466c0020d05a41b@varnish-cache.org> References: <043.aa626a75c4fe2e02d466c0020d05a41b@varnish-cache.org> Message-ID: <058.97cc5a2c305942e99e0d758c6423be67@varnish-cache.org> #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values ------------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: high | Milestone: Component: varnishlog | Version: 3.0.3 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Comment (by geoff): In IRC we mentioned the possibility that the compiler may be interfering, maybe an inappropriate optimization. So here's how I build. First of all, my own environment, where I build to develop: {{{ $ uname -a Linux gsimmons 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.46-1~bpo60+1 x86_64 GNU/Linux $ gcc --version gcc (Debian 4.4.5-8) 4.4.5 $ ./configure --enable-developer-warnings --enable-debugging-symbols --enable-extra-developer-warnings --enable-werror --enable-diagnostics CFLAGS=-m64 }}} For deployments on our test and live environments, we build RPMs on Redhat. The main difference in the configure step is just that it sets fewer debugging flags, and sets some paths (install prefix, runtime lib path etc.) to non-standard locations (masked here): {{{ $ uname -a Linux jenkins-dev-b03507 2.6.32-279.14.1.el6.x86_64 #1 SMP Mon Oct 15 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) $ CFLAGS=-m64 LDFLAGS=-Wl,-rpath=$XXXX_VARNISH_PREFIX/lib/varnish:$XXXX_VARNISH_PREFIX/lib ./configure --prefix=$XXXX_VARNISH_PREFIX --enable-debugging-symbols --enable-tests }}} So the compilation call for one of the C sources looks like this: {{{ gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib/libvgz -I../../include -DVARNISH_STATE_DIR='"/var/opt /varnish-xxxxx/var/varnish"' -DVARNISH_VMOD_DIR='"/var/opt/varnish- xxxx/lib/varnish/vmods"' -DVARNISH_VCL_DIR='"/var/opt/varnish- xxxx/etc/varnish"' -m64 -pthread -O0 -g -fno-inline -Wextra -Wno-missing- field-initializers -Wno-sign-compare -MT varnishd-vsm.o -MD -MP -MF .deps /varnishd-vsm.Tpo -c -o varnishd-vsm.o `test -f 'vsm.c' || echo './'`vsm.c mv -f .deps/varnishd-vsm.Tpo .deps/varnishd-vsm.Po }}} It sets {{{-O0}}}, which probably doesn't cause any troublesome optimizations. But I don't know what all those {{-M}} flags do, maybe one of them is the source of the trouble. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 21 08:55:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 21 Aug 2013 08:55:28 -0000 Subject: [Varnish] #1272: duplicate Content-Length headers with pass and stream In-Reply-To: <045.e87497923f5222571a8b67f55be7787e@varnish-cache.org> References: <045.e87497923f5222571a8b67f55be7787e@varnish-cache.org> Message-ID: <060.a7433ddd87f6a8b8cf7da68ec661280a@varnish-cache.org> #1272: duplicate Content-Length headers with pass and stream -----------------------------------+--------------------- Reporter: ehocdet | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: stream Content-Length | -----------------------------------+--------------------- Comment (by pada): This bug also occurs with version 3.0.4 and produces duplicate Content- Length headers, conflicting with http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Patch https://www.varnish- cache.org/trac/attachment/ticket/1272/1272.2.patch fixed it for us. Please integrate into upstream. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Aug 26 10:15:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 26 Aug 2013 10:15:28 -0000 Subject: [Varnish] #1272: duplicate Content-Length headers with pass and stream In-Reply-To: <045.e87497923f5222571a8b67f55be7787e@varnish-cache.org> References: <045.e87497923f5222571a8b67f55be7787e@varnish-cache.org> Message-ID: <060.d1f9672130f616c4ae23bf6fa8a485ce@varnish-cache.org> #1272: duplicate Content-Length headers with pass and stream -----------------------------------+--------------------- Reporter: ehocdet | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: stream Content-Length | -----------------------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [0a7e6caa0c6bd93003d4733e96f5ea054ac84cbc]: {{{ #!CommitTicketReference repository="" revision="0a7e6caa0c6bd93003d4733e96f5ea054ac84cbc" Fix duplicate Content-Length headers with pass and stream Fixes: #1272 Patch by: ehocdet }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From yabuki at sraoss.co.jp Tue Aug 13 04:52:30 2013 From: yabuki at sraoss.co.jp (YABUKI Youichi) Date: Tue, 13 Aug 2013 13:52:30 +0900 Subject: varnish 2.1.5 assert error in http_SetH() Message-ID: <201308130452.NAA08394@osspc4.sra.co.jp> My customers varnish 2.1.5 aborted with Assert error in http_SetH(). The related logs in /var/log/messages are as follow. This problem seems like #726. https://www.varnish-cache.org/lists/pipermail/varnish-bugs/2010-June/002888.html The page says this is fixed in trunk, but I cannot find the fix for 2.1.5. Is my fix bellow OK? /var/log/messages: ----------------------------------------------------------------------------- Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child (4898) died signal=6 Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child (4898) Panic message: Assert error in http_SetH(), cache_http.c line 656: Condition((fm) != 0) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-sfile,-hclassic,epoll Backtrace: 0x42bad9: pan_backtrace+16 0x42bd42: pan_ic+164 0x427006: http_SetH+81 0x4352ac: VRT_l_obj_status+d8 0x2acd5b411ce5: _end+2acd5ad8547d 0x2acd5b414cac: _end+2acd5ad88444 0x4328cf: VCL_error_method+6a 0x4150eb: cnt_error+2fa 0x418558: CNT_Session+5e1 0x42d7e9: wrk_do_cnt_sess+12a sp = 0x2acd57f02008 { fd = 20, id = 20, xid = 4240864234, client = XX.XX.XX.XX 46773, step = STP_ERROR, handling = deliver, err_code = 854, err_reason = redirection, restarts = 0, esis = 0 ws = 0x2acd57f02080 { id = "sess", {s,f,r,e} = {0x2acd57f02cd8,+1464,(nil),+131072}, }, http[req] = { ws = 0x2acd57f02080[sess] "GET", "/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X! XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child cleanup complete Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: child (2652) Started Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child (2652) said Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child (2652) said Child starts Jul 25 06:12:22 XXXXXXXXXX varnishd[4883]: Child (2652) said managed to mmap 107374182400 bytes of 107374182400 ----------------------------------------------------------------------------- patch: ----------------------------------------------------------------------------- --- cache_vrt.c.org 2013-08-07 13:00:12.000000000 +0900 +++ cache_vrt.c 2013-08-08 10:36:24.000000000 +0900 @@ -275,12 +275,13 @@ VRT_l_obj_status(const struct sess *sp, assert(num >= 100 && num <= 999); p = WS_Alloc(sp->obj->http->ws, 4); - if (p == NULL) + if (p == NULL) { WSP(sp, SLT_LostHeader, "%s", "obj.status"); - else + } else { sprintf(p, "%d", num); - http_SetH(sp->obj->http, HTTP_HDR_STATUS, p); - sp->obj->http->status = num; + http_SetH(sp->obj->http, HTTP_HDR_STATUS, p); + sp->obj->http->status = num; + } } /* Add an objecthead to the saintmode list for the (hopefully) relevant @@ -356,12 +357,13 @@ VRT_l_resp_status(const struct sess *sp, assert(num >= 100 && num <= 999); p = WS_Alloc(sp->wrk->ws, 4); - if (p == NULL) + if (p == NULL) { WSP(sp, SLT_LostHeader, "%s", "resp.status"); - else + } else { sprintf(p, "%d", num); - http_SetH(sp->wrk->resp, HTTP_HDR_STATUS, p); - sp->wrk->resp->status = num; + http_SetH(sp->wrk->resp, HTTP_HDR_STATUS, p); + sp->wrk->resp->status = num; + } } int @@ -461,12 +463,13 @@ VRT_l_beresp_status(const struct sess *s assert(num >= 100 && num <= 999); p = WS_Alloc(sp->wrk->beresp->ws, 4); - if (p == NULL) + if (p == NULL) { WSP(sp, SLT_LostHeader, "%s", "obj.status"); - else + } else { sprintf(p, "%d", num); - http_SetH(sp->wrk->beresp, HTTP_HDR_STATUS, p); - sp->wrk->beresp->status = num; + http_SetH(sp->wrk->beresp, HTTP_HDR_STATUS, p); + sp->wrk->beresp->status = num; + } } int ----------------------------------------------------------------------------- yabuki at sraoss.co.jp SRA OSS,Inc.Japan From Tim.Harrison2 at bbc.co.uk Thu Aug 22 18:10:52 2013 From: Tim.Harrison2 at bbc.co.uk (Tim Harrison) Date: Thu, 22 Aug 2013 18:10:52 +0000 Subject: DNS Director with hostname resolving to multiple IPs Message-ID: Hi, The Varnish Reference Manual suggests that the DNS director can be used with a hostname that resolves to multiple IP addresses, ?DNS round robin balancing is supported. If a hostname resolves to multiple backends, the director will divide the traffic between all of them in a round-robin manner.? And I believe the following is the correct VCL to implement this, director test dns { { .backend = { .host = "hostname.with.multiple.ips"; } } .ttl = 10s; } However, on compilation Varnish complains, Backend host "hostname.with.multiple.ips": resolves to multiple IPv4 addresses. Only one address is allowed. Please specify which exact address you want to use, we found these: xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx Having looked at the source code in vcc_dir_dns.c and vcc_backend.c, it seems that the hostname associated with a .host object can never resolve to more than one IP address, so it?s not clear how the functionality described in the Reference Manual can be achieved. I think this may be a bug, can you help please? Many thanks, Tim Harrison ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Tue Aug 27 20:00:57 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Aug 2013 20:00:57 -0000 Subject: [Varnish] #1333: ESI include parsing HTTPS urls as relative not absolute Message-ID: <045.6b8080c61995515ca77fff449e5494d0@varnish-cache.org> #1333: ESI include parsing HTTPS urls as relative not absolute ---------------------+---------------------- Reporter: rabbitt | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: unknown | Severity: normal Keywords: | ---------------------+---------------------- If your your esi:include src contains an https:// url, it is considered by varnish to be a relative URI instead of a fully qualifed URL. This causes requests to a page like: https://somehost.com/foo/bar that returns an esi:include src of something like: https://somehost.com/baz to send a backend request (TxURL) of: /foo/https://somehost.com/baz A patch (in the form of a pull request) can be found here: https://github.com/varnish/Varnish-Cache/pull/32 Thanks!, -- Carl P. Corliss -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Aug 27 20:50:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Aug 2013 20:50:24 -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.194069257aa5b757de21e36e459f8fe1@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 nnewton): I don't have much to add here, but wanted to note that I've also recently hit this with a cluster of 3 varnish 3.0.3 servers. It was pretty much identical to the above situations: * Varnish would run for about an hour and then one thread would take 100% of a single core, if you left it eventually another thread would as well. * If you pull the stack of these threads they are clearly looping through the gunzip process. * These events happened around incomplete transfers from the backend it would seem. * They were all on ESI-ed paths, thus forcing varnish to attempt to gunzip the object from the backend. We resolved the issue be editing the VCL to request un-gzipped objects from the backend on ESI-ed paths. This has solved the issue for us. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Aug 28 15:34:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 28 Aug 2013 15:34:22 -0000 Subject: [Varnish] #1334: DNS Director with hostname resolving to multiple IPs is not possible Message-ID: <043.991b3b2d7f57c8dd72a70935f5412ba5@varnish-cache.org> #1334: DNS Director with hostname resolving to multiple IPs is not possible --------------------------------+-------------------- Reporter: timrh | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: dns director .host | --------------------------------+-------------------- The [https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns- director Varnish Reference Manual] suggests that the DNS director can be used with a hostname that resolves to multiple IP addresses, DNS round robin balancing is supported. If a hostname resolves to multiple backends, the director will divide the traffic between all of them in a round-robin manner. And I believe the following is the correct VCL to implement this, {{{ director test dns { { .backend = { .host = "hostname.with.multiple.ips"; } } .ttl = 10s; } }}} However, on compilation Varnish complains, {{{ Backend host "hostname.with.multiple.ips": resolves to multiple IPv4 addresses. Only one address is allowed. Please specify which exact address you want to use, we found these: xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx }}} Having looked at the source code in {{{vcc_dir_dns.c}}} and {{{vcc_backend.c}}}, it seems that the hostname associated with a {{{.host}}} object can never resolve to more than one IP address, so it?s not clear how the functionality described in the Reference Manual can be achieved. -- Ticket URL: Varnish The Varnish HTTP Accelerator From jonathan.huot at thomsonreuters.com Tue Aug 27 13:39:50 2013 From: jonathan.huot at thomsonreuters.com (jonathan.huot at thomsonreuters.com) Date: Tue, 27 Aug 2013 13:39:50 -0000 Subject: DNS Director with hostname resolving to multiple IPs In-Reply-To: References: Message-ID: <8E656B642592B942AE317E2AFAE0ABA149F62243@UK2P-ERFMMBX10.ERF.thomson.com> Have you tried with a correct example of DNS director ? e.g. from The Varnish Reference Manual : director directorname dns { .list = { .host_header = "www.example.com"; .port = "80"; .connect_timeout = 0.4s; "192.168.15.0"/24; "192.168.16.128"/25; } .ttl = 5m; .suffix = "internal.example.net"; } Varnish need to know in advance the range of IPs, else, it will not be working. I think latest version of Varnish will improve this kind of ability by implementing lazy backend creation. But I?m not sure if it?s stable enough to be used. Jonathan Huot Phone: +33(0)1.47.62.78.65 From: varnish-bugs-bounces+jonathan.huot=thomsonreuters.com at varnish-cache.org [mailto:varnish-bugs-bounces+jonathan.huot=thomsonreuters.com at varnish-cache.org] On Behalf Of Tim Harrison Sent: Thursday, 22 August 2013 08:11 PM To: varnish-bugs at varnish-cache.org Subject: DNS Director with hostname resolving to multiple IPs Hi, The Varnish Reference Manual suggests that the DNS director can be used with a hostname that resolves to multiple IP addresses, ?DNS round robin balancing is supported. If a hostname resolves to multiple backends, the director will divide the traffic between all of them in a round-robin manner.? And I believe the following is the correct VCL to implement this, director test dns { { .backend = { .host = "hostname.with.multiple.ips"; } } .ttl = 10s; } However, on compilation Varnish complains, Backend host "hostname.with.multiple.ips": resolves to multiple IPv4 addresses. Only one address is allowed. Please specify which exact address you want to use, we found these: xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx Having looked at the source code in vcc_dir_dns.c and vcc_backend.c, it seems that the hostname associated with a .host object can never resolve to more than one IP address, so it?s not clear how the functionality described in the Reference Manual can be achieved. I think this may be a bug, can you help please? Many thanks, Tim Harrison ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -------------- next part -------------- An HTML attachment was scrubbed... URL: