From varnish-bugs at projects.linpro.no Tue Oct 6 19:48:00 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 06 Oct 2009 19:48:00 -0000 Subject: [Varnish] #564: Varnish crash with -s persistent Message-ID: <052.331a803e2e21bbe48b75b59e9ef0db48@projects.linpro.no> #564: Varnish crash with -s persistent ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am running Varnish trunk/4277 in FreeBSD/amd64 7.2-RELEASE with: {{{ -s persistent,/data00/varnishd.dat,20g -s persistent,/data01/varnishd.dat,20g -s persistent,/data02/varnishd.dat,20g }}} After I while I got a crash: Oct 6 21:17:51 cache11 kernel: pid 76878 (varnishd), uid 0: exited on signal 11 (core dumped) Backtrace: {{{ (gdb) bt #0 0x000000080089bd8f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:324 #1 0x00000008008a222f in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:65 #2 0x0000000000421675 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000421a27 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:327 #4 0x0000000000417f95 in EXP_Inject (oc=0x17515431d0, lru=0x0, ttl=1254878199.6581018) at cache_expire.c:104 #5 0x000000000043b38c in smp_load_seg (sp=0x17104fb008, sc=0x801037000, sg=0x170bba9c50) at storage_persistent.c:901 #6 0x000000000043b44b in smp_thread (sp=0x17104fb008, priv=Variable "priv" is not available. ) at storage_persistent.c:1183 #7 0x00000000004235a7 in wrk_bgthread (arg=Variable "arg" is not available. ) at cache_pool.c:534 #8 0x0000000800ac34d1 in pthread_getprio () from /lib/libthr.so.3 #9 0x0000000000000000 in ?? () Cannot access memory at address 0x7ffffc7e5000 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 8 11:44:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 08 Oct 2009 11:44:19 -0000 Subject: [Varnish] #514: varnishtop not printing values in once mode In-Reply-To: <051.8d7aaa65ab9b51b57f19db6c93f05345@projects.linpro.no> References: <051.8d7aaa65ab9b51b57f19db6c93f05345@projects.linpro.no> Message-ID: <060.2f69a5667798df75ce90a9d94330f63e@projects.linpro.no> #514: varnishtop not printing values in once mode ------------------------+--------------------------------------------------- Reporter: ericp | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Comment (by tfheen): (In [4292]) Merge r4130: Fix once mode in varnishtop -1 mode in varnishtop was broken with the variable length shmlog fields. Fix this. Fixes #514 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 8 12:26:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 08 Oct 2009 12:26:19 -0000 Subject: [Varnish] #529: Not RFC compliant - headers wiped on 304 In-Reply-To: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> References: <049.73ebfecf6239ef0185bff1af30d0a824@projects.linpro.no> Message-ID: <058.76b2f62675109b3f8336c7ea4661a3c8@projects.linpro.no> #529: Not RFC compliant - headers wiped on 304 --------------------+------------------------------------------------------- Reporter: are | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [4295]) Merge r4150: Emit more headers when hitting 304 When hitting 304, ETag, Content-Location, Expires, Cache-control and Vary should all be sent to the client. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 for some more details Thanks to Rog?\195?\169rio Schneider for the patch. Fixes #529 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 8 12:47:17 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 08 Oct 2009 12:47:17 -0000 Subject: [Varnish] #531: Varnish fails to compile on AIX 4.3 (Patch included) In-Reply-To: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> References: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> Message-ID: <060.1565f3dbecb2e81082ca28eff3ef100f@projects.linpro.no> #531: Varnish fails to compile on AIX 4.3 (Patch included) --------------------+------------------------------------------------------- Reporter: demik | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [4296]) Merge r4151: Add #ifdef for WCOREDUMP AIX doesn't have WCOREDUMP, so compilation failed there. Add #ifdef. Partially addresses #531. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 8 12:57:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 08 Oct 2009 12:57:05 -0000 Subject: [Varnish] #531: Varnish fails to compile on AIX 4.3 (Patch included) In-Reply-To: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> References: <051.bbb0edd4cbacc2244f86572b86c39bbb@projects.linpro.no> Message-ID: <060.ed4dc18707d42be4a876e1bd96a5fb4e@projects.linpro.no> #531: Varnish fails to compile on AIX 4.3 (Patch included) --------------------+------------------------------------------------------- Reporter: demik | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by tfheen): (In [4297]) Merge r4152: Rename struct thread to struct replay_thread in varnishreplay AIX has a "struct thread" in pthread.h, which conflicts with our struct thread. Rename ours to replay_thread. Fixes #531 Thanks to demik for patch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 8 15:19:35 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 08 Oct 2009 15:19:35 -0000 Subject: [Varnish] #549: Crash on vertical tab In-Reply-To: <054.ecb7af4b265bc425dab802eeb6c3209f@projects.linpro.no> References: <054.ecb7af4b265bc425dab802eeb6c3209f@projects.linpro.no> Message-ID: <063.d7e99bc284c1db480f50751cec004ecc@projects.linpro.no> #549: Crash on vertical tab ----------------------+----------------------------------------------------- Reporter: kristian | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [4314]) Merge r4221: Be much more paranoid about control-characters in backend responses. Fixes #549 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 05:38:52 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 05:38:52 -0000 Subject: [Varnish] #369: Enable serving of graced objects if backend is down In-Reply-To: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> References: <051.733d2435622e06abe187e3ae2e40534c@projects.linpro.no> Message-ID: <060.a67efc3fc8a596176103615ada390064@projects.linpro.no> #369: Enable serving of graced objects if backend is down -------------------------+-------------------------------------------------- Reporter: perbu | Owner: kristian Type: enhancement | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by donarae): Replying to [ticket:369 perbu]: > We would like to be able to serve graced objects if the backend health polling says the backend is down. > > Its not clear to me whether this should happen automatically or if it should be done explicitly in vcl ( if !req.backend.healthy { lookup;} ). > > It seems to be a minor job enabling this (from my limited understanding of the code) but it would be a huge enhancement for varnish. > > Per. > -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 09:05:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 09:05:13 -0000 Subject: [Varnish] #561: Restarting 400 Bad request causes an assert error In-Reply-To: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no> References: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no> Message-ID: <060.e0600bb55e164a65c8c31266761974e1@projects.linpro.no> #561: Restarting 400 Bad request causes an assert error ----------------------+----------------------------------------------------- Reporter: mikko | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [4325]) Merge r4263: Reject garbled requests If we cannot even make sense of the request, don't bother with attempting a reply. Fixes #561 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 09:58:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 09:58:26 -0000 Subject: [Varnish] #565: "git: command not found" messages during build w/o git Message-ID: <054.e28380fac8537d4cb2ade04e899e3854@projects.linpro.no> #565: "git: command not found" messages during build w/o git ----------------------+----------------------------------------------------- Reporter: kristian | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- This might be specific to FreeBSD, I can probably dig up more details, but the automated builds throw pretty much everything away unless I tell them not to. Currently getting the error three times during build. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 14:21:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 14:21:43 -0000 Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering In-Reply-To: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no> References: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no> Message-ID: <058.e5ebca1a08b79e7789560f9f7712c56e@projects.linpro.no> #554: Backend Poll uses User-Agent for filtering -------------------------+-------------------------------------------------- Reporter: mbm | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: I'm closing this since you can do the same thing using the .request parameter. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 14:29:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 14:29:51 -0000 Subject: [Varnish] #557: varnishd manpage error: http_workspace should be sess_workspace In-Reply-To: <053.ef88de8a6e6ff2875794b9980639c361@projects.linpro.no> References: <053.ef88de8a6e6ff2875794b9980639c361@projects.linpro.no> Message-ID: <062.33c1235a0a5f9ee1899ebaf82d61e6fb@projects.linpro.no> #557: varnishd manpage error: http_workspace should be sess_workspace ----------------------------------------------+----------------------------- Reporter: vudumen | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 2.0 Severity: major | Resolution: fixed Keywords: varnishd man http sess workspace | ----------------------------------------------+----------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4329]) s/http_workspace/sess_workspace/ Fixes #557 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 15:27:29 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 15:27:29 -0000 Subject: [Varnish] #562: configure check for xsltproc missing In-Reply-To: <049.267c79551805c07298a5454a91ab951f@projects.linpro.no> References: <049.267c79551805c07298a5454a91ab951f@projects.linpro.no> Message-ID: <058.eb48aba95540d16b529fdc69a132a7ec@projects.linpro.no> #562: configure check for xsltproc missing --------------------+------------------------------------------------------- Reporter: phk | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r4330. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 15:37:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 15:37:44 -0000 Subject: [Varnish] #384: RPM .spec is missing gcc dependency In-Reply-To: <051.73361bd7c4175565a4bb27c53641b091@projects.linpro.no> References: <051.73361bd7c4175565a4bb27c53641b091@projects.linpro.no> Message-ID: <060.b31fda046255d2211dd8a0733d1deb50@projects.linpro.no> #384: RPM .spec is missing gcc dependency -------------------------+-------------------------------------------------- Reporter: janne | Owner: ingvar Type: enhancement | Status: closed Priority: normal | Milestone: Component: packaging | Version: trunk Severity: trivial | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: This was already in there and has been since May 11th 2007, so closing this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 15:39:48 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 15:39:48 -0000 Subject: [Varnish] #436: 2.0.2 crashes on os X with default configuration In-Reply-To: <053.de24599fd2dfd02431a96c17d161db8a@projects.linpro.no> References: <053.de24599fd2dfd02431a96c17d161db8a@projects.linpro.no> Message-ID: <062.152ac00fa1e36e657cf7a6938a92806e@projects.linpro.no> #436: 2.0.2 crashes on os X with default configuration ---------------------+------------------------------------------------------ Reporter: josh3io | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by tfheen): Could you try again with a newer version, preferably 2.0.4, or even better: the 2.0 branch from SVN? If it fails there, you should get a backtrace that I'd appreciate if you could paste into this bug report. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 15:43:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 15:43:56 -0000 Subject: [Varnish] #420: Document string concatenation In-Reply-To: <051.5ed723d27fec71a2e8c24978ff211422@projects.linpro.no> References: <051.5ed723d27fec71a2e8c24978ff211422@projects.linpro.no> Message-ID: <060.63e69b9193e3f0ab83602aa44491345c@projects.linpro.no> #420: Document string concatenation ---------------------------+------------------------------------------------ Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4331]) Document string concatenation Fixes #420 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 13 15:56:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 13 Oct 2009 15:56:14 -0000 Subject: [Varnish] #407: Documentation : the restart sample does not work if the backend is dead In-Reply-To: <053.4b0667720c2c2bf409f72fa6bd1366bb@projects.linpro.no> References: <053.4b0667720c2c2bf409f72fa6bd1366bb@projects.linpro.no> Message-ID: <062.8d412a50fe0a28b72e0a1e46a3cdb373@projects.linpro.no> #407: Documentation : the restart sample does not work if the backend is dead ---------------------------+------------------------------------------------ Reporter: jfbubus | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I fixed this using restarts in vcl_error instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 15 08:34:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 15 Oct 2009 08:34:28 -0000 Subject: [Varnish] #548: Sig 11 crash in trunk 4199 In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no> Message-ID: <061.46fb5c4ce8eba246bea35b23955b2c78@projects.linpro.no> #548: Sig 11 crash in trunk 4199 ---------------------------------------------+------------------------------ Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: sig 11 segmentation fault trunk | ---------------------------------------------+------------------------------ Comment (by anders): This is still happening (using 4199): {{{ (gdb) bt #0 0x0000000800899d8f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:324 #1 0x00000008008a022f in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:65 #2 0x0000000000420305 in pan_backtrace () at cache_panic.c:273 #3 0x00000000004206b7 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:327 #4 0x000000000041b2b5 in HSH_Lookup (sp=0x15ae766008, poh=0x7fffb61ac1e0) at cache_hash.c:506 #5 0x0000000000410c22 in cnt_lookup (sp=0x15ae766008) at cache_center.c:739 #6 0x0000000000412c83 in CNT_Session (sp=0x15ae766008) at steps.h:38 #7 0x0000000000422391 in wrk_do_cnt_sess (w=0x7fffb61b22c0, priv=Variable "priv" is not available. ) at cache_pool.c:281 #8 0x0000000000421687 in wrk_thread_real (qp=0x80100f920, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:176 #9 0x0000000800ac14d1 in pthread_getprio () from /lib/libthr.so.3 #10 0x00007fffb5fb3000 in ?? () Cannot access memory at address 0x7fffb61b3000 (gdb) frame 4 #4 0x000000000041b2b5 in HSH_Lookup (sp=0x15ae766008, poh=0x7fffb61ac1e0) at cache_hash.c:506 506 CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC); (gdb) print *sp $1 = {magic = 741317722, fd = 1811, id = 1811, xid = 1054315730, restarts = 0, esis = 0, disable_esi = 0, wrk = 0x7fffb61b22c0, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x15ae766708, mysockaddr = 0x15ae766788, mylsock = 0x80101bb50, addr = 0x15ae766808 "195.139.16.34", port = 0x15ae766816 "2764", doclose = 0x0, http = 0x15ae766250, http0 = 0x15ae7664a0, ws = {{magic = 905626964, id = 0x443828 "sess", s = 0x15ae766808 "195.139.16.34", f = 0x15ae766b99 "", r = 0x0, e = 0x15ae76a808 '?' ..., overflow = 0}}, ws_ses = 0x15ae76681b "GET", ws_req = 0x15ae766b99 "", htc = {{ magic = 1041886673, fd = 1811, ws = 0x15ae766078, rxbuf = { b = 0x15ae76681b "GET", e = 0x15ae766b99 ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1255526111.390008, t_req = 1255526111.7456758, t_resp = nan(0x8000000000000), t_end = 1255526111.390008, connect_timeout = 0.40000000000000002, first_byte_timeout = 60, between_bytes_timeout = 60, grace = 300, step = STP_LOOKUP, cur_method = 0, handling = 3, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {vtqe_next = 0x80c4d4008, vtqe_prev = 0x80ffde150}, director = 0x80baedf18, vbe = 0x0, obj = 0x0, objcore = 0x0, objhead = 0x0, vcl = 0x80baf2108, mem = 0x15ae766000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x4222d0 , priv = 0x15ae766008}, acct = {first = 1255526110.9361067, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 1, req = 3, pipe = 0, pass = 0, fetch = 0, hdrbytes = 674, bodybytes = 56959}, nhashptr = 0, ihashptr = 0, lhashptr = 0, hashptr = 0x0} (gdb) print *oc $2 = {magic = 1294996226, obj = 0x0, objhead = 0x920f9d800, timer_when = 1255893350.928561, flags = 0 '\0', timer_idx = 0, list = { vtqe_next = 0x0, vtqe_prev = 0x920f9d818}, lru_list = { vtqe_next = 0x169d48bc40, vtqe_prev = 0x80104b0c8}, smp_seg = 0x0, ban = 0x0} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 19 08:55:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Oct 2009 08:55:15 -0000 Subject: [Varnish] #436: 2.0.2 crashes on os X with default configuration In-Reply-To: <053.de24599fd2dfd02431a96c17d161db8a@projects.linpro.no> References: <053.de24599fd2dfd02431a96c17d161db8a@projects.linpro.no> Message-ID: <062.606323d8c5b0348e1e1cea1733db9ec7@projects.linpro.no> #436: 2.0.2 crashes on os X with default configuration ---------------------+------------------------------------------------------ Reporter: josh3io | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by phk): Please also try to change your "-T 88" argument to "-T :88", I suspect that may be the problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 19 08:58:01 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Oct 2009 08:58:01 -0000 Subject: [Varnish] #565: "git: command not found" messages during build w/o git In-Reply-To: <054.e28380fac8537d4cb2ade04e899e3854@projects.linpro.no> References: <054.e28380fac8537d4cb2ade04e899e3854@projects.linpro.no> Message-ID: <063.7fb657e4881f537878971f09c9226a98@projects.linpro.no> #565: "git: command not found" messages during build w/o git ----------------------+----------------------------------------------------- Reporter: kristian | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): For what it's worth: I run FreeBSD and don't see these messages. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 19 13:12:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Oct 2009 13:12:15 -0000 Subject: [Varnish] #566: varnishncsa segfault during (very) high load Message-ID: <054.2c8e9643350d3e94414771ff69da00ff@projects.linpro.no> #566: varnishncsa segfault during (very) high load -------------------------+-------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- {{{ [New process 14993] #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) at shmlog.c:315 315 if (vd->c_opt && !(vd->map[u] & M_CLIENT)) (gdb) bt #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) at shmlog.c:315 #1 0x00002b0fc9fdb47b in VSL_Dispatch (vd=0x17729010, func=0x4016f0 , priv=0x33dff50780) at shmlog.c:349 #2 0x00000000004012f3 in main (argc=2, argv=) at varnishncsa.c:589 (gdb) print vd $1 = (struct VSL_data *) 0x17729010 (gdb) print vd->c_opt $2 = 1 (gdb) print vd->map $3 = '\0' , "\001\000", '\001' , '\0' (gdb) print u $4 = 393216 (gdb) print vd->map[u] Cannot access memory at address 0x17789154 (gdb) }}} This typically happens in a matter of a few seconds when I launch my tests. This is during complete CPU utilization. Core file etc on request. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 19 13:32:47 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 19 Oct 2009 13:32:47 -0000 Subject: [Varnish] #565: "git: command not found" messages during build w/o git In-Reply-To: <054.e28380fac8537d4cb2ade04e899e3854@projects.linpro.no> References: <054.e28380fac8537d4cb2ade04e899e3854@projects.linpro.no> Message-ID: <063.e49537da743a1731b7638944f5e500e4@projects.linpro.no> #565: "git: command not found" messages during build w/o git ----------------------+----------------------------------------------------- Reporter: kristian | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kristian): Do you have git installed? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 21 00:35:04 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 21 Oct 2009 00:35:04 -0000 Subject: [Varnish] #567: Varnish freeze in trunk/4199 Message-ID: <052.6b7c7a0c14b62bbc8cd20d71436e68e0@projects.linpro.no> #567: Varnish freeze in trunk/4199 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I'm running Varnish trunk 4199 in FreeBSD/amd64 7.2-RELEASE-p3. After running for a while, Varnish stopped responding to requests. Telnet to port 80 revealed nothing, and varnishlog showed nothing. Attaching GDB to the child process I get: {{{ (gdb) bt full #0 0x0000000800acb29c in __error () from /lib/libthr.so.3 No symbol table info available. #1 0x0000000800ac9365 in pthread_cond_signal () from /lib/libthr.so.3 No symbol table info available. #2 0x000000000041f5ab in Lck_CondWait (cond=0x7fffc10092e8, lck=Variable "lck" is not available. ) at cache_lck.c:154 ilck = (struct ilck *) 0x801012a80 __func__ = "Lck_CondWait" #3 0x000000000042187d in wrk_thread_real (qp=0x80100f650, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:162 ww = {magic = 1670491599, nobjhead = 0x133244ee00, nobjcore = 0x13324fc520, stats = 0x7fffc1009f70, lastused = 1256071443.3320484, cond = 0x133248cd00, list = { vtqe_next = 0x7fffe130a2c0, vtqe_prev = 0x7fffdd0e92f0}, wrq = 0x0, wfd = 0x0, werr = 0, iov = {{iov_base = 0x830594b38, iov_len = 8}, { iov_base = 0x440431, iov_len = 1}, {iov_base = 0x830594b41, iov_len = 3}, {iov_base = 0x440431, iov_len = 1}, { iov_base = 0x830594b45, iov_len = 2}, {iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x830594b6c, iov_len = 44}, { iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x830594b99, iov_len = 33}, {iov_base = 0x43e76f, iov_len = 2}, { iov_base = 0x830594bbb, iov_len = 29}, {iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x830594bd9, iov_len = 38}, { iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x830594c00, iov_len = 24}, {iov_base = 0x43e76f, iov_len = 2}, { iov_base = 0x830594c19, iov_len = 20}, {iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x7fffc1003260, iov_len = 35}, { iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x7fffc1003284, iov_len = 30}, {iov_base = 0x43e76f, iov_len = 2}, { iov_base = 0x7fffc10032a3, iov_len = 10}, {iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x440c5b, iov_len = 16}, {iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x7fffc10032ae, iov_len = 22}, { iov_base = 0x43e76f, iov_len = 2}, {iov_base = 0x43e76f, iov_len = 2}, { iov_base = 0x830595000, iov_len = 1228}, {iov_base = 0x0, iov_len = 0} }, niov = 0, liov = 0, vcl = 0x80baed108, wlb = 0x7fffc1007270 "\001", wlp = 0x7fffc1007270 "\001", wle = 0x7fffc1009270 "", wlr = 0, sha256ctx = 0x7fffc1009f00, htc = {{ magic = 0, fd = 0, ws = 0x0, rxbuf = {b = 0x0, e = 0x0}, pipeline = { b = 0x0, e = 0x0}}}, ws = {{magic = 905626964, id = 0x4407c6 "wrk", s = 0x7fffc1003260 "Date: Tue, 20 Oct 2009 20:44:03 GMT", f = 0x7fffc10032c5 "Date: Tue, 20 Oct 2009 19:32:54 GMT", r = 0x0, e = 0x7fffc1007260 "", overflow = 0}}, http = {{magic = 0, ws = 0x0, conds = 0 '\0', logtag = 0, status = 0, protover = 0, hd = {{b = 0x0, e = 0x0} }, hdf = '\0' , nhd = 0}, {magic = 0, ws = 0x0, conds = 0 '\0', logtag = 0, status = 0, protover = 0, hd = {{b = 0x0, e = 0x0} }, hdf = '\0' , nhd = 0}, {magic = 1680389577, ws = 0x7fffc1009788, conds = 0 '\0', logtag = HTTP_Tx, status = 200, protover = 0, hd = {{b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, { ---Type to continue, or q to quit--- b = 0x830594b38 "HTTP/1.1", e = 0x830594b40 ""}, { b = 0x830594b41 "200", e = 0x830594b44 ""}, {b = 0x830594b45 "OK", e = 0x830594b47 ""}, { b = 0x830594b6c "Last-Modified: Tue, 15 Sep 2009 22:23:50 GMT", e = 0x830594b98 ""}, { b = 0x830594b99 "ETag: \"100de17-4cc-473a53c946980\"", e = 0x830594bba ""}, { b = 0x830594bbb "Cache-Control: max-age=604800", e = 0x830594bd8 ""}, { b = 0x830594bd9 "Expires: Tue, 27 Oct 2009 14:12:41 GMT", e = 0x830594bff ""}, {b = 0x830594c00 "Content-Type: image/jpeg", e = 0x830594c18 ""}, {b = 0x830594c19 "Content-Length: 1228", e = 0x830594c2d ""}, { b = 0x7fffc1003260 "Date: Tue, 20 Oct 2009 20:44:03 GMT", e = 0x7fffc1003283 ""}, { b = 0x7fffc1003284 "X-Varnish: 688562640 650619960", e = 0x7fffc10032a2 ""}, {b = 0x7fffc10032a3 "Age: 23487", e = 0x7fffc10032ad ""}, {b = 0x440c5b "Via: 1.1 varnish", e = 0x440c6b ""}, {b = 0x7fffc10032ae "Connection: keep-alive", e = 0x7fffc10032c4 ""}, {b = 0x0, e = 0x0} }, hdf = '\0' , nhd = 16}}, bereq = 0x0, beresp1 = 0x0, beresp = 0x0, resp = 0x0, cacheable = 0, age = 0, entered = 0, ttl = 0, grace = 0, do_esi = 0} sha256 = {state = {0, 0, 0, 0, 0, 0, 0, 0}, count = 0, buf = '\0' } stats = {n_object = 0, n_objecthead = 0} stats_clean = 1 __func__ = "wrk_thread_real" #4 0x0000000800ac14d1 in pthread_getprio () from /lib/libthr.so.3 No symbol table info available. #5 0x00007fffc0e0a000 in ?? () No symbol table info available. Error accessing memory address 0x7fffc100a000: Bad address. (gdb) frame 2 #2 0x000000000041f5ab in Lck_CondWait (cond=0x7fffc10092e8, lck=Variable "lck" is not available. ) at cache_lck.c:154 154 AZ(pthread_cond_wait(cond, &ilck->mtx)); (gdb) frame 3 #3 0x000000000042187d in wrk_thread_real (qp=0x80100f650, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:162 162 Lck_CondWait(&w->cond, &qp->mtx); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 22 14:46:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 22 Oct 2009 14:46:50 -0000 Subject: [Varnish] #568: varnish and https Message-ID: <054.8c90bbdc17cc1c82a85093c836a42071@projects.linpro.no> #568: varnish and https ----------------------+----------------------------------------------------- Reporter: odedbobi | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- i am runnig with varnish 2.04 version. it seems that once the varnish get an 302 response to an https url, it throws back http 503 error. what exactly is the varnish support for https ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 22 15:26:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 22 Oct 2009 15:26:53 -0000 Subject: [Varnish] #569: Cannot compile new trunk Message-ID: <051.3548034266255759fa2d0d1125e80bd1@projects.linpro.no> #569: Cannot compile new trunk -------------------+-------------------------------------------------------- Reporter: hp197 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I am having problems compiling the new trunk (Revision: 4337). {{{ Checked out revision 4337. + aclocal + libtoolize --copy --force + autoheader + automake --add-missing --copy --foreign + autoconf + aclocal + libtoolize --copy --force + autoheader + automake --add-missing --copy --foreign + autoconf checking build system type... x86_64-redhat-linux-gnu checking host system type... x86_64-redhat-linux-gnu checking target system type... x86_64-redhat-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for a BSD-compatible install... /usr/bin/install -c checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking whether make sets $(MAKE)... (cached) yes checking for xsltproc... no configure: WARNING: xsltproc not found ??? not building documentation checking for clock_gettime in -lrt... yes checking for dlopen in -ldl... yes checking for library containing initscr... -lcurses checking for library containing pthread_create... -lpthread checking for socket in -lsocket... no checking for getaddrinfo in -lnsl... yes checking for cos in -lm... yes ./configure: line 19675: PKG_PROG_PKG_CONFIG: command not found ./configure: line 19677: syntax error near unexpected token `PCRE,' ./configure: line 19677: ` PKG_CHECK_MODULES(PCRE, libpcre)' }}} {{{ # rpm -qf /usr/lib/pkgconfig/libpcre.pc pcre-devel-6.6-2.el5_1.7 }}} {{{ CentOS release 5.4 (Final) Linux 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux }}} Did install all the latest packages from CentOS. I guess the problem is that my pkg-config is too old. Are you prepared to fix this or do i need to find a workaround for this one? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 23 07:42:48 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Oct 2009 07:42:48 -0000 Subject: [Varnish] #568: varnish and https In-Reply-To: <054.8c90bbdc17cc1c82a85093c836a42071@projects.linpro.no> References: <054.8c90bbdc17cc1c82a85093c836a42071@projects.linpro.no> Message-ID: <063.cadf7451fdfff99bc8dc95b498340f46@projects.linpro.no> #568: varnish and https ----------------------+----------------------------------------------------- Reporter: odedbobi | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * priority: highest => normal * status: new => closed * resolution: => wontfix * severity: blocker => normal Comment: Varnish does not support HTTPS, neither as a server or client. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 23 07:45:18 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Oct 2009 07:45:18 -0000 Subject: [Varnish] #569: Cannot compile new trunk In-Reply-To: <051.3548034266255759fa2d0d1125e80bd1@projects.linpro.no> References: <051.3548034266255759fa2d0d1125e80bd1@projects.linpro.no> Message-ID: <060.acbcf4e82799cb0cf3dc8c8a45c210c3@projects.linpro.no> #569: Cannot compile new trunk --------------------+------------------------------------------------------- Reporter: hp197 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: You need to install pkg-config and re-run autoreconf/autogen.sh, that should make it work better. (This is only a problem for people building from SVN, therefore marking this as wontfix) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 23 07:57:40 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Oct 2009 07:57:40 -0000 Subject: [Varnish] #569: Cannot compile new trunk In-Reply-To: <051.3548034266255759fa2d0d1125e80bd1@projects.linpro.no> References: <051.3548034266255759fa2d0d1125e80bd1@projects.linpro.no> Message-ID: <060.e28156149d197547685fe9e67149b297@projects.linpro.no> #569: Cannot compile new trunk --------------------+------------------------------------------------------- Reporter: hp197 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: wontfix Keywords: | --------------------+------------------------------------------------------- Comment (by hp197): Whoops... Thought I had pkgconfig installed. My error. Thank you -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 23 10:32:09 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Oct 2009 10:32:09 -0000 Subject: [Varnish] #543: vcl.discard causes crash In-Reply-To: <049.4e608f14d8d0a3da3ed0419af34b039e@projects.linpro.no> References: <049.4e608f14d8d0a3da3ed0419af34b039e@projects.linpro.no> Message-ID: <058.52dd21ccb540e9957701ebdd89fa2d14@projects.linpro.no> #543: vcl.discard causes crash ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by janne): I'm seeing similar problem with 2.0.4 under very high load of cache misses with rather small cache file size. I have not checked the code, but to me it seems cache-cleaner thread dies when it's unable to discard items from the cache fast enough to meet the requirements for new space. This problem can be reproduced quite easily with a 100M cache size, few hundred cache missing requests per second with for example 1Mb file size. /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 :81 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 50,2000,120 -u varnish -g varnish -s file,/opt/varnish/varnish_storage.bin,100M This test setup / configuration does not make much sense, but it's still annoying to see varnish constantly dying. Child (23899) died signal=6 Child (23899) Panic message: Assert error in STV_alloc(), stevedore.c line 71: Condition((st) != NULL) not true. thread = (cache-worker) sp = 0x2aaab186e008 { fd = 32, id = 32, xid = 1876476933, client = 10.0.1.88:11419, step = STP_FETCH, handling = discard, ws = 0x2aaab186e078 { id = "sess", {s,f,r,e} = {0x2aaab186e808,,+385,(nil),+16384}, }, worker = 0x7b258bc0 { }, vcl ={ srcname = {"input", "Default", }, }, obj = 0x2aaaab100000 { refcnt = 1, xid = 1876476933,ws = 0x2aaaab100028 { id = "obj", {s,f,r,e} ={0x2aaaab100358,,+239,(nil)+7336},}, http = { ws = 0x2aaaab100028 { id = "obj", {s,f,r,e} = {0x2aaaab100358,,+239,(nil),+7336}, } Os: Linux -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 23 17:40:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 23 Oct 2009 17:40:44 -0000 Subject: [Varnish] #570: [2.0.4] Strange behaviour when using If-Modified-Since Message-ID: <056.393b733660431c23e361970df63da404@projects.linpro.no> #570: [2.0.4] Strange behaviour when using If-Modified-Since ------------------------+--------------------------------------------------- Reporter: gdelacroix | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Hi ! When sending a request with "If-Modified-Since" header in pass mode to a backend that does not correctly handle this header (never responds 304), it seems that Varnish (2.0.4) overrides this behaviour by replacing (when necessary) 200 with 304 and does not send any content => This is great ! But it seems that, when doing this, Varnish follows a different path that forgets headers that are set in vcl_fetch... Here is my vcl_fetch sample : {{{ vcl_fetch { if (req.http.Host == "www.site1.com") { set obj.http.MyTag = "Site1"; } elseif (req.http.Host == "www.site2.com") { set obj.http.MyTag = "Site2"; } } }}} In most cases (if backend sends 304 or no 304 is necessary), "MyTag" header will be sent. But only if the backend answers 200 but it should have answered 304 (Last- Modified <= If-Modified-Since), then Varnish will correct this and send 304 without data, but "MyTag" header will not be sent... I have tried to add some kind of : {{{ vcl_delivery { if (req.http.Host == "www.site1.com") { set resp.http.MyTag = "Site1"; } ... }}} but vcl_delivery doesn't handle req.http... Here is some varnishlog to give you more details : (same requests, same VCL, only backend configuration changes) Normal behaviour (304 > 304) : {{{ 11 RxProtocol b HTTP/1.1 > 11 RxStatus b 304 11 RxResponse b Not Modified 11 RxHeader b Connection: Keep-Alive 11 RxHeader b Date: Fri, 23 Oct 2009 17:20:13 GMT 11 RxHeader b ETag: "d022b2771de7c81:14ff" 11 RxHeader b Server: Microsoft-IIS/6.0 11 RxHeader b Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 11 RxHeader b Accept-Ranges: bytes 11 RxHeader b X-Powered-By: ASP.NET 7 ObjProtocol c HTTP/1.1 > 7 ObjStatus c 304 7 ObjResponse c Not Modified 7 ObjHeader c Date: Fri, 23 Oct 2009 17:20:13 GMT 7 ObjHeader c ETag: "d022b2771de7c81:14ff" 7 ObjHeader c Server: Microsoft-IIS/6.0 7 ObjHeader c Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 7 ObjHeader c X-Powered-By: ASP.NET 11 BackendReuse b MyBackend 7 TTL c 110064484 RFC 3600 1256318401 0 0 0 0 7 VCL_call c fetch 7 VCL_return c pass 7 Length c 0 7 VCL_call c deliver 7 VCL_return c deliver 7 TxProtocol c HTTP/1.1 > 7 TxStatus c 304 7 TxResponse c Not Modified 7 TxHeader c ETag: "d022b2771de7c81:14ff" 7 TxHeader c Server: Microsoft-IIS/6.0 7 TxHeader c Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 7 TxHeader c X-Powered-By: ASP.NET 7 TxHeader c Content-Length: 0 > 7 TxHeader c MyTag: Site1 7 TxHeader c Date: Fri, 23 Oct 2009 17:20:01 GMT 7 TxHeader c X-Varnish: 110064484 7 TxHeader c Age: 0 7 TxHeader c Via: 1.1 varnish 7 TxHeader c Connection: keep-alive 7 ReqEnd c 110064484 1256318401.559283018 1256318401.564701557 0.010328531 0.005382299 0.000036240 }}} Strange behaviour (200 > 304) : {{{ 11 RxProtocol b HTTP/1.1 > 11 RxStatus b 200 11 RxResponse b OK 11 RxHeader b Connection: Keep-Alive 11 RxHeader b Content-Length: 377 11 RxHeader b Date: Fri, 23 Oct 2009 17:27:19 GMT 11 RxHeader b Content-Type: image/gif 11 RxHeader b ETag: "d022b2771de7c81:1c82" 11 RxHeader b Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 11 RxHeader b Accept-Ranges: bytes 7 ObjProtocol c HTTP/1.1 > 7 ObjStatus c 200 7 ObjResponse c OK 7 ObjHeader c Date: Fri, 23 Oct 2009 17:27:19 GMT 7 ObjHeader c Content-Type: image/gif 7 ObjHeader c ETag: "d022b2771de7c81:1c82" 7 ObjHeader c Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 11 BackendReuse b MyBackend 7 TTL c 110064485 RFC 3600 1256318831 0 0 0 0 7 VCL_call c fetch 7 VCL_return c pass 7 Length c 0 7 VCL_call c deliver 7 VCL_return c deliver 7 TxProtocol c HTTP/1.1 > 7 TxStatus c 304 7 TxResponse c Not Modified 7 TxHeader c Date: Fri, 23 Oct 2009 17:27:11 GMT 7 TxHeader c Via: 1.1 varnish 7 TxHeader c X-Varnish: 110064485 7 TxHeader c Last-Modified: Wed, 16 Jul 2008 08:25:12 GMT 7 TxHeader c Connection: keep-alive 7 ReqEnd c 110064485 1256318831.177328587 1256318831.183318853 0.003719568 0.005955219 0.000035048 Where is MyTag ?? }}} It would be great if someone could explain me some fix or some workaround...cause I really miss MyTag ;o) Thanks ! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 30 12:19:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 30 Oct 2009 12:19:51 -0000 Subject: [Varnish] #571: Assert error while setting header using inline C-code Message-ID: <060.fb60b1b5d57304659e42557e698a3ac1@projects.linpro.no> #571: Assert error while setting header using inline C-code ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Keywords: ----------------------------+----------------------------------------------- Hi, Error Messege:- Oct 30 10:47:57 monitoring-ril varnishd[31107]: Child (31108) said Closed fds: 4 5 6 10 11 13 14 Oct 30 10:47:57 monitoring-ril varnishd[31107]: Child (31108) said Child starts Oct 30 10:47:57 monitoring-ril varnishd[31107]: Child (31108) said managed to mmap 1610612736 bytes of 1610612736 Oct 30 10:47:57 monitoring-ril varnishd[31107]: Child (31108) said Ready Oct 30 10:47:57 monitoring-ril varnishd[31107]: Child (31108) said Netacuity plugin loaded successfully. Oct 30 10:48:14 monitoring-ril varnishd[31107]: Child (31108) said Cont : (ind) Oct 30 10:48:14 monitoring-ril varnishd[31107]: Child (31108) died signal=6 Child (31108) Panic message: Assert error in http_IsHdr(), cache_http.c line 141: Condition(l == strlen(hdr + 1)) not true. thread = (cache- worker)sp = 0x47e02004 { fd = 10, id = 10, xid = 124885105, client = 203.199.83.206:43968, step = STP_RECV, handling = error, ws = 0x47e0204c { id = "sess", {s,f,r,e} = {0x47e02534,,+89,(nil),+16384}, }, worker = 0x473fe120 { }, vcl = { srcname = { "input", "Default", }, }, }, Config :- C{ #include #include #include char* (*get_country_code)(char* ip) = NULL; __attribute__((constructor)) void load_module() { const char* symbol_name = "CountryCode"; const char* plugin_name = "/usr/local/lib/libnetacuity.so"; void* handle = NULL; handle = dlopen( plugin_name, RTLD_NOW ); if (handle != NULL) { get_country_code = dlsym( handle, symbol_name ); if (get_country_code == NULL) fprintf( stderr, "\nError: Could not load Netacuity plugin:\n%s\n\n", dlerror() ); else { printf( "Netacuity plugin loaded successfully.\n"); } } else fprintf( stderr, "\nError: Could not load Netacuity plugin:\n%s\n\n", dlerror() ); } }C Below is used in vcl_recv :- C{ char *ip = VRT_IP_string(sp, VRT_r_client_ip(sp)); char country[256] = {0}; char *con = (*get_country_code)(ip); snprintf(country,256,"%s",con); printf("Cont : (%s)\n",country); VRT_SetHdr(sp, HDR_REQ, "\007R-CN:", country,vrt_magic_string_end); }C if (req.http.R-CN ~ "usa") { set req.http.host = "xx.example.com"; } else { set req.http.host = "yy.example.com"; } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 30 23:17:46 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 30 Oct 2009 23:17:46 -0000 Subject: [Varnish] #571: Assert error while setting header using inline C-code In-Reply-To: <060.fb60b1b5d57304659e42557e698a3ac1@projects.linpro.no> References: <060.fb60b1b5d57304659e42557e698a3ac1@projects.linpro.no> Message-ID: <069.54db59a31efe95d747f9a4c0315e333e@projects.linpro.no> #571: Assert error while setting header using inline C-code ----------------------------+----------------------------------------------- Reporter: maheshollalwar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: critical | Resolution: Keywords: | ----------------------------+----------------------------------------------- Comment (by kb): VRT_SetHdr(sp, HDR_REQ, "\007R-CN:",country,vrt_magic_string_end); I think you want this: VRT_SetHdr(sp, HDR_REQ, "\005R-CN:",country,vrt_magic_string_end); Not a bug -- the initial number needs to accurately reflect the length of the header name, including colon. Ken -- Ticket URL: Varnish The Varnish HTTP Accelerator